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

null-ifying some fields by users with limited privileges #7287

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

Originally created by @opericgithub on GitHub (Nov 25, 2022).

NetBox version

v3.3.8

Python version

3.10

Steps to Reproduce

  1. login as a superuser or a user that has all permissions.
  2. go to devices > platforms and add new platform named "test_pf".
  3. go to devices > devices and add new device, populate all required fields and select "test_pf" as its platform.
  4. go to this newly created device, edit it and change its name. this step is to ensure that device's platform remains "test_pf".

image

  1. go to NetBox Administration menu > USERS Permissions and add new permission: 1) name it "no_platform", 2) select all four actions (can view, can add, can change, can delete), 3) select ALL object types EXCEPT "dcim>platform", and 4) click save.

image

  1. go to NetBox Administration menu > AUTHENTICATION AND AUTHORIZATION Groups, and add new group: 1) name it "no_platform_group" then 2) select "no_platform" for the objectpermission below and 3) click save.
  2. go to NetBox Administration menu > AUTHENTICATION AND AUTHORIZATION Users and add new user: name it "no_platform_user" with some password, click save and then 2) choose "no_platform_group" as a group this user will belong to.
  3. go to main netbox site, log out as a superuser and login as this newly created "no_platform_user".
  4. go to the device created in step 3, verify that its platform is listed as "test_pf", then edit this device, change only its name and save it.
  5. platform field is null-ified:

image

Expected Behavior

platform field should remain intact.

Observed Behavior

platform field is null-ified.

Originally created by @opericgithub on GitHub (Nov 25, 2022). ### NetBox version v3.3.8 ### Python version 3.10 ### Steps to Reproduce 1. login as a superuser or a user that has all permissions. 2. go to devices > platforms and add new platform named "test_pf". 3. go to devices > devices and add new device, populate all required fields and select "test_pf" as its platform. 4. go to this newly created device, edit it and change its name. this step is to ensure that device's platform remains "test_pf". ![image](https://user-images.githubusercontent.com/65983735/204359014-379c24fd-7cdb-4317-9948-97d8aae3a30a.png) 5. go to NetBox Administration menu > USERS Permissions and add new permission: 1) name it "no_platform", 2) select all four actions (can view, can add, can change, can delete), 3) select ALL object types EXCEPT "dcim>platform", and 4) click save. ![image](https://user-images.githubusercontent.com/65983735/204359253-a9a57d15-4720-4a9a-8ff0-6ebcbe06d8bd.png) 6. go to NetBox Administration menu > AUTHENTICATION AND AUTHORIZATION Groups, and add new group: 1) name it "no_platform_group" then 2) select "no_platform" for the objectpermission below and 3) click save. 7. go to NetBox Administration menu > AUTHENTICATION AND AUTHORIZATION Users and add new user: name it "no_platform_user" with some password, click save and then 2) choose "no_platform_group" as a group this user will belong to. 8. go to main netbox site, log out as a superuser and login as this newly created "no_platform_user". 9. go to the device created in step 3, verify that its platform is listed as "test_pf", then edit this device, change only its name and save it. 10. platform field is null-ified: ![image](https://user-images.githubusercontent.com/65983735/204359773-948bd454-2de1-4942-b70c-483d144b06d6.png) ### Expected Behavior platform field should remain intact. ### Observed Behavior platform field is null-ified.
adam closed this issue 2025-12-29 20:21:14 +01:00
adam commented 2025-12-29 20:21:15 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 28, 2022):

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 (Nov 28, 2022): 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 20:21:15 +01:00
Author
Owner
Copy Link

@opericgithub commented on GitHub (Nov 28, 2022):

I have edited the original post. I hope there is enough information now.

@opericgithub commented on GitHub (Nov 28, 2022): I have edited the original post. I hope there is enough information now.
adam commented 2025-12-29 20:21:15 +01:00
Author
Owner
Copy Link

@opericgithub commented on GitHub (Dec 13, 2022):

what is the procedure now? should someone take over this case?

@opericgithub commented on GitHub (Dec 13, 2022): what is the procedure now? should someone take over this case?
adam commented 2025-12-29 20:21:17 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 16, 2022):

@opericgithub thanks for providing those detailed instructions. This is happening because the user you created does not have permission to view platforms. When the device edit form loads, there is no way for the user to select a platform, so the field is left empty.

You have two options to work around this:

  1. Assign to the user (or group) a separate permission granting view access for platforms
  2. Add dcim.platform to EXEMPT_VIEW_PERMISSIONS

Either solution will grant the permissions necessary for the user to retain or change a device's platform. Hope that helps!

@jeremystretch commented on GitHub (Dec 16, 2022): @opericgithub thanks for providing those detailed instructions. This is happening because the user you created does not have permission to view platforms. When the device edit form loads, there is no way for the user to select a platform, so the field is left empty. You have two options to work around this: 1. Assign to the user (or group) a separate permission granting view access for platforms 2. Add `dcim.platform` to [`EXEMPT_VIEW_PERMISSIONS`](https://docs.netbox.dev/en/stable/configuration/security/#exempt_view_permissions) Either solution will grant the permissions necessary for the user to retain or change a device's platform. Hope that helps!
adam commented 2025-12-29 20:21:19 +01:00
Author
Owner
Copy Link

@opericgithub commented on GitHub (Dec 19, 2022):

hello @jeremystretch, I must say this doesn't relate only to platform field, but to any other fields.
Unfortunately this workaround doesn't apply to my usecase.

In my usecase I intentionally want to have two general groups of users, light and strong. One of them, light one, lets call them network technicians, and the other, strong one is network admins.

Tehcnicians don't need to be loaded with lots of informations, they don't require a ton of knowledge. They simply need access to a very tiny or constrained set of data.
However, administrators must have access to all information.

Technicians don't need to be aware of platform, ip addresses, ranges, l2vpns, tenant groups etc. In the current constellation, if they modify some components which use any of these, they will null-ify some data that is very important to network admins.

Using your proposed workaroung would mean that technicians would have to see and have access to all of these components, which is the thing I want to evade.

In my opinion, one of the solutions would be not to allow certain fields to be visible at all on the edit page, if that user doesn't have proper rights. For ie, if the user has only the read-only (viewing) privileges, the field could be grayed out, and similarly if the user doesn't have any privileges, including viewing privileges, then the field shouldn't be displayed at all.

@opericgithub commented on GitHub (Dec 19, 2022): hello @jeremystretch, I must say this doesn't relate only to platform field, but to any other fields. Unfortunately this workaround doesn't apply to my usecase. In my usecase I intentionally want to have two general groups of users, light and strong. One of them, light one, lets call them network technicians, and the other, strong one is network admins. Tehcnicians don't need to be loaded with lots of informations, they don't require a ton of knowledge. They simply need access to a very tiny or constrained set of data. However, administrators must have access to all information. Technicians don't need to be aware of platform, ip addresses, ranges, l2vpns, tenant groups etc. In the current constellation, if they modify some components which use any of these, they will null-ify some data that is very important to network admins. Using your proposed workaroung would mean that technicians would have to see and have access to all of these components, which is the thing I want to evade. In my opinion, one of the solutions would be not to allow certain fields to be visible at all on the edit page, if that user doesn't have proper rights. For ie, if the user has only the read-only (viewing) privileges, the field could be grayed out, and similarly if the user doesn't have any privileges, including viewing privileges, then the field shouldn't be displayed at all.
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
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#7287
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?