Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom Field UI - hidden if unset - independent of rw/ro #13299

Closed
1 task
whtkam opened this issue Jul 29, 2023 · 8 comments
Closed
1 task

Custom Field UI - hidden if unset - independent of rw/ro #13299

whtkam opened this issue Jul 29, 2023 · 8 comments
Assignees
Labels
status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application
Milestone

Comments

@whtkam
Copy link

whtkam commented Jul 29, 2023

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

@whtkam whtkam added the type: feature Introduction of new functionality to the application label Jul 29, 2023
@abhi1693 abhi1693 added the status: under review Further discussion is needed to determine this issue's scope and/or implementation label Jul 29, 2023
@github-actions
Copy link
Contributor

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 github-actions bot added the pending closure Requires immediate attention to avoid being closed for inactivity label Oct 28, 2023
@jeremystretch jeremystretch added status: accepted This issue has been accepted for implementation and removed status: under review Further discussion is needed to determine this issue's scope and/or implementation pending closure Requires immediate attention to avoid being closed for inactivity labels Nov 6, 2023
@jeremystretch jeremystretch added this to the v3.7 milestone Nov 6, 2023
@jeremystretch jeremystretch self-assigned this Nov 6, 2023
@jeremystretch
Copy link
Member

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
Copy link
Member

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.

@sleepinggenius2
Copy link
Contributor

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.

@AnythingOverIP

This comment was marked as off-topic.

@jeremystretch
Copy link
Member

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.

@cpund
Copy link
Contributor

cpund commented 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.

@mmahacek
Copy link
Contributor

What about these settings?

  • ui_editmode (choice): Read/Write, Read-Only, hidden
  • ui_viewmode (choice): Always, if set, hidden

jeremystretch added a commit that referenced this issue Nov 20, 2023
#14289)

* Add ui_visible and ui_editable fields

* Extend migration to map new visible/editable values

* Remove ui_visibility field

* Update docs
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 19, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application
Projects
None yet
Development

No branches or pull requests

7 participants