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

Inconsistent requirement for slugs across GUI and API #7298

New Issue
Closed
opened 2025-12-29 20:21:29 +01:00 by adam · 1 comment
adam commented 2025-12-29 20:21:29 +01:00
Owner
Copy Link

Originally created by @jwbensley on GitHub (Nov 29, 2022).

NetBox version

v3.3.2

Python version

3.10

Steps to Reproduce

Try to add an object to NetBox either via the GUI or via the API without a slug, when a slug is required, and the request is rejected. An error is presented that a slug is hard required.

Expected Behavior

The following objects are just some of the objects which require the user to specify a slug at the time of creation:

  • Site
  • Site Group
  • Location
  • Region
  • Rack Role
  • Tenant
  • Tenant Group
  • Contact Groups
  • Contact Roles
  • and many more....

Whether a slug is or is not required for object creation, is not consistent across object types in NB. For example, a slug is required for creating a Contact Role and Contact Group, but not for a Contact. A slug is required for creating Rack Role but not for Rack. A slug is required for creating Device Roles but not for a Device. And so on.

So I think one problem is that whether a slug is hard required should be consistent across all object types, otherwise API clients have to be aware of the type of object being created and take extra steps to create a slug, only when certain object types are being created, like a Device Role, but not a Device. In stead of having this inconsistency, I think supplying slugs at object creation time in NB should be optional, and if one isn't supplied by the user when creating an object, NetBox should just call the Django slugify() method against the name of the object being created.

This is actually what is happening in the GUI today. This isn't happening via the API though. So I think the solution is to make the "slug" field optional for all API calls, and then have NB call slugify() just as it does via the GUI, if the slug is missing from an API create request.

Firstly, this would we fix the 1st problem above, that some objects require a slug and some don't: my API client would no longer need to track which objects require a slug, and implement a method for generating them. Secondly this would align the behaviour between GUI and API. GUI users don't need to provide a slug because one is created for them, where a slug is hard required.

Observed Behavior

API calls without a slug are rejected.

Originally created by @jwbensley on GitHub (Nov 29, 2022). ### NetBox version v3.3.2 ### Python version 3.10 ### Steps to Reproduce Try to add an object to NetBox either via the GUI or via the API without a slug, when a slug is required, and the request is rejected. An error is presented that a slug is hard required. ### Expected Behavior The following objects are just some of the objects which require the user to specify a slug at the time of creation: - Site - Site Group - Location - Region - Rack Role - Tenant - Tenant Group - Contact Groups - Contact Roles - and many more.... Whether a slug is or is not required for object creation, is not consistent across object types in NB. For example, a slug is required for creating a Contact Role and Contact Group, but not for a Contact. A slug is required for creating Rack Role but not for Rack. A slug is required for creating Device Roles but not for a Device. And so on. So I think one problem is that whether a slug is hard required should be consistent across all object types, otherwise API clients have to be aware of the type of object being created and take extra steps to create a slug, only when certain object types are being created, like a Device Role, but not a Device. In stead of having this inconsistency, I think supplying slugs at object creation time in NB should be optional, and if one isn't supplied by the user when creating an object, NetBox should just call the Django `slugify()` method against the name of the object being created. This is actually what is happening in the GUI today. This isn't happening via the API though. So I think the solution is to make the "slug" field optional for all API calls, and then have NB call `slugify()` just as it does via the GUI, if the slug is missing from an API create request. Firstly, this would we fix the 1st problem above, that some objects require a slug and some don't: my API client would no longer need to track which objects require a slug, and implement a method for generating them. Secondly this would align the behaviour between GUI and API. GUI users don't need to provide a slug because one is created for them, where a slug is hard required. ### Observed Behavior API calls without a slug are rejected.
adam closed this issue 2025-12-29 20:21:29 +01:00
adam commented 2025-12-29 20:21:30 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 29, 2022):

This is a not a bug. If you would like to propose changes to the fields required for particular models, please do so by submitting a feature request citing your use case. You might also be interested in the discussion under #8036, which proposed removing slugs entirely.

@jeremystretch commented on GitHub (Nov 29, 2022): This is a not a bug. If you would like to propose changes to the fields required for particular models, please do so by submitting a [feature request](https://github.com/netbox-community/netbox/issues/new?assignees=&labels=type%3A+feature&template=feature_request.yaml) citing your use case. You might also be interested in the discussion under #8036, which proposed removing slugs entirely.
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
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#7298
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?