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

Device name prefix automatic normalization button #9377

New Issue
Closed
opened 2025-12-29 20:49:08 +01:00 by adam · 2 comments
adam commented 2025-12-29 20:49:08 +01:00
Owner
Copy Link

Originally created by @e3elettronica on GitHub (Mar 21, 2024).

NetBox version

v3.7.2

Feature type

New functionality

Proposed functionality

Add an optional button in device creation page for triggering the proposal of a string to be used as device name prefix generated using some normalization rules.
The button should be close to the device name form text field.
The button could be optional, visible only if a dedicated flag is set either in user or in global configuration menu.
When the button is pushed, the system should collect temporary values from the other device creation page form fields, calculate a normalized device name prefix and pre-populate the new device name form text field with the proposed device name prefix.
After pushing button, if the generated string is acceptable, the operator just needs to add the trailing part of the device name in order to make it unique before creating the device instance.
The device name prefix generation and proposal should work only on-demand by pushing the button.
The device name prefix calculation could be based on:

  • a predefined rule
  • a custom rule

If the device name prefix calculation is based on a predefined rule it could use the tenant/site/location/rack field temporary values and it could concatenate them (es. tenantval-siteval-locationval-rackval) in order to create the proposed string.
It is not the best option because some of these values could need to be sanitized or normalized or simplified.

If the device name prefix calculation is based on a custom rule it should be base on a script provided either by the administrator (for all the server) or by the user (for his own session).
The device name prefix calculation script should be able to:

  • extract temporary variables values from all device creation page form fields temporary values (both text fields and selectable fields)
  • modify each temporary variables values using some kind of recursive regex syntax (e.g. removing whitespaces and special chars, replacing characters, extracting only a customizable number of characters from the start/end of each temporary variable)
  • concatenate the temporary variables according a custom ordering and by interlaving custom characters or strings

Use case

The feature would help network administrators to automatically generate the prefix base for consistent namining of new devices when adding new devices manually.
At the moment if a network operator needs to create a consistent naming for devices he needs to track outside Netbox and share with other network operators the rules to be used manually for generating the device names based on tenant/site/location/rack and other parameters.
At the moment the tenant/site/location/rack selectable values could be used only as hints to generate the consistent naming but these hints are not enough because they could include also infos not strictly needed for device name creation.
E.g.: a site could be named "S01 Headquarter Site" and the consistent naming should use only the "S01" part, i.e. the first 3 characters.
At the moment different network operators could generating a inconsistent prefix strings because they must calculate the prefix autonomously and by hand.
E.g.: one operator using site and location names could generate a "S01-L01" prefix while another operator could generate "S1-L1" creating inconsistency.
Providing a shared automatic common way for generating the device name prefix proposal is less error / inconsistency prone.

Database changes

None

External dependencies

None

Originally created by @e3elettronica on GitHub (Mar 21, 2024). ### NetBox version v3.7.2 ### Feature type New functionality ### Proposed functionality Add an optional button in device creation page for triggering the proposal of a string to be used as device name prefix generated using some normalization rules. The button should be close to the device name form text field. The button could be optional, visible only if a dedicated flag is set either in user or in global configuration menu. When the button is pushed, the system should collect temporary values from the other device creation page form fields, calculate a normalized device name prefix and pre-populate the new device name form text field with the proposed device name prefix. After pushing button, if the generated string is acceptable, the operator just needs to add the trailing part of the device name in order to make it unique before creating the device instance. The device name prefix generation and proposal should work only on-demand by pushing the button. The device name prefix calculation could be based on: - a predefined rule - a custom rule If the device name prefix calculation is based on a predefined rule it could use the tenant/site/location/rack field temporary values and it could concatenate them (es. tenantval-siteval-locationval-rackval) in order to create the proposed string. It is not the best option because some of these values could need to be sanitized or normalized or simplified. If the device name prefix calculation is based on a custom rule it should be base on a script provided either by the administrator (for all the server) or by the user (for his own session). The device name prefix calculation script should be able to: - extract temporary variables values from all device creation page form fields temporary values (both text fields and selectable fields) - modify each temporary variables values using some kind of recursive regex syntax (e.g. removing whitespaces and special chars, replacing characters, extracting only a customizable number of characters from the start/end of each temporary variable) - concatenate the temporary variables according a custom ordering and by interlaving custom characters or strings ### Use case The feature would help network administrators to automatically generate the prefix base for consistent namining of new devices when adding new devices manually. At the moment if a network operator needs to create a consistent naming for devices he needs to track outside Netbox and share with other network operators the rules to be used manually for generating the device names based on tenant/site/location/rack and other parameters. At the moment the tenant/site/location/rack selectable values could be used only as hints to generate the consistent naming but these hints are not enough because they could include also infos not strictly needed for device name creation. E.g.: a site could be named "S01 Headquarter Site" and the consistent naming should use only the "S01" part, i.e. the first 3 characters. At the moment different network operators could generating a inconsistent prefix strings because they must calculate the prefix autonomously and by hand. E.g.: one operator using site and location names could generate a "S01-L01" prefix while another operator could generate "S1-L1" creating inconsistency. Providing a shared automatic common way for generating the device name prefix proposal is less error / inconsistency prone. ### Database changes None ### External dependencies None
adam added the type: feature label 2025-12-29 20:49:08 +01:00
adam closed this issue 2025-12-29 20:49:08 +01:00
adam commented 2025-12-29 20:49:09 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 21, 2024):

