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

Hide Custom Field form element if that fields references an object without view permission #10723

New Issue
Closed
opened 2025-12-29 21:35:13 +01:00 by adam · 8 comments
adam commented 2025-12-29 21:35:13 +01:00
Owner
Copy Link

Originally created by @mwobst on GitHub (Feb 3, 2025).

NetBox version

v4.2.1

Feature type

Change to existing functionality

Proposed functionality

Current situation: If a custom fields references an object type (e. g. VLAN) and you do not have the view permission on this object, the element is rendered empty. Upon saving, the value is removed.

This was unexpected for us, thus a proposal: If a custom fields references an object type, and the corresponding view permission is missing, then the form element should not be included in the form (so saving won’t destroy references by "accident").

Use case

Motivation: We have some custom fields on our IP adresses that reference a different object type. Some users are indeed allowed to modify IP addresses, but don’t have view permission on the referenced object. After saving, the reference was simply gone. Yes, you can see in advance that there is such a reference, but that doesn’t really help here … on little oversight (due time pressure or whatever) and the value is nuked.

Database changes

Probably none

External dependencies

None

Originally created by @mwobst on GitHub (Feb 3, 2025). ### NetBox version v4.2.1 ### Feature type Change to existing functionality ### Proposed functionality Current situation: If a custom fields references an object type (e. g. VLAN) and you do not have the view permission on this object, the element is rendered empty. Upon saving, the value is removed. This was unexpected for us, thus a proposal: If a custom fields references an object type, and the corresponding view permission is missing, then the form element should not be included in the form (so saving won’t destroy references by "accident"). ### Use case Motivation: We have some custom fields on our IP adresses that reference a different object type. Some users are indeed allowed to modify IP addresses, but don’t have view permission on the referenced object. After saving, the reference was simply gone. Yes, you can see in advance that there is such a reference, but that doesn’t really help here … on little oversight (due time pressure or whatever) and the value is nuked. ### Database changes Probably none ### External dependencies None
adam added the type: featurestatus: needs ownerpending closurecomplexity: low labels 2025-12-29 21:35:13 +01:00
adam closed this issue 2025-12-29 21:35:13 +01:00
adam commented 2025-12-29 21:35:13 +01:00
Author
Owner
Copy Link

@bctiemann commented on GitHub (Feb 27, 2025):

Could you provide some reproduction steps/details so we can see what the behavior is that you're seeing? This seems like it might be more of a bug than a feature.

@bctiemann commented on GitHub (Feb 27, 2025): Could you provide some reproduction steps/details so we can see what the behavior is that you're seeing? This seems like it might be more of a bug than a feature.
adam commented 2025-12-29 21:35:14 +01:00
Author
Owner
Copy Link

@mwobst commented on GitHub (Feb 28, 2025):

Thanks for replying. In our special case:

  • we defined a custom field with Type = Object
  • the "Related object type" was a custom model (from a plugin I wrote for our specific needs),
  • "Object type" was "IP address"
  • a user who doesn’t have permission on this specific model (no view, edit, delete or anything else), but was allowed to edit IP adresses, had their form rendered with the dropdown for the custom model object selection, but no options were there
  • Result: The form is saved, the value for the custom field becomes … errr … sth. empty-like. I’m actually not sure = did not look it up, but anyway, the reference was gone afterwards.

You probably can reproduce this with any model, I guess.

@mwobst commented on GitHub (Feb 28, 2025): Thanks for replying. In our special case: - we defined a custom field with Type = Object - the "Related object type" was a custom model (from a plugin I wrote for our specific needs), - "Object type" was "IP address" - a user who doesn’t have permission on this specific model (no view, edit, delete or anything else), but was allowed to edit IP adresses, had their form rendered with the dropdown for the custom model object selection, but no options were there - Result: The form is saved, the value for the custom field becomes … errr … sth. empty-like. I’m actually not sure = did not look it up, but anyway, the reference was gone afterwards. You probably can reproduce this with any model, I guess.
adam commented 2025-12-29 21:35:14 +01:00
Author
Owner
Copy Link

