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

Constraints for which devices get Custom Fields #6053

New Issue
Closed
opened 2025-12-29 19:36:06 +01:00 by adam · 8 comments
adam commented 2025-12-29 19:36:06 +01:00
Owner
Copy Link

Originally created by @lamoni on GitHub (Feb 4, 2022).

NetBox version

v3.1.7

Feature type

Change to existing functionality

Proposed functionality

I think taking the "constraints" functionality we have for Groups/permissions and applying it to Custom Fields (possibly other things) would be great. As an example, I'd like to be able to constrain which devices get certain custom fields: cable managers get created as "Devices" in netbox just the same as Network devices, so when one team might want a custom field for dcim->device that is applicable to "cable managers", but then network devices also have that custom field now. Multiply this by 10 teams using the same Netbox instance and you get a lot of custom fields where maybe 10% of them are actually applicable/sensical for the device you're looking at.

Use case

This functionality would clean up Custom Fields for multi-team netbox instances. Our example is: we've got asset management, VM teams, netops, etc... all using netbox, and all teams have various requirements for custom fields. Unfortunately that means a Network device (e.g. Juniper) has custom field options like "K8s instance". Makes no sense and we don't seem to have a way to limit which devices get those custom fields applied to them.

Database changes

I'm unsure of what changes need to happen for the DB.

External dependencies

No response

Originally created by @lamoni on GitHub (Feb 4, 2022). ### NetBox version v3.1.7 ### Feature type Change to existing functionality ### Proposed functionality I think taking the "constraints" functionality we have for Groups/permissions and applying it to Custom Fields (possibly other things) would be great. As an example, I'd like to be able to constrain which devices get certain custom fields: cable managers get created as "Devices" in netbox just the same as Network devices, so when one team might want a custom field for dcim->device that is applicable to "cable managers", but then network devices also have that custom field now. Multiply this by 10 teams using the same Netbox instance and you get a lot of custom fields where maybe 10% of them are actually applicable/sensical for the device you're looking at. ### Use case This functionality would clean up Custom Fields for multi-team netbox instances. Our example is: we've got asset management, VM teams, netops, etc... all using netbox, and all teams have various requirements for custom fields. Unfortunately that means a Network device (e.g. Juniper) has custom field options like "K8s instance". Makes no sense and we don't seem to have a way to limit which devices get those custom fields applied to them. ### Database changes I'm unsure of what changes need to happen for the DB. ### External dependencies _No response_
adam added the type: feature label 2025-12-29 19:36:06 +01:00
adam closed this issue 2025-12-29 19:36:06 +01:00
adam commented 2025-12-29 19:36:07 +01:00
Author
Owner
Copy Link

@lamoni commented on GitHub (Feb 4, 2022):

I should mention, even if the Constraints just hid those custom fields (i.e. the custom field still exists for that device in the backend, it just isn't visible on the frontend), that would be ideal. So even just a "viewable" constraint would be a big improvement.

@lamoni commented on GitHub (Feb 4, 2022): I should mention, even if the Constraints just hid those custom fields (i.e. the custom field still exists for that device in the backend, it just isn't visible on the frontend), that would be ideal. So even just a "viewable" constraint would be a big improvement.
adam commented 2025-12-29 19:36:08 +01:00
Author
Owner
Copy Link

@AnythingOverIP commented on GitHub (Feb 15, 2022):

This would be helpful! It could extend to other fields like described in https://github.com/netbox-community/netbox/issues/5777

@AnythingOverIP commented on GitHub (Feb 15, 2022): This would be helpful! It could extend to other fields like described in https://github.com/netbox-community/netbox/issues/5777
adam commented 2025-12-29 19:36:09 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 18, 2022):

Any volunteers to develop a proof of concept?

@jeremystretch commented on GitHub (Feb 18, 2022): Any volunteers to develop a proof of concept?
adam commented 2025-12-29 19:36:09 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Feb 18, 2022):

@jeremystretch - A different solution to the same problem, that I actually implemented but never got around to creating a FR for, is just adding a "Hide when empty" option to custom fields. If it is toggled, empty fields are hidden from display, but still visible when editing the object.

It's a lot simpler to implement at least (just add one field to the model and some if statements to the templates). Not sure it satisfies the original intent of the FR though. What do you think of that solution @lamoni?

@kkthxbye-code commented on GitHub (Feb 18, 2022): @jeremystretch - A different solution to the same problem, that I actually implemented but never got around to creating a FR for, is just adding a "Hide when empty" option to custom fields. If it is toggled, empty fields are hidden from display, but still visible when editing the object. It's a lot simpler to implement at least (just add one field to the model and some if statements to the templates). Not sure it satisfies the original intent of the FR though. What do you think of that solution @lamoni?
adam commented 2025-12-29 19:36:09 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Apr 20, 2022):

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. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Apr 20, 2022): 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. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 19:36:09 +01:00
Author
Owner
Copy Link

@AnythingOverIP commented on GitHub (Apr 20, 2022):

@jeremystretch , is @kkthxbye-code approach would work?

@AnythingOverIP commented on GitHub (Apr 20, 2022): @jeremystretch , is @kkthxbye-code approach would work?
adam commented 2025-12-29 19:36:09 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 27, 2022):

I think there's some overlap between @kkthxbye-code's idea above and what was proposed in #9166. It's probably best to continue discussion of the "hiding" approach under #9166.

@jeremystretch commented on GitHub (Apr 27, 2022): I think there's some overlap between @kkthxbye-code's idea above and what was proposed in #9166. It's probably best to continue discussion of the "hiding" approach under #9166.
adam commented 2025-12-29 19:36:10 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 4, 2022):

I think taking the "constraints" functionality we have for Groups/permissions and applying it to Custom Fields (possibly other things) would be great.

These do not work the same as what's being proposed here. With permissions, constraints are determined by the permissions assigned to the user (and/or its group) associated with the request, and applied to queries for objects. What you describe above is the inverse: Starting with an object and then determining which custom fields to display based on constraints applied to each custom field, rather than the object. This is not feasible using the approach we employ for permissions enforcement.

I'm going to close this issue for two reasons:

  1. A detailed, feasible implementation has not been proposed.
  2. Once implemented, #9166 should mostly obviate the need for any more complex logic to omit custom fields.

That said, if anyone would like to submit a new FR outlining a detailed, workable implementation for such functionality, please feel welcome to do so.

@jeremystretch commented on GitHub (May 4, 2022): > I think taking the "constraints" functionality we have for Groups/permissions and applying it to Custom Fields (possibly other things) would be great. These do not work the same as what's being proposed here. With permissions, constraints are determined by the permissions assigned to the user (and/or its group) associated with the request, and applied to queries for objects. What you describe above is the inverse: Starting with an object and then determining which custom fields to display based on constraints applied to each custom field, rather than the object. This is not feasible using the approach we employ for permissions enforcement. I'm going to close this issue for two reasons: 1. A detailed, feasible implementation has not been proposed. 2. Once implemented, #9166 should mostly obviate the need for any more complex logic to omit custom fields. That said, if anyone would like to submit a new FR outlining a **detailed, workable implementation** for such functionality, please feel welcome to do so.
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#6053
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?