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

Error fetching options for field #5466

New Issue
Closed
opened 2025-12-29 19:28:21 +01:00 by adam · 7 comments
adam commented 2025-12-29 19:28:21 +01:00
Owner
Copy Link

Originally created by @dkm77 on GitHub (Oct 4, 2021).

NetBox version

v3.0.4

Python version

3.8

Steps to Reproduce

  • Create a new user:
    image

  • Create a new permission with full access to "DCIM -> device" and no access to other objects and assign it to the user:
    image

  • Login as the new user and open the edit dialogue for a device to see multiple overlapping error messages for the fields the user may not access:
    image

Expected Behavior

If a user is not allowed to view values of a drop down like the "site group" or "region" field, the dropdown should either not be displayed when editing a device or the error should only show when the user tries to actually select values from the dropdown.
Before NetBox 3.0 we had the same permission scheme and the error did not show.
Now you get multiple overlapping error messages because we don't use some objects like "regions" and "site groups" so our users have no read access to those objects.
Atm the workound would be give a use read permissions to everything within NetBox so he doesn't get any error messages when opening an edit dialogue.

Observed Behavior

The following error occurs when opening the device edit page:
image

Originally created by @dkm77 on GitHub (Oct 4, 2021). ### NetBox version v3.0.4 ### Python version 3.8 ### Steps to Reproduce - Create a new user: ![image](https://user-images.githubusercontent.com/8020884/135974928-4f59013d-0ea9-41d9-bf3e-af33056714a9.png) - Create a new permission with full access to "DCIM -> device" and no access to other objects and assign it to the user: ![image](https://user-images.githubusercontent.com/8020884/135975585-78f121f8-789e-42e4-8297-a63b2281781f.png) - Login as the new user and open the edit dialogue for a device to see multiple overlapping error messages for the fields the user may not access: ![image](https://user-images.githubusercontent.com/8020884/135975202-c45c592c-9679-4fd5-8d24-c5c7d8207bf5.png) ### Expected Behavior If a user is not allowed to view values of a drop down like the "site group" or "region" field, the dropdown should either not be displayed when editing a device or the error should only show when the user tries to actually select values from the dropdown. Before NetBox 3.0 we had the same permission scheme and the error did not show. Now you get multiple overlapping error messages because we don't use some objects like "regions" and "site groups" so our users have no read access to those objects. Atm the workound would be give a use read permissions to everything within NetBox so he doesn't get any error messages when opening an edit dialogue. ### Observed Behavior The following error occurs when opening the device edit page: ![image](https://user-images.githubusercontent.com/8020884/135975202-c45c592c-9679-4fd5-8d24-c5c7d8207bf5.png)
adam added the type: bugstatus: under review labels 2025-12-29 19:28:21 +01:00
adam closed this issue 2025-12-29 19:28:22 +01:00
adam commented 2025-12-29 19:28:22 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 4, 2021):

Thank you for opening a bug report. Unfortunately, the information you have provided is not sufficient for someone else to attempt to reproduce the reported behavior. Remember, each bug report must include detailed steps that someone else can follow on a clean, empty NetBox installation to reproduce the exact problem you're experiencing. These instructions should include the creation of any involved objects, any configuration changes, and complete accounting of the actions being taken. Also be sure that your report does not reference data on the public NetBox demo, as that is subject to change at any time by an outside party and cannot be relied upon for bug reports.

@jeremystretch commented on GitHub (Oct 4, 2021): Thank you for opening a bug report. Unfortunately, the information you have provided is not sufficient for someone else to attempt to reproduce the reported behavior. Remember, each bug report must include detailed steps that someone else can follow on a clean, empty NetBox installation to reproduce the exact problem you're experiencing. These instructions should include the creation of any involved objects, any configuration changes, and complete accounting of the actions being taken. Also be sure that your report does not reference data on the public NetBox demo, as that is subject to change at any time by an outside party and cannot be relied upon for bug reports.
adam commented 2025-12-29 19:28:22 +01:00
Author
Owner
Copy Link

