Skip to content

Hide Related Objects Based On Its Permissions #15966

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
mr1716 opened this issue May 6, 2024 · 10 comments
Closed

Hide Related Objects Based On Its Permissions #15966

mr1716 opened this issue May 6, 2024 · 10 comments
Labels
status: duplicate This issue has already been raised type: feature Introduction of new functionality to the application

Comments

@mr1716
Copy link
Contributor

mr1716 commented May 6, 2024

NetBox version

v3.7.7

Feature type

New functionality

Proposed functionality

Hey, just like changing the permissions can hide the Contacts page for specific sites (such as .../dcim/sites/X with X being a valid site number), this would do the same for dcim sites and dcim regions Related Objects. The goal would be to be able to hide Related Objects that arent being used based upon specific permissions. Right now, the users can click on them, but will get an error if not provided permissions. This would hide that so the users wouldnt see the options they lack permissions to.

Use case

Provide cleaner viewing and user experience for users. Plus, it would implement functionality that exist with other functionality in Netbox.

Database changes

Not sure

External dependencies

N/A I think

@mr1716 mr1716 added status: needs triage This issue is awaiting triage by a maintainer type: feature Introduction of new functionality to the application labels May 6, 2024
@mr1716
Copy link
Contributor Author

mr1716 commented May 6, 2024

This may also be an improvement or change to functionality as well. Not sure it’s classified correctly, so please correct.

@jeffgdotorg jeffgdotorg removed their assignment May 7, 2024
@jeffgdotorg jeffgdotorg added status: needs owner This issue is tentatively accepted pending a volunteer committed to its implementation and removed status: needs triage This issue is awaiting triage by a maintainer labels May 7, 2024
@jeffgdotorg
Copy link
Contributor

Thanks for your interest in helping improve NetBox. I've triaged this feature request as actionable and moved it to the needs owner status. If you would like to volunteer to work it through to a PR, please let us know and a maintainer will assign it to you. Otherwise, another developer with the requisite skills may pick it up as capacity permits.

@jeffgdotorg
Copy link
Contributor

This may also be an improvement or change to functionality as well. Not sure it’s classified correctly, so please correct.

Feature request (FR) is appropriate since we don't currently have a separate enhancement type designation. Thanks for your openness to correction.

@mr1716
Copy link
Contributor Author

mr1716 commented May 7, 2024

@jeffgdotorg, thanks for the assistance and information. It would be best if someone else took the lead as I am not entirely sure on this, and it seems that someone who knows Netbox better would be able to do this faster. I am not sure that this would be a big fix and hope that is the case.

@mr1716
Copy link
Contributor Author

mr1716 commented May 8, 2024

To be clear, one can set the proper permissions so when the user clicks the specific Related Object, it would show an access denied message if unable to access. This request is to go a step further, as to hide these values in the UI as well

@abhi1693
Copy link
Member

abhi1693 commented May 9, 2024

Before I take this task up, how would the permission chekc work with only a subset of related objects are allowed? Hiding the objects based on a simple check will break this use case.

@mr1716
Copy link
Contributor Author

mr1716 commented May 9, 2024

@abhi1693 if you go to individual Sites and Regions, you’ll see a card with Related Objects on the right side. I can disable the permissions to provide an “Access Denied” to users. Rather than provide that error, why not have those options that the user lacks permissions to view, be removed. That’s the request. And it wouldn’t break the use case as the use case is to hide functionality that isn’t being used based on provided functionality. There are other ways to hide functionality and pages and such based upon permissions, so this should follow suit.

@mr1716
Copy link
Contributor Author

mr1716 commented May 9, 2024

@abhi1693 here's a visual look at what the current Related Image looks like. But since I am not using and have disabled permissions for users to view items such as Locations, Circuits, and VLANs, they shouldnt show up. Even though when clicked, the user gets a "You do not have permission to access this page." message. This request is to NOT even show them if the user lacks the permissions to view.
image

@jeremystretch
Copy link
Member

There's some overlap here with #15794 FYI.

@jeremystretch jeremystretch added the complexity: high Expected to require a large amont of time and effort to implement relative to other tasks label May 21, 2024
@jeremystretch
Copy link
Member

I believe this is a duplicate of #15294. Please continue any further discussion under that thread.

@jeremystretch jeremystretch closed this as not planned Won't fix, can't repro, duplicate, stale May 21, 2024
@jeremystretch jeremystretch added status: duplicate This issue has already been raised and removed status: needs owner This issue is tentatively accepted pending a volunteer committed to its implementation complexity: high Expected to require a large amont of time and effort to implement relative to other tasks labels May 21, 2024
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 20, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: duplicate This issue has already been raised type: feature Introduction of new functionality to the application
Projects
None yet
Development

No branches or pull requests

4 participants