Remove the usage of slug fields

[glennmatthews]

Discussed in #2312

Remove slug From

Beta Give feedback

1. ProviderNetwork
2. DeviceType
3. LocationType
4. Location
5. RackGroup
6. Note
7. VLANGroup
8. Tag

^{Originally posted by lampwins August 25, 2022}
I propose ditching the usage of slug fields altogether. I realize this might be a contentious idea, so here are my thoughts.

Slugs in their present form create bad UX when managing data

Today we have slugs all over the place as fields that users can edit. Many folks have no idea what the actual function of the slug is and why it exists. I can't count the number of times I have answered the question "what is the slug for" or "what is the purpose of this field since it duplicates the name?"

We could certainly address some of these concerns, but I truly don't see the point in favor of just ditching them.

Slugs cause surprises when permalinking

If a slug is updated for whatever reason, that record's UI link changes which is surprising to the user if they don't understand the purpose of the slug. This becomes very obvious when you have objects with simple names (e.g., one word) in which the name field and the slug contain the exact same value. The user is presented with two fields with the same value, and when their intention is to change the name, it is natural for them to also change the slug, even though it is not automatically updated for an existing record.

Also, consider automation like SSoT use cases which may change the value of the slug (either inadvertently or via a valid use case).

Slugs are great if you actually care about fancy URLs

IMO slugs in Django are great if you are running a blog where there is absolutely no reason to change the title of a post, and you want a nice-looking URL, which, more importantly, is SEO friendly. Nautobot is a data-intensive, internal IT application; our data changes, and we don't care about SEO.

Also, it's 2022, and modern browsers are removing focus from the structure and content of URLs. Safari does not even show the URL. Chrome puts focus on only the domain.

Link sharing between humans has become much more advanced. Many modern chat applications will attempt to include additional link context, like the page's title while hiding the actual text of the URL.

Our usage of slugs vs. PKs is entirely inconsistent

Sometimes we use slugs, sometimes we use the UUID PK. Our REST API uses the UUID exclusively. I know we have discussed moving towards natural keys, which alone is great, but we know in many (potentially most) cases, these will be composite keys which presents many challenges in creating workable URLs that play nice within the Django ecosystem of 3rd party apps that we rely on.

Bottom line, let's move to all UUIDs

Sure they don't look sexy, but who seriously cares enough that we are going to forgo these other points? Exposing UUIDs for record identification is a sane and standard practice that reduces overall complexity. It would allow us to be consistent across the application interfaces, and most of all, it would reduce UX toil.

I humbly submit to you nuking slugs from orbit. Please do it for the children.

[bryanculver]

Models still needing slug removed (per scanning next):

• ProviderNetwork
• DeviceType
• LocationType
• Location
• RackGroup
• GitRepository
• Job (removed in Job fixes for git repositories #3840)
• ConfigContextSchema (will be removed as part of Change ConfigContext, ConfigContextSchema Uniqueness Constraints #3849)
• Note
• VLANGroup

[glennmatthews]

Need to account for the removal of slugs in the Git repository data import case (update_git_config_contexts) - this is probably a latent bug at this time.

[jvanderaa]

So in the instance where I have the following playbook creating tags:

    - name: "100: CREATE A TAG FOR PARENT PREFIX OF VM ADDRESSING"
      networktocode.nautobot.tag:
        url: "{{ nautobot_url }}"
        token: "{{ nautobot_token }}"
        name: "VM Addresses"
        description: "Addresses for VMs to live in"

That creates a tag with the name VM Addresses and the slug vm-addresses. I then have the subsequent GraphQL Query:

      {
        prefixes(tag: "vm-addresses") {
          prefix
          id
        }
      }

What does the tag: search become? Will that be the name or would we have to figure out what the UUID is first?

[glennmatthews]

The filter will use the name, yes.

[glennmatthews]

Actually Tag (specifically) will still have a slug because it's provided by django-taggit, I think?

[bryanculver]

We are keeping slug for GitRepository and Tag because:

• GitRepository: slug is used as the package name for GitRepository-provided Jobs, and they are part of the import path
• Tag: slug is provided by Django-taggit and it's more difficult than it's worth to remove them

[bryanculver]

Address #3890 as a part of this story

[glennmatthews]

@jvanderaa for visibility: Tag.slug is being removed after all as part of this issue, so yes, tag filters will need to specify the tag name instead in 2.0.

[glennmatthews]

implemented by #3914.