@dkm77 commented on GitHub (Oct 5, 2021):

Thank you for opening a bug report. Unfortunately, the information you have provided is not sufficient for someone else to attempt to reproduce the reported behavior. Remember, each bug report must include detailed steps that someone else can follow on a clean, empty NetBox installation to reproduce the exact problem you're experiencing. These instructions should include the creation of any involved objects, any configuration changes, and complete accounting of the actions being taken. Also be sure that your report does not reference data on the public NetBox demo, as that is subject to change at any time by an outside party and cannot be relied upon for bug reports.

Sorry for that, I was in a hurry yesterday. I now updated the post and hope that you are able to reproduce this issue the way I described.

@dkm77 commented on GitHub (Oct 5, 2021): > Thank you for opening a bug report. Unfortunately, the information you have provided is not sufficient for someone else to attempt to reproduce the reported behavior. Remember, each bug report must include detailed steps that someone else can follow on a clean, empty NetBox installation to reproduce the exact problem you're experiencing. These instructions should include the creation of any involved objects, any configuration changes, and complete accounting of the actions being taken. Also be sure that your report does not reference data on the public NetBox demo, as that is subject to change at any time by an outside party and cannot be relied upon for bug reports. Sorry for that, I was in a hurry yesterday. I now updated the post and hope that you are able to reproduce this issue the way I described.
adam commented 2025-12-29 19:28:22 +01:00
Author
Owner
Copy Link

@trollqaa commented on GitHub (Oct 5, 2021):

I confirm that we also have these "errors" about the lack of permissions.

@trollqaa commented on GitHub (Oct 5, 2021): I confirm that we also have these "errors" about the lack of permissions.
adam commented 2025-12-29 19:28:23 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 6, 2021):

IMO this is correct and desired behavior. You've created a user without permission to view any of the related objects involved when creating a device, so the error message makes sense.

If a user is not allowed to view values of a drop down like the "site group" or "region" field, the dropdown should either not be displayed when editing a device or the error should only show when the user tries to actually select values from the dropdown.

Some of these fields, such as the site, are required. A user without access to view the list of sites will not be able to create a device.

Atm the workound would be give a use read permissions to everything within NetBox so he doesn't get any error messages when opening an edit dialogue.

Correct, except this isn't really a "workaround:" It's how NetBox is intended to function. To allow such a user to create devices, you'll need to either grant the use "view" permission for the related objected, or exempt these models using the EXEMPT_VIEW_PERMISSIONS configuration parameter.

@jeremystretch commented on GitHub (Oct 6, 2021): IMO this is correct and desired behavior. You've created a user without permission to view any of the related objects involved when creating a device, so the error message makes sense. > If a user is not allowed to view values of a drop down like the "site group" or "region" field, the dropdown should either not be displayed when editing a device or the error should only show when the user tries to actually select values from the dropdown. Some of these fields, such as the site, are required. A user without access to view the list of sites will not be able to create a device. > Atm the workound would be give a use read permissions to everything within NetBox so he doesn't get any error messages when opening an edit dialogue. Correct, except this isn't really a "workaround:" It's how NetBox is intended to function. To allow such a user to create devices, you'll need to either grant the use "view" permission for the related objected, or exempt these models using the [`EXEMPT_VIEW_PERMISSIONS`](https://netbox.readthedocs.io/en/stable/configuration/optional-settings/#exempt_view_permissions) configuration parameter.
adam commented 2025-12-29 19:28:23 +01:00
Author
Owner
Copy Link

@dkm77 commented on GitHub (Oct 7, 2021):

I am ok with giving the user read permissions to all objects used within relevant dropdowns so there are no error messages, to basically restore the edit-behaviour before NetBox 3.0.

The one thing that was nicer with not giving read access to objects that are not used / that the user has no business dealing with was that this was indicated in the menu, so the user could easily see which objects he's supposed to work with.
So in our example were we don't use "Regions" and "Site Groups" this would be indicated in the menu to the user with the lock symbol:
image

