Make slug fields optional for all models #5803

adam commented

@candlerb commented on GitHub (Dec 19, 2021):

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

@candlerb commented on GitHub (Dec 19, 2021): I have no objection, except I think they should remain unique (per model).

adam commented

@jeremystretch commented on GitHub (Dec 19, 2021):

@candlerb please elaborate on why.

@jeremystretch commented on GitHub (Dec 19, 2021): @candlerb please elaborate on why.

adam commented

@candlerb commented on GitHub (Dec 19, 2021):

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.

@candlerb commented on GitHub (Dec 19, 2021): 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.

adam commented

@kkthxbye-code commented on GitHub (Dec 19, 2021):

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?

@kkthxbye-code commented on GitHub (Dec 19, 2021): 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?

adam commented

@sol1-matt commented on GitHub (Dec 20, 2021):

@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.

@sol1-matt commented on GitHub (Dec 20, 2021): @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](https://github.com/netbox-community/netbox/issues/8058#issuecomment-994130668) with it and it was fairly straight forward and better than built in validation.

adam commented

@jeremystretch commented on GitHub (Dec 20, 2021):

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.

@jeremystretch commented on GitHub (Dec 20, 2021): > 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](https://docs.djangoproject.com/en/3.2/ref/models/constraints/#condition) here to apply the constraint only when a slug is defined.

adam commented

@DanSheps commented on GitHub (Dec 20, 2021):

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 commented on GitHub (Dec 20, 2021): > 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 ""

adam commented

@DanSheps commented on GitHub (Dec 20, 2021):

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.

@DanSheps commented on GitHub (Dec 20, 2021): 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.

adam commented

@rfdrake commented on GitHub (Jan 4, 2022):

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)

@rfdrake commented on GitHub (Jan 4, 2022): 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)

adam commented

@candlerb commented on GitHub (Jan 10, 2022):

@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.

