Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please reconsider dropping slugs in URLs in NetBox 2.11 #6097

Closed
bootc opened this issue Apr 6, 2021 · 3 comments
Closed

Please reconsider dropping slugs in URLs in NetBox 2.11 #6097

bootc opened this issue Apr 6, 2021 · 3 comments
Assignees
Labels
beta Concerns a bug/feature in a beta release status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application

Comments

@bootc
Copy link
Member

bootc commented Apr 6, 2021

NetBox version

v2.11-beta1

Python version

3.8

Steps to Reproduce

From your release notes:

  • All objects now use numeric IDs in their UI view URLs instead of slugs. You may need to update external references to NetBox objects. (Note that this does not affect the REST API.)
  • The UI now uses numeric IDs when filtering object lists. You may need to update external links to filtered object lists. (Note that the slug- and name-based filters will continue to work, however the filter selection fields within the UI will not be automatically populated.)

Expected Behavior

The use of slugs should remain, ideally indefinitely but at the very least there should be an overlap of at least one release where both work.

Observed Behavior

URL slugs no longer work at all.

We have quite a lot of documentation in other places (e.g. wikis and other documents) which point back at NetBox, and all of those links will break when we upgrade. It's a big ask for us to upgrade and then trawl through all our docs to update the links for (from a user perspective) no discernible gain.

I understand you wanting to change this, and the reasons given. Perhaps the think to do is have some kind of compatibility shim that, if a URL with slugs is detected, can redirect to the URL with IDs instead? That would keep the URLs working, possibly even indefinitely. I think we'd be happy to sacrifice some performance in terms of the extra redirect just to avoid having to spend hours updating all the documentation.

@bootc bootc added the type: bug A confirmed report of unexpected behavior in the application label Apr 6, 2021
@jeremystretch
Copy link
Member

Perhaps the think to do is have some kind of compatibility shim that, if a URL with slugs is detected, can redirect to the URL with IDs instead?

Yeah, I think that's a reasonable solution. Accessing /dcim/sites/raleigh-nc/ would redirect to /dcim/sites/489/, for example. The only potential hiccup would be for an object with an entirely numeric slug (which would be interpreted as a primary key), though that seems like it would be pretty uncommon.

@jeremystretch jeremystretch added beta Concerns a bug/feature in a beta release status: under review Further discussion is needed to determine this issue's scope and/or implementation status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application and removed status: under review Further discussion is needed to determine this issue's scope and/or implementation type: bug A confirmed report of unexpected behavior in the application labels Apr 6, 2021
@jeremystretch jeremystretch self-assigned this Apr 8, 2021
@jeremystretch
Copy link
Member

There are only three models significantly affected by the switch from slugs to PKs:

  • circuits.Provider
  • dcim.Site
  • tenancy.Tenant

These are the only three models with individual object views accessed via slug. (Many of the organizational models employed slugs for their edit/delete/changelog URLs, however these are unlikely to be directly referenced outside the NetBox UI.) I'm working on adding a simple slug-based redirection view for these three models.

@bootc
Copy link
Member Author

bootc commented Apr 8, 2021

Thanks very much!

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
beta Concerns a bug/feature in a beta release status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application
Projects
None yet
Development

No branches or pull requests

2 participants