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

Custom fields only showing by Role, Type or tags #7444

New Issue
Closed
opened 2025-12-29 20:23:33 +01:00 by adam · 3 comments
adam commented 2025-12-29 20:23:33 +01:00
Owner
Copy Link

Originally created by @chesronw on GitHub (Jan 3, 2023).

NetBox version

V3.3.5

Feature type

New functionality

Proposed functionality

It would be nice that we can define the custom fields based on for example the type or role of a device.
At this moment you can add a custom field only to a specific module in Netbox.

If there is a possibility to add an extra filter on the custom field that will be very helpful to add an custom field only for specific modules where needed.

Use case

In this use case we want to add a custom field to define the support level of a switch.
To add this custom field we can add a custom field for the module "Device" (See example below)

The problem with this is that this custom field is add to all another devices that are created.
Not every device needs this custom field. Or for other departments than the network team needs that custom field.

That is the reason that it would be nice if we have an sub filter to only show the custom field based by the role or something like that.

image

Database changes

No response

External dependencies

No response

Originally created by @chesronw on GitHub (Jan 3, 2023). ### NetBox version V3.3.5 ### Feature type New functionality ### Proposed functionality It would be nice that we can define the custom fields based on for example the type or role of a device. At this moment you can add a custom field only to a specific module in Netbox. If there is a possibility to add an extra filter on the custom field that will be very helpful to add an custom field only for specific modules where needed. ### Use case In this use case we want to add a custom field to define the support level of a switch. To add this custom field we can add a custom field for the module "Device" (See example below) The problem with this is that this custom field is add to all another devices that are created. Not every device needs this custom field. Or for other departments than the network team needs that custom field. That is the reason that it would be nice if we have an sub filter to only show the custom field based by the role or something like that. ![image](https://user-images.githubusercontent.com/85490348/210357366-3335bbb9-088f-431f-810d-2b8984ec0fc7.png) ### Database changes _No response_ ### External dependencies _No response_
adam added the type: feature label 2025-12-29 20:23:33 +01:00
adam closed this issue 2025-12-29 20:23:33 +01:00
adam commented 2025-12-29 20:23:33 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Jan 20, 2023):

Custom fields are generic - a given custom field can be linked to almost any type of object - so I don't think it makes sense to filter on Device Role or Device Type (unless "Role" were to be made completely generic and shared by all objects - there are quite a few which have some sort of "Role" already).

However, tags are also generic. Therefore, it should in principle be straightforward to bind a custom field to tags as well as object types, so that it's only displayed if an object has a particular tag present.

I'm not sure what should happen to CF data if the tag is subsequently removed from an object. Either you always display non-empty CF data; or you have to delete the custom field data when the tag is removed (dangerous); or you have to prevent the removal of the tag from an object if there is non-empty related CF data present (probably the safest option).

@candlerb commented on GitHub (Jan 20, 2023): Custom fields are generic - a given custom field can be linked to almost any type of object - so I don't think it makes sense to filter on Device Role or Device Type (unless "Role" were to be made completely generic and shared by all objects - there are quite a few which have some sort of "Role" already). However, tags are also generic. Therefore, it should in principle be straightforward to bind a custom field to tags as well as object types, so that it's only displayed if an object has a particular tag present. I'm not sure what should happen to CF data if the tag is subsequently removed from an object. Either you always display non-empty CF data; or you have to delete the custom field data when the tag is removed (dangerous); or you have to prevent the removal of the tag from an object if there is non-empty related CF data present (probably the safest option).
adam commented 2025-12-29 20:23:33 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Apr 21, 2023):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Apr 21, 2023): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 20:23:33 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 2, 2023):

I'm not sure what should happen to CF data if the tag is subsequently removed from an object. Either you always display non-empty CF data; or you have to delete the custom field data when the tag is removed (dangerous); or you have to prevent the removal of the tag from an object if there is non-empty related CF data present (probably the safest option).

The need to conditionally enable or disable custom fields based on some other object attribute is a clear signal that you've outgrown the functionality provided by custom fields, and should instead pursue a purpose-built extension to NetBox's data model via a custom plugin. Trying to hack something together using custom fields is only going to ultimately cost you more time and effort while delivering a subpar solution.

@jeremystretch commented on GitHub (May 2, 2023): > I'm not sure what should happen to CF data if the tag is subsequently removed from an object. Either you always display non-empty CF data; or you have to delete the custom field data when the tag is removed (dangerous); or you have to prevent the removal of the tag from an object if there is non-empty related CF data present (probably the safest option). The need to conditionally enable or disable custom fields based on some other object attribute is a clear signal that you've outgrown the functionality provided by custom fields, and should instead pursue a purpose-built extension to NetBox's data model via a custom plugin. Trying to hack something together using custom fields is only going to ultimately cost you more time and effort while delivering a subpar solution.
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#7444
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?