@candlerb commented on GitHub (Jan 10, 2022): @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](https://github.com/netbox-community/netbox/blob/v3.1.5/netbox/virtualization/filtersets.py#L181-L191): ``` 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.

adam commented

@jeremystretch commented on GitHub (Jan 10, 2022):

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.

@jeremystretch commented on GitHub (Jan 10, 2022): > 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.

adam commented

@candlerb commented on GitHub (Jan 10, 2022):

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")

@candlerb commented on GitHub (Jan 10, 2022): > 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](https://github.com/netbox-community/netbox/releases/v2.11.0) - *"All objects now use numeric IDs in their UI view URLs instead of slugs"*)

adam commented

@jeremystretch commented on GitHub (Jan 10, 2022):

For example, because I'm identifying a site from a script, and a config file points to the particular site I want to select.

How is that any different from using its database ID? How do you handle objects that don't have a 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?

Yes, we changed all URLs to use the database ID consistently some time ago, as we realized the slug was redundant.

@jeremystretch commented on GitHub (Jan 10, 2022): > For example, because I'm identifying a site from a script, and a config file points to the particular site I want to select. How is that any different from using its database ID? How do you handle objects that don't have a 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? Yes, we changed all URLs to use the database ID consistently some time ago, as we realized the slug was redundant.

adam commented

@candlerb commented on GitHub (Jan 10, 2022):

For example, because I'm identifying a site from a script, and a config file points to the particular site I want to select.

How is that any different from using its database ID?

e.g. site=ldex instead of site_id=7

I know what site "ldex" refers to, and it's stable between Netbox instances. I don't know what site 7 is, and it cannot be aligned between Netbox instances, unless one is an exact SQL replica of the other.

I think it's the same as tag=production versus tag_id=123. It would be possible to forbid referencing tags by anything other than their database ID; I don't think that would be an improvement.

How do you handle objects that don't have a slug?

I guess the main example is IP addresses and prefixes; I'd do a lookup IP address and VRF, as I wouldn't want to hardcode ipaddress_id=12345. I could see a use for having slugs on prefixes and ranges.

@candlerb commented on GitHub (Jan 10, 2022): > > For example, because I'm identifying a site from a script, and a config file points to the particular site I want to select. > > How is that any different from using its database ID? e.g. `site=ldex` instead of `site_id=7` I know what site "ldex" refers to, and it's stable between Netbox instances. I don't know what site 7 is, and it *cannot* be aligned between Netbox instances, unless one is an exact SQL replica of the other. I think it's the same as `tag=production` versus `tag_id=123`. It would be possible to forbid referencing tags by anything other than their database ID; I don't think that would be an improvement. > How do you handle objects that don't have a slug? I guess the main example is IP addresses and prefixes; I'd do a lookup IP address and VRF, as I wouldn't want to hardcode `ipaddress_id=12345`. I could see a use for having slugs on prefixes and ranges.

adam commented

@jeremystretch commented on GitHub (Jan 10, 2022):

I don't know what site 7 is, and it cannot be aligned between Netbox instances, unless one is an exact SQL replica of the other.

This isn't a problem we're trying to solve for (but of course you could use the name just as you do the slug).

I guess the main example is IP addresses and prefixes

Much more than those two: most models in NetBox don't include a slug field. 23 models have a slug field whereas the remaining ~66 do not.

I'd do a lookup IP address and VRF, as I wouldn't want to hardcode ipaddress_id=12345.

Exactly, you use values you already know: the address, or name, or whatever other attribute(s) you have to identify the object. The slug is just a redundant mechanism.

@jeremystretch commented on GitHub (Jan 10, 2022): > I don't know what site 7 is, and it cannot be aligned between Netbox instances, unless one is an exact SQL replica of the other. This isn't a problem we're trying to solve for (but of course you could use the name just as you do the slug). > I guess the main example is IP addresses and prefixes Much more than those two: _most_ models in NetBox don't include a slug field. 23 models have a slug field whereas the remaining ~66 do not. > I'd do a lookup IP address and VRF, as I wouldn't want to hardcode ipaddress_id=12345. Exactly, you use values you already know: the address, or name, or whatever other attribute(s) you have to identify the object. The slug is just a redundant mechanism.

adam commented

@DanSheps commented on GitHub (Jan 10, 2022):

Exactly, you use values you already know: the address, or name, or whatever other attribute(s) you have to identify the object. The slug is just a redundant mechanism.

I think the problem is, names don't have specific naming rules to enforce a specific subset of characters (alphanum, "-" and "_") that are predictable.

To give an example, there was someone working on a script (I would have to dig it up) and he was having a problem because the name had all different punctuation and capitalization so it was creating multiple objects, however if you go by slugs, they are generally lowercase and only have a - to replace any special characters or whitespace. This is where slugs shine, being predictable and well defined. I think there are more models they could be included on, but that is just me.

@DanSheps commented on GitHub (Jan 10, 2022): > Exactly, you use values you already know: the address, or name, or whatever other attribute(s) you have to identify the object. The slug is just a redundant mechanism. I think the problem is, names don't have specific naming rules to enforce a specific subset of characters (alphanum, "-" and "_") that are predictable. To give an example, there was someone working on a script (I would have to dig it up) and he was having a problem because the name had all different punctuation and capitalization so it was creating multiple objects, however if you go by slugs, they are generally lowercase and only have a - to replace any special characters or whitespace. This is where slugs shine, being predictable and well defined. I think there are more models they could be included on, but that is just me.

adam commented

@sol1-matt commented on GitHub (Jan 10, 2022):

I think the problem is, names don't have specific naming rules to enforce a specific subset of characters (alphanum, "-" and "_") that are predictable.

This can be solved in one direction with the use of custom filters.

You create a filter that checks the rules that the name field should use. The same filter can slugify the name in the same way your external application would and then check the rules the slug should match as well and reject the name if it won't match. This way if a user enters something in the name field that will be problematic for an external applications "slug" it is caught at data entry time.

This won't help if you are taking external data and trying to lookup the slug in Netbox, you'd only be able to lookup on name. The custom filters here can still help some to ensure name case insensitive uniqueness so filters don't pick up multiple results.

I think it boils down to needing to put a bit of thought into Netbox if you want to automate with it.

@sol1-matt commented on GitHub (Jan 10, 2022): > I think the problem is, names don't have specific naming rules to enforce a specific subset of characters (alphanum, "-" and "_") that are predictable. This can be solved in one direction with the use of custom filters. You create a filter that checks the rules that the `name` field should use. The same filter can slugify the name in the same way your external application would and then check the rules the slug should match as well and reject the name if it won't match. This way if a user enters something in the name field that will be problematic for an external applications "slug" it is caught at data entry time. This won't help if you are taking external data and trying to lookup the slug in Netbox, you'd only be able to lookup on name. The custom filters here can still help some to ensure name case insensitive uniqueness so filters don't pick up multiple results. I think it boils down to needing to put a bit of thought into Netbox if you want to automate with it.

adam commented

@DanSheps commented on GitHub (Jan 10, 2022):

I think the problem is, names don't have specific naming rules to enforce a specific subset of characters (alphanum, "-" and "_") that are predictable.

This can be solved in one direction with the use of custom filters.

You create a filter that checks the rules that the name field should use. The same filter can slugify the name in the same way your external application would and then check the rules the slug should match as well and reject the name if it won't match. This way if a user enters something in the name field that will be problematic for an external applications "slug" it is caught at data entry time.

This won't help if you are taking external data and trying to lookup the slug in Netbox, you'd only be able to lookup on name. The custom filters here can still help some to ensure name case insensitive uniqueness so filters don't pick up multiple results.

I think it boils down to needing to put a bit of thought into Netbox if you want to automate with it.

But then you are hamstringing your name field to follow the slug requirements which it might not need to or be desirable to do.

@DanSheps commented on GitHub (Jan 10, 2022): > > I think the problem is, names don't have specific naming rules to enforce a specific subset of characters (alphanum, "-" and "_") that are predictable. > > This can be solved in one direction with the use of custom filters. > > You create a filter that checks the rules that the `name` field should use. The same filter can slugify the name in the same way your external application would and then check the rules the slug should match as well and reject the name if it won't match. This way if a user enters something in the name field that will be problematic for an external applications "slug" it is caught at data entry time. > > This won't help if you are taking external data and trying to lookup the slug in Netbox, you'd only be able to lookup on name. The custom filters here can still help some to ensure name case insensitive uniqueness so filters don't pick up multiple results. > > I think it boils down to needing to put a bit of thought into Netbox if you want to automate with it. But then you are hamstringing your name field to follow the slug requirements which it might not need to or be desirable to do.

adam commented

@sol1-matt commented on GitHub (Jan 11, 2022):

But then you are hamstringing your name field to follow the slug requirements which it might not need to or be desirable to do.

I don't think so, you can have different requirements for name and your external slug value. But at the same time those requirements may mean some names aren't allowed because of slug requirements.

eg you have a 6 char minimum on name and slug
so name t - 123 is valid but slug with only underscore t_123 slug isn't valid (we ate the duplicates) so name fails, make the name longer please.

The alternative is a custom field for external slug that is automatically filled out along with the name, I was wondering if this is possible by abusing the custom filters. Then you can lookup the custom field.

@sol1-matt commented on GitHub (Jan 11, 2022): > But then you are hamstringing your name field to follow the slug requirements which it might not need to or be desirable to do. I don't think so, you can have different requirements for name and your external slug value. But at the same time those requirements may mean some names aren't allowed because of slug requirements. eg you have a 6 char minimum on name and slug so name `t - 123` is valid but slug with only underscore `t_123` slug isn't valid (we ate the duplicates) so name fails, make the name longer please. The alternative is a custom field for external slug that is automatically filled out along with the name, I was wondering if this is possible by abusing the custom filters. Then you can lookup the custom field.

adam commented

2025-12-29 19:32:54 +01:00

@DanSheps commented on GitHub (Jan 11, 2022):

so name t - 123 is valid but slug with only underscore t_123 slug isn't valid (we ate the duplicates) so name fails, make the name longer please.

Okay, but where is the slug field in this instance? Still need a slug field to have two different values. Spaces aren't valid in a slug field.

The alternative is a custom field for external slug that is automatically filled out along with the name, I was wondering if this is possible by abusing the custom filters. Then you can lookup the custom field.

There is no automatic fill of a custom field now, so this fails the use-case for slugs as well.

@DanSheps commented on GitHub (Jan 11, 2022): > so name `t - 123` is valid but slug with only underscore `t_123` slug isn't valid (we ate the duplicates) so name fails, make the name longer please. Okay, but where is the slug field in this instance? Still need a slug field to have two different values. Spaces aren't valid in a slug field. > The alternative is a custom field for external slug that is automatically filled out along with the name, I was wondering if this is possible by abusing the custom filters. Then you can lookup the custom field. There is no automatic fill of a custom field now, so this fails the use-case for slugs as well.

adam commented

@sol1-matt commented on GitHub (Jan 11, 2022):

Okay, but where is the slug field in this instance? Still need a slug field to have two different values. Spaces aren't valid in a slug field.

If you are using an external application that uses Netbox as a source of truth and needs slugs then you can create the slugs on the fly at export/import time, I've done this irl and it works well.

The Custom Validators can ensure the name field is validated to a level where it knows the externally created slug will be valid, I've also done this and it is working well on an existing dataset though I've had to rename on edit a couple of times, I now have better data :)

