Remove the usage of slug fields

[lampwins]

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.

[itdependsnetworks]

Just a point of consideration. I often link to objects within plugins, I see that Device is already based on UUID, so I don't think I will have an issue, but just want to be consdiered.

[lampwins]

Absolutely and to the point about consistency, it sure would be nice to only have one way to link objects instead of contextually knowing when to use one of these two options:

reverse("view", args=[obj.pk])

reverse("view", args=[obj.slug])

Arguably, there are better patterns for this anyway, and we can look at those too.

[glennmatthews]

It's a valid question - if say a plugin wants to add a nav menu item that links to a Job, we'd need to be sure that this is still possible/feasible to do so (a la #2267) if the job is uniquely identified by a UUID rather than by a slug.

[glennmatthews]

Need to also think about how this impacts #1574. Are there models for whom the only natural key would be a slug?

[Kircheneer]

Wouldn't all of these have a name field that fulfills the same purpose?

[glennmatthews]

Not all models have a name, though IIRC all core models that have a slug also have at least a name. But fair point. :)

[glennmatthews]

We do have some models (notably CustomField, ComputedField, and Relationship -- maybe also DynamicGroup?) where a slug is directly needed/useful as a way of uniquely representing the object, often via a constrained character set, particularly in GraphQL and the REST API. I don't think we want to go in the direction of having the REST API list custom fields on an object by their UUID!

[lampwins]

I'll be clear that I certainly think we would be looking at a series of breaking changes to make this a reality.

Are there models for whom the only natural key would be a slug?

I would argue that a slug is never a natural key because a natural key should always be a unique piece of data that exists naturally in the business use case. A slug is usually some additional data representing a denormalized copy of either a valid natural key or a composite key. Thereby, IMO, a slug is always a type of surrogate key, which exists only to serve some contrived technical need, as illustrated in my premise.

[lampwins]

To further that last point, here is an example in the wild of how slugs are treated, which points to why they should not be considered actual natural keys. This comes from taggit, in which TagBase may be instantiated without specifying a slug value. In such a case, this logic will attempt to automatically create a slug value from the name, and in the case of a collision, it will append an integer value. That's certainly necessary to meet the technical unique constraint but falls outside of the business use case, making it at best a surrogate key.

https://github.com/jazzband/django-taggit/blob/72c21117f78dac37f32219f8ec8e1ce4583528f9/taggit/models.py#L42-L73

[glennmatthews]

Another case to consider: filtering and human-readable URLs.

/dcim/devices/?site=ams01&site=atl01&site=ang01 is pretty self-explanatory
/dcim/devices/?site=77e0624a-7c49-496b-98ec-2b1da85472cc&site=783352b6-1919-4a5e-be3d-cf407e09b7dc&site=30262054-b4fe-4287-8db6-6f7d831d24ea is... less so.

If we're saying that we no longer care about human-readable URLs period, then so be it - just thought this was a bit distinct from the "human-readable URL for a single object" case mentioned in the OP.