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 Field UI - hidden if unset - independent of rw/ro #8381

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

Originally created by @whtkam on GitHub (Jul 29, 2023).

Originally assigned to: @jeremystretch on GitHub.

NetBox version

v3.5.7

Feature type

Change to existing functionality

Proposed functionality

I have many custom fields which only apply to a part of e.g. devices. With the "UI visibility" = "Hidden(if unset)" you can keep the UI clean for each device and you only see those that are set for the device. The problem and hence the feature reqest the "if unset" option should be independent of "Read/Write" or "Read only" option.

UI visibility:

  • Read/Write
  • Read/Write(if unset)
  • Read-only
  • Read-only(if unset)
  • Hidden

or maybe with a checkbox

UI visibility:

  • Read/Write

  • Read-only

  • Hidden

  • Hidden if unset

Use case

I have custom fields that are Ready-only but I don't want them to appear in the UI on every device as they have no meaning for those devices. So it would be good if I could select read-only and "hidden if unset". Maybe there is another way to achieve this, but I haven't found any.

Database changes

No response

External dependencies

No response

Originally created by @whtkam on GitHub (Jul 29, 2023). Originally assigned to: @jeremystretch on GitHub. ### NetBox version v3.5.7 ### Feature type Change to existing functionality ### Proposed functionality I have many custom fields which only apply to a part of e.g. devices. With the "UI visibility" = "Hidden(if unset)" you can keep the UI clean for each device and you only see those that are set for the device. The problem and hence the feature reqest the "if unset" option should be independent of "Read/Write" or "Read only" option. **UI visibility:** - Read/Write - Read/Write(if unset) - Read-only - Read-only(if unset) - Hidden or maybe with a checkbox **UI visibility:** - Read/Write - Read-only - Hidden - [ ] Hidden if unset ### Use case I have custom fields that are Ready-only but I don't want them to appear in the UI on every device as they have no meaning for those devices. So it would be good if I could select read-only and "hidden if unset". Maybe there is another way to achieve this, but I haven't found any. ### Database changes _No response_ ### External dependencies _No response_
adam added the status: acceptedtype: feature labels 2025-12-29 20:36:01 +01:00
adam closed this issue 2025-12-29 20:36:01 +01:00
adam commented 2025-12-29 20:36:02 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Oct 28, 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 (Oct 28, 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:36:02 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 16, 2023):

I'm going to propose replacing the current ui_visibility field with two new fields:

  • ui_editable (boolean): True or false
  • ui_visible (choice): Always, if set, hidden

The former will control whether the custom field value can be modified using the web UI; the later will control whether a custom field is displayed in the web UI. As with the current field, neither will have any impact on REST or GraphQL API operation.

This will obviously result in a breaking API change, but we'll be able to migrate existing custom fields automatically.

@jeremystretch commented on GitHub (Nov 16, 2023): I'm going to propose replacing the current `ui_visibility` field with two new fields: * `ui_editable` (boolean): True or false * `ui_visible` (choice): Always, if set, hidden The former will control whether the custom field value can be modified using the web UI; the later will control whether a custom field is displayed in the web UI. As with the current field, neither will have any impact on REST or GraphQL API operation. This will obviously result in a breaking API change, but we'll be able to migrate existing custom fields automatically.
adam commented 2025-12-29 20:36:02 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 16, 2023):

Thinking about this further, it might make sense to give ui_editable three options:

  • Yes
  • No
  • Hidden

Selecting "no" would still include the custom field in the object edit form with a read-only (disabled) widget. Selecting "hidden" would omit it completely.

@jeremystretch commented on GitHub (Nov 16, 2023): Thinking about this further, it might make sense to give `ui_editable` three options: * Yes * No * Hidden Selecting "no" would still include the custom field in the object edit form with a read-only (disabled) widget. Selecting "hidden" would omit it completely.
adam commented 2025-12-29 20:36:02 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Nov 16, 2023):

I just ran into this yesterday and was surprised that setting a custom field to readonly still showed it in the add/edit form, just in a readonly state. To me, the proposed No and Hidden options for ui_editable would be the same thing, but I'm curious what others' use case is for showing readonly fields within the add/edit form, if their value cannot be changed there.