There is no automatic fill of a custom field now, so this fails the use-case for slugs as well.

I suspect custom validators could be abused for this purpose, I'm very interested in testing this out but won't have time this month most likely. Custom validators would be the right place to add this too as you want to ensure the automatic slug is validated too.

Slugification of Netbox names something that is important to me but may be a add on for my requirements rather than core Netbox. I'm still looking for any corner cases that can't be handled if slugs disappear in Netbox.

Edit: feel free to hit me up in netbox slack if you want to discuss what I've done, same name and avatar

@sol1-matt commented on GitHub (Jan 11, 2022): > Okay, but where is the slug field in this instance? Still need a slug field to have two different values. Spaces aren't valid in a slug field. If you are using an external application that uses Netbox as a source of truth and needs slugs then you can create the slugs on the fly at export/import time, I've done this irl and it works well. The Custom Validators can ensure the name field is validated to a level where it knows the externally created slug will be valid, I've also done this and it is working well on an existing dataset though I've had to rename on edit a couple of times, I now have better data :) > There is no automatic fill of a custom field now, so this fails the use-case for slugs as well. I suspect custom validators could be abused for this purpose, I'm very interested in testing this out but won't have time this month most likely. Custom validators would be the right place to add this too as you want to ensure the automatic slug is validated too. Slugification of Netbox names something that is important to me but may be a add on for my requirements rather than core Netbox. I'm still looking for any corner cases that can't be handled if slugs disappear in Netbox. Edit: feel free to hit me up in netbox slack if you want to discuss what I've done, same name and avatar

