Make slug fields optional for all models

[jeremystretch]

NetBox version

v3.1.1

Feature type

Change to existing functionality

Proposed functionality

For all 22 models which currently have a required slug field, make the field optional and remove the uniqueness requirement. This will make the slug field no longer required in UI forms and REST API serializers.

Use case

Slugs are no longer used as unique identifiers in NetBox URLs, and no longer serve any native function. #8036 proposed removing slug fields entirely, however some users have expressed opposition to this idea. As an alternative, making slugs optional will preserve their utility for those users while alleviating the undue burden they place on users who do not.

Users who wish to still enforce slugs as required fields can employ simple custom validation rules to do so.

Database changes

A migration will be introduced within each app altering all models.SlugField instances to set blank=True.

External dependencies

No response

[candlerb]

I have no objection, except I think they should remain unique (per model).

[jeremystretch]

@candlerb please elaborate on why.

[candlerb]

If a slug has any usefulness, then it's because it's a unique identifier. If I know object X has slug Y, then I can search for /foo/?slug=Y and be sure I get exactly zero or one.

The field already has a unique constraint, so why remove it? People who don't want to use slugs can set them to null.

[kkthxbye-code]

For automation we have the id, which is a unique identifier. So the usecase is a human searchable unique key with constraints regarding charset? And name with custom constraints is not enough?

[sol1-matt]

@kkthxbye-code

For automation we have the id, which is a unique identifier. So the use case is a human searchable unique key with constraints regarding charset? And name with custom constraints is not enough?

ID's are good for machines but not as good for people, often automation is building something that humans will look at.

Example 1
If the automation you are using does something like use templates to create relationships then you end up with a bunch of templates named 123 which are terrible at describing the template itself. The current slug means your unique link between objects is also human readable eg: the-earth.

Example 2
In the filter example from @candlerb a human will likely know a slug name but they won't know the id. So using a slug in a filter is straight forward where as using the id will require something to lookup the id.

I know I've run into this with id's in Netbox and why I've built a lot of automation around slugs, it simplifies things greatly with the same safety.

@candlerb

except I think they should remain unique (per model).

I don't disagree with the uniqueness constraint but I'd encourage you to look at custom validation as the method of enforcing that, I had a play around with it and it was fairly straight forward and better than built in validation.

[jeremystretch]

ID's are good for machines but not as good for people, often automation is building something that humans will look at.

Slugs aren't good for people either: They were only ever intended to serve as an alternative identifier in URLs. Such a system should always be presenting a proper human-friendly value to the user, retrieved from the database being queried. This is exactly how the NetBox UI works: When you go to add a device, you see a list of proper site names, but the form submits the selected site's numeric ID.

The field already has a unique constraint, so why remove it?

Slugs are stored as strings. If we make them optional, empty slugs will be stored as empty strings. Retaining the unique constraint in its current form would not permit more than one empty slug per model (because "" == ""). An alternative approach would be store empty slugs as null (because null != null), however that's generally not recommended as it can lead to other issues. However, I think we may be able to leverage UniqueConstraint conditions here to apply the constraint only when a slug is defined.

[DanSheps]

Slugs aren't good for people either: They were only ever intended to serve as an alternative identifier in URLs. Such a system should always be presenting a proper human-friendly value to the user, retrieved from the database being queried. This is exactly how the NetBox UI works: When you go to add a device, you see a list of proper site names, but the form submits the selected site's numeric ID.

Slugs are generally a human friendly value stored in the database. I know we used them strictly as URL components, but slugs really are suppose to be short human-usable labels for something.

Going back to the DJango docs: Slug is a newspaper term. A slug is a short label for something, containing only letters, numbers, underscores or hyphens. They’re generally used in URLs. Can't get much more human friendly then that IMO. Using names, you add additional formatting potential (punctuation, additional characters, etc) which aren't allowed in a slug field.

A slug field (in general) isn't meant to replace the name field but compliment it so that you can quickly reference it in things like the REST API, the Python API, etc. For example, lets take the Dunder-Mifflin Inc. tenant. First, you have a space, a hyphen and a period in addition to the alphanumeric characters, however this renders to dunder-mifflin-inc in a slug.

