starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Don't change slug if already exists/populated #3102

New Issue
Closed
opened 2025-12-29 18:25:38 +01:00 by adam · 4 comments
adam commented 2025-12-29 18:25:38 +01:00
Owner
Copy Link

Originally created by @CrackerJackMack on GitHub (Dec 30, 2019).

Environment

  • Python version: 3.6.5
  • NetBox version: v2.6.9

Proposed Functionality

When editing an item's name (site, device, ...) with slugs already populated, the javascript shouldn't automatically regenerate and clobber the existing slug. Would be nice to include a refresh (↺) icon next to the slug name for those who do want the slug to update with the generated value.

Use Case

Updating the slug on the edit pages breaks any shared links (i.e. from a wiki page for documentation) or breaks the already chosen slug format (imported data including a slug). My use case is an already existing database in which we imported the data. But any typo's in the name that were discovered or when the site name changes (rare but acquisitions do happen) causes the per-determined slug to be invalidated. With my current employer and my previous employer, for sites alone this is well in excess of 100+, and 75+ for multi-hierarchy regions.

Generating the slug makes complete sense when creating an ad-hoc entry, but not editing an existing one IMHO.

Database Changes

None

External Dependencies

AFAICT, none

Originally created by @CrackerJackMack on GitHub (Dec 30, 2019). ### Environment * Python version: 3.6.5 * NetBox version: v2.6.9 ### Proposed Functionality When editing an item's name (site, device, ...) with slugs already populated, the javascript shouldn't automatically regenerate and clobber the existing slug. Would be nice to include a refresh (↺) icon next to the slug name for those who do want the slug to update with the generated value. ### Use Case Updating the slug on the edit pages breaks any shared links (i.e. from a wiki page for documentation) or breaks the already chosen slug format (imported data including a slug). My use case is an already existing database in which we imported the data. But any typo's in the name that were discovered or when the site name changes (rare but acquisitions do happen) causes the per-determined slug to be invalidated. With my current employer and my previous employer, for sites alone this is well in excess of 100+, and 75+ for multi-hierarchy regions. Generating the slug makes complete sense when creating an ad-hoc entry, but not editing an existing one IMHO. ### Database Changes None ### External Dependencies AFAICT, none
adam added the status: accepted label 2025-12-29 18:25:38 +01:00
adam closed this issue 2025-12-29 18:25:38 +01:00
adam commented 2025-12-29 18:25:39 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 31, 2019):

But any typo's in the name that were discovered or when the site name changes (rare but acquisitions do happen) causes the per-determined slug to be invalidated.

But that means correcting the name automatically corrects the slug, right? I wouldn't think you'd want to keep the erroneous slug. Yes, it means updating any referring links from external sources, but that's the cost of not validating data prior to import.

@jeremystretch commented on GitHub (Dec 31, 2019): > But any typo's in the name that were discovered or when the site name changes (rare but acquisitions do happen) causes the per-determined slug to be invalidated. But that means correcting the name automatically corrects the slug, right? I wouldn't think you'd want to keep the erroneous slug. Yes, it means updating any referring links from external sources, but that's the cost of not validating data prior to import.
adam commented 2025-12-29 18:25:39 +01:00
Author
Owner
Copy Link

@CrackerJackMack commented on GitHub (Dec 31, 2019):

Fair point. However I don't feel that it invalidates the 2nd portion in which slugs are generated on import. Re-reading my initial request I seem to have not communicated this well.

I set many of the slugs because we already had uniqueness and it's required for import. For example, device roles I had 'Edge fabric switch'='efs' instead of 'edge-fabric-switch', Sites already had small site codes 'Equinix DA2'='EQ-DA2'. Automatically updating the slug (even by accident) seems to have undesirable results for me.

Being it's all in the javascript, I'm assuming it isn't something we can create a config setting for unfortunately.

@CrackerJackMack commented on GitHub (Dec 31, 2019): Fair point. However I don't feel that it invalidates the 2nd portion in which slugs are generated on import. Re-reading my initial request I seem to have not communicated this well. I set many of the slugs because we already had uniqueness and it's required for import. For example, device roles I had 'Edge fabric switch'='efs' instead of 'edge-fabric-switch', Sites already had small site codes 'Equinix DA2'='EQ-DA2'. Automatically updating the slug (even by accident) seems to have undesirable results for me. Being it's all in the javascript, I'm assuming it isn't something we can create a config setting for unfortunately.
adam commented 2025-12-29 18:25:39 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Jan 12, 2020):

But that means correcting the name automatically corrects the slug, right? I wouldn't think you'd want to keep the erroneous slug.

In my case, I do want to keep the original ("erroneous") slug.

I am planning to use the slug as a stable reference for another system. If the user-readable description is changed, I want the slug to be kept the same.

I think the solution could be as simple as:

  • When creating a new device role, site, rack etc: auto-populate the slug as you type (*)
  • But when editing an existing record, don't update the slug. The user can still change it if they wish.

(*) Or even more simply: you could leave the field empty in the UI. On save, if the slug is empty, then auto-generate one. If there is a conflict with existing slug, the record will fail to save.

This also has the benefit that if you want to "reset" the slug you can just set it to empty field and save; no need for a "refresh" button.

@candlerb commented on GitHub (Jan 12, 2020): > But that means correcting the name automatically corrects the slug, right? I wouldn't think you'd want to keep the erroneous slug. In my case, I do want to keep the original ("erroneous") slug. I am planning to use the slug as a stable reference for another system. If the user-readable description is changed, I want the slug to be kept the same. I think the solution could be as simple as: * When creating a *new* device role, site, rack etc: auto-populate the slug as you type (*) * But when editing an *existing* record, don't update the slug. The user can still change it if they wish. (*) Or even more simply: you could leave the field empty in the UI. On save, if the slug is empty, then auto-generate one. If there is a conflict with existing slug, the record will fail to save. This also has the benefit that if you want to "reset" the slug you can just set it to empty field and save; no need for a "refresh" button.
adam commented 2025-12-29 18:25:40 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 19, 2020):

Disabled auto-reslugification for existing objects and added a button to manually regenerate it:

edit_site_slug

@jeremystretch commented on GitHub (Feb 19, 2020): Disabled auto-reslugification for existing objects and added a button to manually regenerate it: ![edit_site_slug](https://user-images.githubusercontent.com/13487278/74865598-5f871000-531f-11ea-9d35-2ca08ac84194.png)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label status: accepted
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#3102
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?