-
Notifications
You must be signed in to change notification settings - Fork 179
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
Dashboard: Adjust access to settings view #4423
Conversation
… flag is true. Hiding toaster errors re settings when canManageSettings is false since that ties to reading settings data and only admin can do that at this moment
Size Change: -15 B (0%) Total Size: 1.25 MB ℹ️ View Unchanged
|
Codecov Report
@@ Coverage Diff @@
## main #4423 +/- ##
==========================================
- Coverage 83.52% 83.38% -0.14%
==========================================
Files 859 861 +2
Lines 15079 15111 +32
==========================================
+ Hits 12594 12601 +7
- Misses 2485 2510 +25
Flags with carried forward coverage won't be shown. Click here to find out more.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works perfectly when switching roles
|
||
const enableSettingsView = useFeature('enableSettingsView'); | ||
const enableSettingsView = | ||
useFeature('enableSettingsView') && canManageSettings; // we only want to show errors about settings when users have access to managing them, otherwise they can't read settings anyways |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should not be triggering errors in the first place
@BrittanyIRL I'm sorry I didn't see this PR, so I implemented ef06bf4 as part of #4374. I think I prefer that solution over this one as it prevents fetching settings data when the user doesn't have permissions (rather than just hiding the toast messages). PTAL! |
no worries. that's totally fine. i'll close this one. I was just doing that with the toasts for the time being since i figured the permissions thing would get fixed, purely just a work around to get telemetry and settings in for release. |
Summary
Adjusts rules surrounding routes to get to settings so that all users have the ability to see settings when flag is true, hiding parts of settings view when not admin and cannot interact with them (API won't read).
Relevant Technical Choices
enableSettingsView
flag is truecanManageSettings
is false since that ties to reading settings data and only admin can do that at this momentTo-do
User-facing changes
enableSettingsView
feature flag is true you can always navigate to settings page regardless of user's role.Testing Instructions
enableSettingsView
feature flag to 'true' as a logged in admin.(Non admin view)
(Admin view)
Prep work to merge #4152