@arthanson commented on GitHub (Mar 7, 2025):

@mwobst we would need reproduction steps with NetBox without using a plugin. We get a lot of issues in and trying to reproduce them without clear reproduction steps is a problem.

@arthanson commented on GitHub (Mar 7, 2025): @mwobst we would need reproduction steps with NetBox without using a plugin. We get a lot of issues in and trying to reproduce them without clear reproduction steps is a problem.
adam commented 2025-12-29 21:35:15 +01:00
Author
Owner
Copy Link

@mwobst commented on GitHub (Mar 10, 2025):

@mwobst we would need reproduction steps with NetBox without using a plugin. We get a lot of issues in and trying to reproduce them without clear reproduction steps is a problem.

Sorry if this was too unspecific. Well, while trying to do the steps again to create an appropriate steps list, I had a suspicion – which proved to be true: The problem is more general, it does not affect only custom fields, but any dropdown with an object selection.

Steps:

  • Create a prefix/vlan role, for example "Test"
  • Create some test prefix and assign the role above
  • Create a permission that allows any action on the Prefix
  • Create (as admin) a user (no special privilegues) and assign this permission only
  • Go to the prefix and edit it. You should see that the dropdown is empty. Save – and the role assignment is gone.
    (I verified by logging in as admin that this not just some weird display or view permission issue, but nope: No role anymore)

Please note: I also created a custom field, type "multiple objects" to assign multiple such roles to a prefix, for sake of testing. Result is sadly the same; all assigned roles are gone after saving.

I know, this example is a bit pointless because anybody with permission to manage prefixes should at least be able to view prefix/vlan role, but it demonstrates the problem. Hope the steps are enough …

@mwobst commented on GitHub (Mar 10, 2025): > [@mwobst](https://github.com/mwobst) we would need reproduction steps with NetBox without using a plugin. We get a lot of issues in and trying to reproduce them without clear reproduction steps is a problem. Sorry if this was too unspecific. Well, while trying to do the steps again to create an appropriate steps list, I had a suspicion – which proved to be true: The problem is more general, it does not affect only custom fields, but *any* dropdown with an object selection. Steps: - Create a prefix/vlan role, for example "Test" - Create some test prefix and assign the role above - Create a permission that allows any action on the Prefix - Create (as admin) a user (no special privilegues) and assign this permission only - Go to the prefix and edit it. You should see that the dropdown is empty. Save – and the role assignment is gone. (I verified by logging in as admin that this not just some weird display or view permission issue, but nope: No role anymore) Please note: I also created a custom field, type "multiple objects" to assign multiple such roles to a prefix, for sake of testing. Result is sadly the same; all assigned roles are gone after saving. I know, this example is a bit pointless because anybody with permission to manage prefixes should at least be able to view prefix/vlan role, but it demonstrates the problem. Hope the steps are enough …
adam commented 2025-12-29 21:35:15 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Mar 18, 2025):

This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.

@github-actions[bot] commented on GitHub (Mar 18, 2025): This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.
adam commented 2025-12-29 21:35:16 +01:00
Author
Owner
Copy Link

@mwobst commented on GitHub (Mar 18, 2025):

Okay, the bot message comes a bit unexpected. Is there anything I need to add?

@mwobst commented on GitHub (Mar 18, 2025): Okay, the bot message comes a bit unexpected. Is there anything I need to add?
adam commented 2025-12-29 21:35:16 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jun 17, 2025):

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[bot] commented on GitHub (Jun 17, 2025): 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](https://github.com/netbox-community/netbox/blob/main/CONTRIBUTING.md).
adam commented 2025-12-29 21:35:16 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jul 17, 2025):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (Jul 17, 2025): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
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 complexity: low pending closure status: needs owner type: feature
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#10723
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?