adam commented

2025-12-29 19:32:54 +01:00

@DanSheps commented on GitHub (Jan 11, 2022):

If you are using an external application that uses Netbox as a source of truth and needs slugs then you can create the slugs on the fly at export/import time, I've done this irl and it works well.

You can't use export templates on the API, so this can't be done in all instances

The Custom Validators can ensure the name field is validated to a level where it knows the externally created slug will be valid, I've also done this and it is working well on an existing dataset though I've had to rename on edit a couple of times, I now have better data :)

Again, you are then enforcing a name field to be something it isn't, you lose fidelity on the name field.

I suspect custom validators could be abused for this purpose, I'm very interested in testing this out but won't have time this month most likely. Custom validators would be the right place to add this too as you want to ensure the automatic slug is validated too.

We should not have to "abuse" a feature to get something to work for this. Slugs are here, I know some people don't like them but they also probably don't use NetBox to the fullest.

@DanSheps commented on GitHub (Jan 11, 2022): > If you are using an external application that uses Netbox as a source of truth and needs slugs then you can create the slugs on the fly at export/import time, I've done this irl and it works well. You can't use export templates on the API, so this can't be done in all instances > The Custom Validators can ensure the name field is validated to a level where it knows the externally created slug will be valid, I've also done this and it is working well on an existing dataset though I've had to rename on edit a couple of times, I now have better data :) Again, you are then enforcing a name field to be something it isn't, you lose fidelity on the name field. > I suspect custom validators could be abused for this purpose, I'm very interested in testing this out but won't have time this month most likely. Custom validators would be the right place to add this too as you want to ensure the automatic slug is validated too. We should not have to "abuse" a feature to get something to work for this. Slugs are here, I know some people don't like them but they also probably don't use NetBox to the fullest.

