Allow hiding custom fields in UI

[PieterL75]

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

[jeremystretch]

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?

[PieterL75]

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

[proudbro]

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

[jeremystretch]

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.

[PieterL75]

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.

[jeremystretch]

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.

[PieterL75]

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

[pgnuta]

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.

[jeremypng]

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?

[kkthxbye-code]

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.

[phurrelmann]

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

[kkthxbye-code]

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.

[jeremystretch]

Thanks @kkthxbye-code!

[proudbro]

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