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

Potential to limit Custom Field visibility using constraints #4838

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

Originally created by @darcynz on GitHub (Apr 28, 2021).

NetBox version

v2.11

Feature type

New functionality

Proposed functionality

Be able to hide custom fields, similar to how permissions constraints work.

So that its possible to show custom fields only when relevant to a use case.

Use case

One of the challenges to ensuring an accurate source of truth is ensuring that relevant data is captured consistently.
Custom fields allow data to be captured relevant to the use cases of an organization. However when a custom field is used it then presents on all instances of the objects.

Users can be confused by this, thinking that there is an expectation that data should be entered for the object.

For example if we wanted to capture information for Cisco devices only, this data would appear on all makes and models.
Solution proposed would allow the custom field to be constrained so that the field only appears where the manufacturer = cisco.

Database changes

Should be able to use the existing database schema.

External dependencies

None

Originally created by @darcynz on GitHub (Apr 28, 2021). ### NetBox version v2.11 ### Feature type New functionality ### Proposed functionality Be able to hide custom fields, similar to how permissions constraints work. So that its possible to show custom fields only when relevant to a use case. ### Use case One of the challenges to ensuring an accurate source of truth is ensuring that relevant data is captured consistently. Custom fields allow data to be captured relevant to the use cases of an organization. However when a custom field is used it then presents on all instances of the objects. Users can be confused by this, thinking that there is an expectation that data should be entered for the object. For example if we wanted to capture information for Cisco devices only, this data would appear on all makes and models. Solution proposed would allow the custom field to be constrained so that the field only appears where the manufacturer = cisco. ### Database changes Should be able to use the existing database schema. ### External dependencies None
adam added the type: featurepending closure labels 2025-12-29 19:21:07 +01:00
adam closed this issue 2025-12-29 19:21:07 +01:00
adam commented 2025-12-29 19:21:08 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 29, 2021):

The purpose of custom fields is to extend the stock data model for each object. If you have a piece of data that applies only to a certain subset of objects, a custom field probably isn't the best solution.

Be able to hide custom fields, similar to how permissions constraints work.

Permission constraints work by querying the database for objects that meet a specific set of constraints. What you're proposing is the inverse, where you've already retrieved an object, and want to figure out what constraints apply to it from the set of available custom fields. I don't know how this would even be feasible, let alone worth the performance penalty.

I'm sorry but I just don't see this being a worthwhile investment of effort when the existing alternative is to simply leave the custom field empty.

@jeremystretch commented on GitHub (Apr 29, 2021): The purpose of custom fields is to extend the stock data model for each object. If you have a piece of data that applies only to a certain subset of objects, a custom field probably isn't the best solution. > Be able to hide custom fields, similar to how permissions constraints work. Permission constraints work by querying the database for objects that meet a specific set of constraints. What you're proposing is the inverse, where you've already retrieved an object, and want to figure out what constraints apply to it from the set of available custom fields. I don't know how this would even be feasible, let alone worth the performance penalty. I'm sorry but I just don't see this being a worthwhile investment of effort when the existing alternative is to simply leave the custom field empty.
adam commented 2025-12-29 19:21:08 +01:00
Author
Owner
Copy Link

@darcynz commented on GitHub (May 3, 2021):

Yes I wasn't sure how you would achieve the use case, but used the permission constraint as an example.

I guess the proposal is a form of input validation, which is a deeper problem and the solution to that can just be for the user to input better data!

@darcynz commented on GitHub (May 3, 2021): Yes I wasn't sure how you would achieve the use case, but used the permission constraint as an example. I guess the proposal is a form of input validation, which is a deeper problem and the solution to that can just be for the user to input better data!
adam commented 2025-12-29 19:21:08 +01:00
Author
Owner
Copy Link

@jcralbino commented on GitHub (May 3, 2021):

Maybe for this use case it will be enough to add an additional check when displaying the device information.

For example if custom field is empty then this field should not be shown in the device page.

The custom field will be shown in the edit page, but not in the the normal device page used for the visualization.
Although i do not know the full picture behind the scenes, i believe this will be an easy check to make that will have little impact in other areas.

@jcralbino commented on GitHub (May 3, 2021): Maybe for this use case it will be enough to add an additional check when displaying the device information. For example if custom field is empty then this field should not be shown in the device page. The custom field will be shown in the edit page, but not in the the normal device page used for the visualization. Although i do not know the full picture behind the scenes, i believe this will be an easy check to make that will have little impact in other areas.
adam commented 2025-12-29 19:21:08 +01:00
Author
Owner
Copy Link

@jcralbino commented on GitHub (May 4, 2021):

It seems a similar feature was proposed here
https://github.com/netbox-community/netbox/issues/6103

The main goal being that limiting the custom field visibility in the corresponding object page would be interesting to achieve
Could we check if field is empty before showing it will allow to simplify this and achieve the necessary scale ?
@jeremystretch

@jcralbino commented on GitHub (May 4, 2021): It seems a similar feature was proposed here https://github.com/netbox-community/netbox/issues/6103 The main goal being that limiting the custom field visibility in the corresponding object page would be interesting to achieve Could we check if field is empty before showing it will allow to simplify this and achieve the necessary scale ? @jeremystretch
adam commented 2025-12-29 19:21:09 +01:00
Author
Owner
Copy Link

@darcynz commented on GitHub (May 4, 2021):

If it was a feature you could enable on a custom field where required (eg data that is not always appropriate), hiding the data unless populated could work well.

@darcynz commented on GitHub (May 4, 2021): If it was a feature you could enable on a custom field where required (eg data that is not always appropriate), hiding the data unless populated could work well.
adam commented 2025-12-29 19:21:09 +01:00
Author
Owner
Copy Link

@jcralbino commented on GitHub (May 19, 2021):

@darcynz if you think that providing the visibility in the gui only if the field is populated, is enough also for your use case , can you adapt the request here or should we open a different one stating that implementation option?

@jcralbino commented on GitHub (May 19, 2021): @darcynz if you think that providing the visibility in the gui only if the field is populated, is enough also for your use case , can you adapt the request here or should we open a different one stating that implementation option?
adam commented 2025-12-29 19:21:09 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jul 19, 2021):

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 (Jul 19, 2021): 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:21:09 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Aug 18, 2021):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (Aug 18, 2021): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
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 pending closure 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#4838
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?