What you're describing is largely bespoke logic that would not be appropriate (and likely not even feasible) to implement in the core product. However, you can very easily write a custom script to achieve the functionality you describe.

@jeremystretch commented on GitHub (Mar 21, 2024): What you're describing is largely bespoke logic that would not be appropriate (and likely not even feasible) to implement in the core product. However, you can very easily write a [custom script](https://docs.netbox.dev/en/stable/customization/custom-scripts/) to achieve the functionality you describe.
adam commented 2025-12-29 20:49:09 +01:00
Author
Owner
Copy Link

@e3elettronica commented on GitHub (Mar 21, 2024):

I'm sorry but I disagree with the fact you could implement this feature easily using custom scripts only.
The way custom scripts are concieved is very basic / single-transaction-minded and the way they are executed by the core Netbox UI is quite limited.
I understand that these limitations are because core UI and custom scripts are different and almost indipendent components and the latters should be able to be run without core UI (e.g. by API).
When using the core Netbox UI to run a custom script it is not possible to have the UI dynamically changing the value of any text field value in the UI form before submitting the whole form like on the contrary happens for slug text field during new DeviceType creation.
When using the core Netbox UI to run a custom script it is not possible to chain the running of a second custom script, using the output of the first script for pre-populating form variables for the second script.
For emulating a very simple multi-stage form in order to run two or more custom scripts in chain you need to write a whole new UI outside Netbox by using API.
In this perspective the most of the core Netbox UI is not attractive if you cannot customize it at least a bit and you need to re-implement it from the scratch outside Netbox for any minor change (exporting also the whole user login part in order to know to preserve permissions).
I understand keeping safe the core database models and interaction through well defined function call and APIs.
I don't undestand why this severe strictness in every aspect of the UI too.
Being compelled to re-implement from the scratch either outside Netbox or in a new plugin what is already 90% implemented in the core UI for me is a waste of time.

@e3elettronica commented on GitHub (Mar 21, 2024): I'm sorry but I disagree with the fact you could implement this feature easily using custom scripts only. The way custom scripts are concieved is very basic / single-transaction-minded and the way they are executed by the core Netbox UI is quite limited. I understand that these limitations are because core UI and custom scripts are different and almost indipendent components and the latters should be able to be run without core UI (e.g. by API). When using the core Netbox UI to run a custom script it is not possible to have the UI dynamically changing the value of any text field value in the UI form before submitting the whole form like on the contrary happens for slug text field during new DeviceType creation. When using the core Netbox UI to run a custom script it is not possible to chain the running of a second custom script, using the output of the first script for pre-populating form variables for the second script. For emulating a very simple multi-stage form in order to run two or more custom scripts in chain you need to write a whole new UI outside Netbox by using API. In this perspective the most of the core Netbox UI is not attractive if you cannot customize it at least a bit and you need to re-implement it from the scratch outside Netbox for any minor change (exporting also the whole user login part in order to know to preserve permissions). I understand keeping safe the core database models and interaction through well defined function call and APIs. I don't undestand why this severe strictness in every aspect of the UI too. Being compelled to re-implement from the scratch either outside Netbox or in a new plugin what is already 90% implemented in the core UI for me is a waste of time.
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 type: feature
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#9377
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?