-
Notifications
You must be signed in to change notification settings - Fork 295
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
UX/UI issue for 'Who can manage view access' inactive dropdowns #5352
Comments
@felixarntz @marrrmarrr should we instead maybe replace the select boxes here with text (like we do for modules owned by other admins) to say simply "Manageable by all authenticated admins" ? |
@aaemnnosttv +1, I think that's a gread idea. I'd say the term "authenticated" we should probably only include though in combination with also changing the "All admins" dropdown label to "All authenticated admins" (see other bug bash discussion). |
@bethanylang Since you originally pointed this out and suggested changes to make it clear that users can't edit these settings, can you check the Acceptance Criteria here and see if they would improve this scenario? If it's good just leave a comment saying so and feel free to move this over to the Implementation Brief column, but if not please let me know any better wording to use or an approach you think is better 🙂 |
@tofumatt LGTM, thank you! |
@bethanylang I've revised the language a bit, would you please take another look? |
@aaemnnosttv Like this even more, thank you! |
IB ✅ looks good. Thanks for the updated text @aaemnnosttv, it's way better 👍🏻 |
Feature Description
Bug bash issue: https://app.asana.com/0/1202258919887896/1202406665934847 please refer to Asana issue for background
When you have a secondary admin user and went back to the Dashboard sharing & permissions screen, the Who can manage view access dropdown is inactive for PageSpeed and Idea Hub. Looking at the AC this is expected but could we not have a scenario where an admin does not want to share these modules with all admins? If this isn't a scenario, then should we hide these dropdown's to avoid confusion? I feel this needs discussing.
These are what are referred to as "Shared ownership modules" which are different than others because they don't involve a specific "owned" entity on the service side, the ownership is more of a detail related to sharing (only owned modules can be shared with others). For these, ownership is set when the roles are changed which can be managed by all authenticated admins which is why the dropdowns for these are disabled.
Maybe it's worth having some kind of tooltip or other message there indicating why these can't be changed? I don't think it's obvious to users that these modules are any different from the others.
Do not alter or remove anything below. The following sections will be managed by moderators only.
Acceptance criteria
<select>
tag will clarify the usage for users by never setting up the expectation that this setting can be changed.Implementation Brief
assets/js/components/dashboard-sharing/DashboardSharingSettings/Module.js
:<Select />
component responsible for showing the view access options..googlesitekit-dashboard-sharing-settings__column--manage
, prior to showing the<Select />
component, start a new paragraph for the plain text. This should only show up ifsharedOwnershipModule
istrue
..googlesitekit-dashboard-sharing-settings__note
paragraph as indicated in the last part of the AC to compose this plain text. Simply replace the text of the paragraph (and the tooltip inside) to match what's included in the AC.<Select />
: it should only show up whensharedOwnershipModule
isfalse
andhasOwnedModule
istrue
.Test Coverage
QA Brief
dashboardSharing
flag from the tester plugin.Changelog entry
The text was updated successfully, but these errors were encountered: