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

Allow hiding custom fields in UI #6377

New Issue
Closed
opened 2025-12-29 19:39:59 +01:00 by adam · 14 comments
adam commented 2025-12-29 19:39:59 +01:00
Owner
Copy Link

Originally created by @PieterL75 on GitHub (Apr 19, 2022).

Originally assigned to: @kkthxbye-code on GitHub.

NetBox version

v3.2

Feature type

Change to existing functionality

Proposed functionality

Provide a 'ReadOnly' checkbox to custom fields.
If a checkbox is readonly, then the user is not able to edit/update the field, when editing an object.

Use case

Fields that are populated by automation, should not be editable by end users.
(ex: vcenter, prefix utilization, ...)

Database changes

New Boolean field on the custom fields.

External dependencies

No response

Originally created by @PieterL75 on GitHub (Apr 19, 2022). Originally assigned to: @kkthxbye-code on GitHub. ### NetBox version v3.2 ### Feature type Change to existing functionality ### Proposed functionality Provide a 'ReadOnly' checkbox to custom fields. If a checkbox is readonly, then the user is not able to edit/update the field, when editing an object. ### Use case Fields that are populated by automation, should not be editable by end users. (ex: vcenter, prefix utilization, ...) ### Database changes New Boolean field on the custom fields. ### External dependencies _No response_
adam added the status: acceptedtype: feature labels 2025-12-29 19:39:59 +01:00
adam closed this issue 2025-12-29 19:39:59 +01:00
adam commented 2025-12-29 19:40:00 +01:00
Author
Owner
Copy Link

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

Fields that are populated by automation, should not be editable by end users.

How are you distinguishing between a human user and a system user?

@jeremystretch commented on GitHub (Apr 19, 2022): > Fields that are populated by automation, should not be editable by end users. How are you distinguishing between a human user and a system user?
adam commented 2025-12-29 19:40:00 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Apr 19, 2022):

We have some scripts that run regularly (contact import for ex), and some that are triggered (prefix utilization calculation) and external scripts that push data into Netbox using API calls.
On the other hand, we have fields on devices (hardwaretag, escalation levels, ...) that are entered manually.

There is no way to 'predefine' what fields are human and what are autopopulated.
But if I can set the readonly-flag then the Edit form will be less cluttered with fields that users are not allowed to edit/change

@PieterL75 commented on GitHub (Apr 19, 2022): We have some scripts that run regularly (contact import for ex), and some that are triggered (prefix utilization calculation) and external scripts that push data into Netbox using API calls. On the other hand, we have fields on devices (hardwaretag, escalation levels, ...) that are entered manually. There is no way to 'predefine' what fields are human and what are autopopulated. But if I can set the readonly-flag then the Edit form will be less cluttered with fields that users are not allowed to edit/change
adam commented 2025-12-29 19:40:01 +01:00
Author
Owner
Copy Link

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

I've created the similar issue
IMO useful functionality for external integrations

@proudbro commented on GitHub (Apr 20, 2022): I've created the similar [issue](https://github.com/netbox-community/netbox/issues/6677) IMO useful functionality for external integrations
adam commented 2025-12-29 19:40:01 +01:00
Author
Owner
Copy Link

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

But if I can set the readonly-flag then the Edit form will be less cluttered with fields that users are not allowed to edit/change

I think you're missing my question. What would prevent a human user from modifying a "read-only" custom field e.g. via the REST API, while permitting the change from a system user? It's not sufficient to just omit the custom field from the object edit form.

@jeremystretch commented on GitHub (Apr 20, 2022): > But if I can set the readonly-flag then the Edit form will be less cluttered with fields that users are not allowed to edit/change I think you're missing my question. What would prevent a human user from modifying a "read-only" custom field e.g. via the REST API, while permitting the change from a system user? It's not sufficient to just omit the custom field from the object edit form.
adam commented 2025-12-29 19:40:01 +01:00
Author
Owner
Copy Link

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

Good point.. In my case, no users have write api keys, only read..
The service accounts are the only ones with Write API keys.

But that's of course not something that can be generalized.
I can think of some options, but those introduce extra rights to be assigned to custom fields.. and that's not sustainable I think.

I guess that in 80% of the use cases, that it is fine to block the access in the GUI and leave it modifiable using the API keys for anyone.

@PieterL75 commented on GitHub (Apr 20, 2022): Good point.. In my case, no users have write api keys, only read.. The service accounts are the only ones with Write API keys. But that's of course not something that can be generalized. I can think of some options, but those introduce extra rights to be assigned to custom fields.. and that's not sustainable I think. I guess that in 80% of the use cases, that it is fine to block the access in the GUI and leave it modifiable using the API keys for anyone.
adam commented 2025-12-29 19:40:01 +01:00
Author
Owner
Copy Link

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

I think the key here is not referring to them as "read-only" fields, but by some other name that more accurately conveys the fact that they're not editable via the UI. It's a subtle but important distinction.

Maybe introduce an "editable via UI" flag (better name TBD) which defaults to true. If set to false, the field won't be editable in the UI, but it will have no impact on changes made via the API.

@jeremystretch commented on GitHub (Apr 20, 2022): I think the key here is not referring to them as "read-only" fields, but by some other name that more accurately conveys the fact that they're not editable via the UI. It's a subtle but important distinction. Maybe introduce an "editable via UI" flag (better name TBD) which defaults to true. If set to false, the field won't be editable in the UI, but it will have no impact on changes made via the API.
adam commented 2025-12-29 19:40:01 +01:00
Author
Owner
Copy Link

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

Sounds like a good approach !
Maybe 'Only updatable via API'

@PieterL75 commented on GitHub (Apr 20, 2022): Sounds like a good approach ! Maybe 'Only updatable via API'
adam commented 2025-12-29 19:40:01 +01:00
Author
Owner
Copy Link

@pgnuta commented on GitHub (Apr 21, 2022):

I'd like to suggest a three-way choice option for the custom field:

Name: "Web UI Display"
Description: "The ability to edit or display the field to users in the web UI, read/write access is always available via API and custom scripts"
Choices: "Read / Write", "Read only", "Invisible"
Default: "Read / Write"

This choice would affect the display in object lists as well as on the add/edit form.

@pgnuta commented on GitHub (Apr 21, 2022): I'd like to suggest a three-way choice option for the custom field: Name: "Web UI Display" Description: "The ability to edit or display the field to users in the web UI, read/write access is always available via API and custom scripts" Choices: "Read / Write", "Read only", "Invisible" Default: "Read / Write" This choice would affect the display in object lists as well as on the add/edit form.
adam commented 2025-12-29 19:40:02 +01:00
Author
Owner
Copy Link

@jeremypng commented on GitHub (May 11, 2022):

Would it be possible as part of this feature to allow you to specify what device-types to display the field on if the custom field is assigned to a device object?

@jeremypng commented on GitHub (May 11, 2022): Would it be possible as part of this feature to allow you to specify what device-types to display the field on if the custom field is assigned to a device object?
adam commented 2025-12-29 19:40:02 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (May 23, 2022):

I'm working on this currently. Just need to clean it up and add whatever stuff I missed. I'll create a PR when done to gather feedback.

@kkthxbye-code commented on GitHub (May 23, 2022): I'm working on this currently. Just need to clean it up and add whatever stuff I missed. I'll create a PR when done to gather feedback.
adam commented 2025-12-29 19:40:02 +01:00
Author
Owner
Copy Link

@phurrelmann commented on GitHub (May 24, 2022):

Just a quick idea to make the hiding more natural the "netbox way": could the hiding and/or read-write be handled with jinja2? that way a user would be able to decide based on objects/contents if a custom fields need to be disabled or is editable

@phurrelmann commented on GitHub (May 24, 2022): Just a quick idea to make the hiding more natural the "netbox way": could the hiding and/or read-write be handled with jinja2? that way a user would be able to decide based on objects/contents if a custom fields need to be disabled or is editable
adam commented 2025-12-29 19:40:02 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (May 24, 2022):

The implementation will be based on @pgnuta's reply.

Not sure I understand exactly what you are suggesting @phurrelmann. Like a text field where you can write template code? And then what? Is the template code rendered in place of the custom field display both on objects and in edit/create forms? It seems very different than what was suggested in this FR.

@kkthxbye-code commented on GitHub (May 24, 2022): The implementation will be based on @pgnuta's reply. Not sure I understand exactly what you are suggesting @phurrelmann. Like a text field where you can write template code? And then what? Is the template code rendered in place of the custom field display both on objects and in edit/create forms? It seems very different than what was suggested in this FR.
adam commented 2025-12-29 19:40:03 +01:00
Author
Owner
Copy Link

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

Thanks @kkthxbye-code!

@jeremystretch commented on GitHub (May 24, 2022): Thanks @kkthxbye-code!
adam commented 2025-12-29 19:40:03 +01:00
Author
Owner
Copy Link

@proudbro commented on GitHub (Aug 2, 2022):

@jeremystretch , you can link it with this issue as well

@proudbro commented on GitHub (Aug 2, 2022): @jeremystretch , you can link it with [this issue](https://github.com/netbox-community/netbox/issues/6677) as well
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 status: accepted 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#6377
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?