adam commented

2025-12-29 19:32:54 +01:00

@jcralbino commented on GitHub (Jan 21, 2022):

My experience with ansible is that when using a name to search this is actually reverted to the slug that expected to solve the "-" in the name to a "_" in slug.
Example here
https://github.com/netbox-community/netbox/issues/6955

So this will be for sure a breaking change that requires work on ansible modules and eventually also in several python scripts.

I believe before committing this change in a final version a migration plan out of the slug should be identified.

A proposal could be to eventually allow users, developers get statistics and insight when they are using this.

I would create a report( custom log file if you will) in the next version 3.n of some sort every time a slug is used instead of the name, that could redirect developers out of this feature easily. In the end of week this could be summarised and sent to a administrator for review.

The goal would be the on version 3.n+2 for example slugs could be removed without impacting current environments

@jcralbino commented on GitHub (Jan 21, 2022): My experience with ansible is that when using a name to search this is actually reverted to the slug that expected to solve the "-" in the name to a "_" in slug. Example here https://github.com/netbox-community/netbox/issues/6955 So this will be for sure a breaking change that requires work on ansible modules and eventually also in several python scripts. I believe before committing this change in a final version a migration plan out of the slug should be identified. A proposal could be to eventually allow users, developers get statistics and insight when they are using this. I would create a report( custom log file if you will) in the next version 3.n of some sort every time a slug is used instead of the name, that could redirect developers out of this feature easily. In the end of week this could be summarised and sent to a administrator for review. The goal would be the on version 3.n+2 for example slugs could be removed without impacting current environments

adam commented

@sleepinggenius2 commented on GitHub (Mar 2, 2022):

I just wanted to add two use cases for slugs that my company uses in production today.

First, they are used to enforce our naming conventions on things like locations and devices based on the tenant, site, and device role slugs. Moving this to a custom field and updating thousands of records is not something I would really want to do, as the existing slug mechanism meets our needs in that respect.

Second, slugs are so useful as an accessor field for imports. For example, on tenants, we can use the department cost center or a customer ID as the slug, which allows the name to be changed, but the object to still be referenced consistently. Again, I understand that could be done with custom fields now, but when it was first implemented, you could not add a unique constraint to custom fields, so going back and updating thousands of records just to implement it that way now is impractical.

I would argue that in our scenarios, the slug has a semantic meaning that people already know and can generally be entered directly, not looked up first. I can understand where not everyone has a use case for that field and can find it to be a burden to always have to set it, though the current auto generation mechanism should alleviate a lot of that. I would definitely not want to see the field removed, but I think it makes sense to add a configuration option to hide and/or make it not required. I think it could be useful to allow applying that on a per-model basis, but then that starts getting into #5777 territory.

