Read Only Interface Custom Fields #3625

New Issue

adam · 2025-12-29T18:30:15+01:00

adam commented

2025-12-29 18:30:15 +01:00

Originally created by @nerdbaggy on GitHub (Apr 30, 2020).

Environment

Python version: 3.6.5
NetBox version: 2.8.1

Proposed Functionality

It would be great to have a field as a custom field to be ready only in the web interface, but not the API. Like in the Django Admin the

readonly_fields = []

https://docs.djangoproject.com/en/3.0/ref/contrib/admin/#django.contrib.admin.ModelAdmin.readonly_fields

Use Case

We integrate a lot of things into netbox, like our RDNS stuff. Have a field that a user can't change that we can put things like the RDNS record, its A record, if its been synced, things like that. We don't want the users/admin to be able to change them. Its all done via API calls.

Database Changes

The only change I can think of is a field on the custom fields model that is like is_readonly = True/False default False

External Dependencies

None

Originally created by @nerdbaggy on GitHub (Apr 30, 2020). ### Environment * Python version: 3.6.5 * NetBox version: 2.8.1 ### Proposed Functionality It would be great to have a field as a custom field to be ready only in the web interface, but not the API. Like in the Django Admin the ``` readonly_fields = [] ``` https://docs.djangoproject.com/en/3.0/ref/contrib/admin/#django.contrib.admin.ModelAdmin.readonly_fields ### Use Case We integrate a lot of things into netbox, like our RDNS stuff. Have a field that a user can't change that we can put things like the RDNS record, its A record, if its been synced, things like that. We don't want the users/admin to be able to change them. Its all done via API calls. ### Database Changes The only change I can think of is a field on the custom fields model that is like is_readonly = True/False default False ### External Dependencies None

adam closed this issue

2025-12-29 18:30:15 +01:00

adam commented

2025-12-29 18:30:15 +01:00

@jeremystretch commented on GitHub (Apr 30, 2020):

The REST API and web interface are intended to have parity. (I realize that is not currently the case, however it is a long-term design goal.) Thus, it would not make sense to enforce different validation logic for the two interfaces.

@jeremystretch commented on GitHub (Apr 30, 2020): The REST API and web interface are intended to have parity. (I realize that is not currently the case, however it is a long-term design goal.) Thus, it would not make sense to enforce different validation logic for the two interfaces.

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#3625