Regardless, the proposed Hidden option would certainly be an improvement over the current situation, as there is apparently no way currently to have a field show in the UI, but not on the edit screen, so if you have big JSON fields that can only set by script/API, you have to keep scrolling over them every time you want to add/edit an object.

@sleepinggenius2 commented on GitHub (Nov 16, 2023): I just ran into this yesterday and was surprised that setting a custom field to readonly still showed it in the add/edit form, just in a readonly state. To me, the proposed No and Hidden options for `ui_editable` would be the same thing, but I'm curious what others' use case is for showing readonly fields within the add/edit form, if their value cannot be changed there. Regardless, the proposed Hidden option would certainly be an improvement over the current situation, as there is apparently no way currently to have a field show in the UI, but not on the edit screen, so if you have big JSON fields that can only set by script/API, you have to keep scrolling over them every time you want to add/edit an object.
adam commented 2025-12-29 20:36:03 +01:00
Author
Owner
Copy Link

@AnythingOverIP commented on GitHub (Nov 16, 2023):

I would looooooove if this could also apply to other default fields showed in UI, as described in https://github.com/netbox-community/netbox/issues/5777 .

@AnythingOverIP commented on GitHub (Nov 16, 2023): I would looooooove if this could also apply to other default fields showed in UI, as described in https://github.com/netbox-community/netbox/issues/5777 .
adam commented 2025-12-29 20:36:03 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 16, 2023):

I'm curious what others' use case is for showing readonly fields within the add/edit form, if their value cannot be changed there.

For me it's about providing consistency. A user may be confused if they see a custom field displayed in the UI but absent in the object edit form. Rendering it as a disabled form field provides assurance that the field is not "missing." Some administrators still may prefer to omit it from the form anyway, so we provide both options.

@jeremystretch commented on GitHub (Nov 16, 2023): > I'm curious what others' use case is for showing readonly fields within the add/edit form, if their value cannot be changed there. For me it's about providing consistency. A user may be confused if they see a custom field displayed in the UI but absent in the object edit form. Rendering it as a disabled form field provides assurance that the field is not "missing." Some administrators still may prefer to omit it from the form anyway, so we provide both options.
adam commented 2025-12-29 20:36:03 +01:00
Author
Owner
Copy Link

@cpund commented on GitHub (Nov 16, 2023):

Could I suggest another option to ui_visible? It'd be nice to have a field hidden when viewing (not editing) a device? While not a huge necessity, it's nice to clean out some cruft when just viewing the device. My use case for this is when creating a device, I've got a custom field that stores the SolarWinds NodeID of a device. This field powers the custom link to link directly to the monitoring page for the device. Something like this custom field doesn't need to be shown when just viewing a device.

Edit: Re-readings things, maybe I'm still waking up and the intention for this was when viewing a device, not editing. In which case, sounds like my input is already covered.

@cpund commented on GitHub (Nov 16, 2023): Could I suggest another option to `ui_visible`? It'd be nice to have a field hidden when viewing (not editing) a device? While not a huge necessity, it's nice to clean out some cruft when just viewing the device. My use case for this is when creating a device, I've got a custom field that stores the SolarWinds NodeID of a device. This field powers the custom link to link directly to the monitoring page for the device. Something like this custom field doesn't need to be shown when just viewing a device. Edit: Re-readings things, maybe I'm still waking up and the intention for this was when viewing a device, not editing. In which case, sounds like my input is already covered.
adam commented 2025-12-29 20:36:03 +01:00
Author
Owner
Copy Link

@mmahacek commented on GitHub (Nov 16, 2023):

What about these settings?

  • ui_editmode (choice): Read/Write, Read-Only, hidden
  • ui_viewmode (choice): Always, if set, hidden
@mmahacek commented on GitHub (Nov 16, 2023): What about these settings? - `ui_editmode` (choice): Read/Write, Read-Only, hidden - `ui_viewmode` (choice): Always, if set, hidden
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#8381
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?