@sleepinggenius2 commented on GitHub (Mar 2, 2022): I just wanted to add two use cases for slugs that my company uses in production today. First, they are used to enforce our naming conventions on things like locations and devices based on the tenant, site, and device role slugs. Moving this to a custom field and updating thousands of records is not something I would really want to do, as the existing slug mechanism meets our needs in that respect. Second, slugs are so useful as an accessor field for imports. For example, on tenants, we can use the department cost center or a customer ID as the slug, which allows the name to be changed, but the object to still be referenced consistently. Again, I understand that could be done with custom fields now, but when it was first implemented, you could not add a unique constraint to custom fields, so going back and updating thousands of records just to implement it that way now is impractical. I would argue that in our scenarios, the slug has a semantic meaning that people already know and can generally be entered directly, not looked up first. I can understand where not everyone has a use case for that field and can find it to be a burden to always have to set it, though the current auto generation mechanism should alleviate a lot of that. I would definitely not want to see the field removed, but I think it makes sense to add a configuration option to hide and/or make it not required. I think it could be useful to allow applying that on a per-model basis, but then that starts getting into #5777 territory.

adam commented

@candlerb commented on GitHub (Mar 20, 2022):

Just noting a particular case where use of slugs is mandatory and that's in query params in the REST API, when using foo=... rather than foo_id=... to limit by a related object.

# This works
curl -gH "Authorization: Token $TOKEN" "localhost:8001/api/virtualization/clusters/?type=proxmox-ve"

# This works
curl -gH "Authorization: Token $TOKEN" "localhost:8001/api/virtualization/clusters/?type_id=8"

# These don't
curl -gH "Authorization: Token $TOKEN" "localhost:8001/api/virtualization/clusters/?type=8"
{"type":["Select a valid choice. 8 is not one of the available choices."]}
curl -gH "Authorization: Token $TOKEN" "localhost:8001/api/virtualization/clusters/?type=Proxmox+VE"
{"type":["Select a valid choice. Proxmox VE is not one of the available choices."]}

I think it will be highly confusing if you're allowed to set non-unique slugs on any object type; it means a query for type=foo may act the same as type_id=8&type_id=9

Furthermore, it would also be weird if the rules for setting slugs become more lax than the rules for setting names. For example, ClusterType has a unique constraint on name, but the proposal is to remove the unique constraint on slug (while leaving the unique constraint on name!)

What I would like to see is:

slugs are optional: nullable but non-blank
non-null slugs are unique across all objects of that type, enforced by DB constraint