One thing that might be a little inconsistent (but that's for you to decide) is that even if a user does not have read access to a region for example, he sees the assigned region of a device when he views the device.
However when he then edits the device, the region field will be empty and the error will be displayed.
Also for me when I just tested this (as I didn't use regions before) it wasn't clear from the UI that assigning a region to a device basically does nothing, as the region dropdown only acts as a filter for the site dropdown and the site is the object that is actually assigned to a device. So this could maybe be made more clear for the user in the UI.

But the way this is heading maybe the actual request would be to have a feature to hide all fields a user does not have read permissions to or have an additional feature to configure hidden fields.
Basically what I am trying to achieve and what worked a little nicer before 3.0 was hiding irrelevant information / fields from the UI to make the user experience easier for the way we are using NetBox (because we don't use all objects/fields available).

For now I will just add read permissions to make the errors disappear but maybe this could be some feature to consider for the future, however I don't think it should have high priority.

@dkm77 commented on GitHub (Oct 7, 2021): I am ok with giving the user read permissions to all objects used within relevant dropdowns so there are no error messages, to basically restore the edit-behaviour before NetBox 3.0. The one thing that was nicer with not giving read access to objects that are not used / that the user has no business dealing with was that this was indicated in the menu, so the user could easily see which objects he's supposed to work with. So in our example were we don't use "Regions" and "Site Groups" this would be indicated in the menu to the user with the lock symbol: ![image](https://user-images.githubusercontent.com/8020884/136330671-9f0cd415-1835-4f58-9a16-17303bf4bbec.png) One thing that might be a little inconsistent (but that's for you to decide) is that even if a user does not have read access to a region for example, he sees the assigned region of a device when he views the device. However when he then edits the device, the region field will be empty and the error will be displayed. Also for me when I just tested this (as I didn't use regions before) it wasn't clear from the UI that assigning a region to a device basically does nothing, as the region dropdown only acts as a filter for the site dropdown and the site is the object that is actually assigned to a device. So this could maybe be made more clear for the user in the UI. But the way this is heading maybe the actual request would be to have a feature to hide all fields a user does not have read permissions to or have an additional feature to configure hidden fields. Basically what I am trying to achieve and what worked a little nicer before 3.0 was hiding irrelevant information / fields from the UI to make the user experience easier for the way we are using NetBox (because we don't use all objects/fields available). For now I will just add read permissions to make the errors disappear but maybe this could be some feature to consider for the future, however I don't think it should have high priority.
adam commented 2025-12-29 19:28:24 +01:00
Author
Owner
Copy Link

@dkm77 commented on GitHub (Oct 7, 2021):

I now added read permissions to the following objects and it seems there a no more errors in edit-dialogues for our users :)
(we are only using the DCIM functionality)

dcim | site group, dcim | region, tenancy | tenant, extras | tag, tenancy | tenant group, dcim | rack role, virtualization | cluster, virtualization | cluster group, dcim | platform, ipam | VLAN, ipam | VLAN group

@dkm77 commented on GitHub (Oct 7, 2021): I now added read permissions to the following objects and it seems there a no more errors in edit-dialogues for our users :) (we are only using the DCIM functionality) `dcim | site group, dcim | region, tenancy | tenant, extras | tag, tenancy | tenant group, dcim | rack role, virtualization | cluster, virtualization | cluster group, dcim | platform, ipam | VLAN, ipam | VLAN group`
adam commented 2025-12-29 19:28:25 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 7, 2021):

Unfortunately I don't think there's anything we can do with the current implementation. If this becomes a more common issue we can re-evaluate.

@jeremystretch commented on GitHub (Oct 7, 2021): Unfortunately I don't think there's anything we can do with the current implementation. If this becomes a more common issue we can re-evaluate.
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: under review type: bug
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#5466
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?