Lets say you don't remember the ID but you want to get all devices belonging to Dunder Mifflin. Sure, you can search by name, however the name mostly has to be exact (Sure, you could do name__startswith=Dunder-Mifflin but that could pull unintended data). With a slug, you only need to remember the slug rules (alphanum, hyphens) to find the devices, less chance of getting the wrong data, less chance of getting nothing at all.

Moving over to the rest API, you can only query by slug or ID on related fields currently in most instances. There really isn't a way to query by name. We would either need to drop in a new filter for name or everyone would need to hit the API first for the PK of what they want. TBH, I wish we had slugs on more things but that is just me.

However, I think we may be able to leverage UniqueConstraint conditions here to apply the constraint only when a slug is defined.

I like this idea. Only care about it when slug is not None or ""

[DanSheps]

One additional comment, perhaps add a configuration option to "hide" the slug field completely. I know we have typically shied away from hiding information within NetBox but given the split of people who want to use slugs and those who don't, I think removing it from view might make those that don't want it happier as well.

[rfdrake]

I'm only noting this so that people are aware. I don't particularly care if slugs exist or not.

The ansible modules for netbox use slugs in many ways. Some of which are probably inappropriate but would need to be refactored to keep the modules working. That also means that people using them in production would need to refactor their playbooks to account for the changes.

An example is tying a block to a site. Here is a stub of an ansible task:

- name: netbox add block
  netbox_prefix:
    netbox_url: "{{ lookup('env', 'NETBOX_URL') }}"
    netbox_token: "{{ lookup('env', 'NETBOX_TOKEN') }}"
    data:
        prefix: "{{ block['prefix'] }}"
        site: "{{ block['site']| default(omit,true) }}"

In this case, the block['site'] is the slug rather than the site name.

From what I've read, the ansible module is currently looking for a maintainer. It might be difficult to coordinate this change to it's users. (https://github.com/netbox-community/ansible_modules#looking-for-new-maintainers)

[candlerb]

@DanSheps said:

Moving over to the rest API, you can only query by slug or ID on related fields currently in most instances. There really isn't a way to query by name.

To expand that with a concrete example, this is from VirtualMachineFilterSet:

    site_id = django_filters.ModelMultipleChoiceFilter(
        field_name='cluster__site',
        queryset=Site.objects.all(),
        label='Site (ID)',
    )
    site = django_filters.ModelMultipleChoiceFilter(
        field_name='cluster__site__slug',
        queryset=Site.objects.all(),
        to_field_name='slug',
        label='Site (slug)',
    )

site_id filters by the site's sequential database ID, site filters by the site's slug. There are a lot of filters like this. This is one reason why I think slugs should be unique per model; if you're going to identify something by a slug, you really don't want to be dealing with ambiguity at the same time.

It would in principle be possible to add site_name as a new query filter. That's going to add a lot of different filters all over the place, for lots of other things you might filter by. You'd also have to decide whether to mix together the results from multiple sites which happen to have the same name (ugh), or to give an error if there is no unique name match, maybe (ab)using 409 for this.

If getting rid of slugs completely, then the plain site filter could be deprecated and eventually removed.

[jeremystretch]

if you're going to identify something by a slug

But why are you identifying anything by a slug to begin with? The slug is not a value that can be assumed by the user (such as an object's proper name may be). So in order to know the slug, you must first have retrieved the object from the database at some point. And since you've already retrieved the object from the database, you know and can use its database ID. The slug is irrelevant.

[candlerb]

But why are you identifying anything by a slug to begin with?

For example, because I'm identifying a site from a script, and a config file points to the particular site I want to select. Sure, I could lookup the site's ID first, and put that in the config file. But then (a) it would be opaque, and (b) it would be different between two different Netbox instances, say dev and prod.

You could say the same thing about tags. Which is clearer, filtering on tag_id=9 or tag=gateway ?

Aside 1: tags right now are a special case. Firstly, /extras/tags/9/ doesn't show any slug, but /extras/tags/add/ does prompt you for a slug. Secondly, it enforces uniqueness on both name and slug. When I filter by tag=foo I'm not actually sure if that's the slug or the name I'm using; I'd hope it's the slug.

Aside 2: I have a vague memory that there was somewhere in the web UI that used the slug as part of the URL, but I can't find it now - maybe it was changed to use ID instead? (EDIT: found it, in v2.11 - "All objects now use numeric IDs in their UI view URLs instead of slugs")