@candlerb commented on GitHub (Mar 20, 2022): Just noting a particular case where use of slugs is *mandatory* and that's in query params in the REST API, when using `foo=...` rather than `foo_id=...` to limit by a related object. ``` # This works curl -gH "Authorization: Token $TOKEN" "localhost:8001/api/virtualization/clusters/?type=proxmox-ve" # This works curl -gH "Authorization: Token $TOKEN" "localhost:8001/api/virtualization/clusters/?type_id=8" # These don't curl -gH "Authorization: Token $TOKEN" "localhost:8001/api/virtualization/clusters/?type=8" {"type":["Select a valid choice. 8 is not one of the available choices."]} curl -gH "Authorization: Token $TOKEN" "localhost:8001/api/virtualization/clusters/?type=Proxmox+VE" {"type":["Select a valid choice. Proxmox VE is not one of the available choices."]} ``` I think it will be highly confusing if you're allowed to set non-unique slugs on any object type; it means a query for `type=foo` may act the same as `type_id=8&type_id=9` Furthermore, it would also be weird if the rules for setting *slugs* become more lax than the rules for setting *names*. For example, ClusterType has a unique constraint on name, but the proposal is to remove the unique constraint on slug (while leaving the unique constraint on name!) What I would like to see is: * slugs are optional: nullable but non-blank * non-null slugs are unique across all objects of that type, enforced by DB constraint

adam commented

@seismiccollision commented on GitHub (Mar 29, 2022):

i'd just like to +1 for slugs
it was really convenient to be able to directly reach an object from a human-readable url like how sites was. i know that ship has sailed but i'm going to miss it

it's easier said than done to get every external system to query netbox to get an ID before crafting a url so i'm often stuck with a user experience of two clicks to reach the specific object a user wanted (as far as i know) instead of a link to a query result

and related to slugs in urls, i'd still rather rely on slugs over externally storing links to an object id because accidental object deletions do happen and it's just nice to know what a link is going to show you by looking at it

sorry if i don't know what i'm talking about, i'm just a netbox end user but i'm still trying to catch up from changes made in 2.10 so figure i need to be more engaged commenting on things that will make things more difficult for me when i see them

@seismiccollision commented on GitHub (Mar 29, 2022): i'd just like to +1 for slugs it was really convenient to be able to directly reach an object from a human-readable url like how sites was. i know that ship has sailed but i'm going to miss it it's easier said than done to get every external system to query netbox to get an ID before crafting a url so i'm often stuck with a user experience of two clicks to reach the specific object a user wanted (as far as i know) instead of a link to a query result and related to slugs in urls, i'd still rather rely on slugs over externally storing links to an object id because accidental object deletions do happen and it's just nice to know what a link is going to show you by looking at it sorry if i don't know what i'm talking about, i'm just a netbox end user but i'm still trying to catch up from changes made in 2.10 so figure i need to be more engaged commenting on things that will make things more difficult for me when i see them

adam commented

@ryanmerolle commented on GitHub (May 28, 2022):

There would likely be a bunch of implications related to this with the ansible inventory plugin and ansible modules if everything did not always have a slug.

We might be able lessen the blow if we auto-slugify object names for ansible, but it would be a decent amount of work and likely break a lot of people's Ansible integrations.

I could be overthinking this; @rodvand what are your thoughts?

@ryanmerolle commented on GitHub (May 28, 2022): There would likely be a bunch of implications related to this with the ansible inventory plugin and ansible modules if everything did not always have a slug. We might be able lessen the blow if we auto-slugify object names for ansible, but it would be a decent amount of work and likely break a lot of people's Ansible integrations. I could be overthinking this; @rodvand what are your thoughts?

adam commented

2025-12-29 19:32:56 +01:00

@rodvand commented on GitHub (May 28, 2022):

There would likely be a bunch of implications related to this with the ansible inventory plugin and ansible modules if everything did not always have a slug.

We might be able lessen the blow if we auto-slugify object names for ansible, but it would be a decent amount of work and likely break a lot of people's Ansible integrations.

I could be overthinking this; @rodvand what are your thoughts?

The ansible modules would have to start using the name as an identifier. There are already some issues today when people use non auto-generated slugs and their playbooks fail. It's also not apparent to everyone that slugs are the main identifier used, so I can see moving away from slugs being a good thing. Will be some work though...

@rodvand commented on GitHub (May 28, 2022): > There would likely be a bunch of implications related to this with the ansible inventory plugin and ansible modules if everything did not always have a slug. > > We might be able lessen the blow if we auto-slugify object names for ansible, but it would be a decent amount of work and likely break a lot of people's Ansible integrations. > > I could be overthinking this; @rodvand what are your thoughts? The ansible modules would have to start using the name as an identifier. There are already some issues today when people use non auto-generated slugs and their playbooks fail. It's also not apparent to everyone that slugs are the main identifier used, so I can see moving away from slugs being a good thing. Will be some work though...

adam commented

@DanSheps commented on GitHub (May 29, 2022):

Names are not guaranteed unique (neither are slugs but I can see a way to fix that with some sort of auto-generated slug).

@DanSheps commented on GitHub (May 29, 2022): Names are not guaranteed unique (neither are slugs but I can see a way to fix that with some sort of auto-generated slug).

adam commented

2025-12-29 19:32:56 +01:00

@rodvand commented on GitHub (May 29, 2022):

Names are not guaranteed unique (neither are slugs but I can see a way to fix that with some sort of auto-generated slug).

That's true, the name would be used in conjunction with other attributes to ensure uniqueness. Using auto-generated unique slugs wouldn't really solve anything for the ansible modules as users are inputting the name of a device, and it's turned into a slug used in the API calls. So if a user inputs "Device 1" it's translated to device-1 and so on. If you have two Device 1 there wouldn't be a way to differentiate them purely on the slug (as the modules would both just translate them to the slug device-1).

I think we've highlighted the ansible modules use of slugs. Not a show stopper, but a revamp of the modules is needed.

@rodvand commented on GitHub (May 29, 2022): > Names are not guaranteed unique (neither are slugs but I can see a way to fix that with some sort of auto-generated slug). That's true, the name would be used in conjunction with other attributes to ensure uniqueness. Using auto-generated unique slugs wouldn't really solve anything for the ansible modules as users are inputting the name of a device, and it's turned into a slug used in the API calls. So if a user inputs "Device 1" it's translated to device-1 and so on. If you have two Device 1 there wouldn't be a way to differentiate them purely on the slug (as the modules would both just translate them to the slug device-1). I think we've highlighted the ansible modules use of slugs. Not a show stopper, but a revamp of the modules is needed.

adam commented

@sol1-matt commented on GitHub (Jun 1, 2022):

@rodvand
I have my own ansible inventory manly because the built in one was insufficient for my needs. As a result my ansible inventory ended up using a sanitized name, or other text field which uniquely identifies the Netbox object, to generate unique groups and vars in the inventory.

I also do the same thing with a Icinga Director import module.

Both the external systems have their own naming quirks, I suspect other external systems would have their own unique naming requirements.

Before this issue I used Slug, it was good but each system using a naming convention that suits it is better.

To ensure the Netbox data is safe for the external systems I'm using Custom Validators in Netbox to perform the same sanitization and ensure all requirements are met at data entry time. This is working very nicely in practice all around.

The only real downside is I need to maintain code for each external system and in the custom validators.

This doesn't address anything relying on the slugs to get/push data to netbox. Just pulling it.

@sol1-matt commented on GitHub (Jun 1, 2022): @rodvand I have my own ansible inventory manly because the built in one was insufficient for my needs. As a result my ansible inventory ended up using a sanitized name, or other text field which uniquely identifies the Netbox object, to generate unique groups and vars in the inventory. I also do the same thing with a Icinga Director import module. Both the external systems have their own naming quirks, I suspect other external systems would have their own unique naming requirements. Before this issue I used Slug, it was good but each system using a naming convention that suits it is better. To ensure the Netbox data is safe for the external systems I'm using Custom Validators in Netbox to perform the same sanitization and ensure all requirements are met at data entry time. This is working very nicely in practice all around. The only real downside is I need to maintain code for each external system and in the custom validators. _This doesn't address anything relying on the slugs to get/push data to netbox. Just pulling it._

adam commented

@ryanmerolle commented on GitHub (Jun 3, 2022):

Would this also break graphql filtering?

Examples using demo.netbox.dev:

Does not work so does not filter.

{
  circuit_list(type: "Dark Fiber") {
    id
    cid
    type {
      name
    }
  }
}

Works/filters:

{
  circuit_list(type: "dark-fiber") {
    id
    cid
    type {
      name
    }
  }
}

@ryanmerolle commented on GitHub (Jun 3, 2022): Would this also break graphql filtering? Examples using demo.netbox.dev: Does not work so does not filter. ``` { circuit_list(type: "Dark Fiber") { id cid type { name } } } ``` Works/filters: ``` { circuit_list(type: "dark-fiber") { id cid type { name } } } ```

adam commented

@seismiccollision commented on GitHub (Jun 16, 2022):

this morning two months later i still think it's a better user experience to be able to link people to https://demo.netbox.dev/circuits/providers/centurylink/ where
reading the link makes sense to humans
vs https://demo.netbox.dev/circuits/providers/2/ which means nothing and would change if the object gets accidentally deleted or the two-click user experience that doesn't sacrifice readability of linking to a search https://demo.netbox.dev/circuits/providers/?name=CenturyLink

@seismiccollision commented on GitHub (Jun 16, 2022): this morning two months later i still think it's a better user experience to be able to link people to https://demo.netbox.dev/circuits/providers/centurylink/ where reading the link makes sense to humans vs https://demo.netbox.dev/circuits/providers/2/ which means nothing and would change if the object gets accidentally deleted or the two-click user experience that doesn't sacrifice readability of linking to a search https://demo.netbox.dev/circuits/providers/?name=CenturyLink

adam commented