Dashboard Sharing: shared modules are blocked from sharing if owner loses capability

[eclarke1]

Bug Description

Bug bash issue: https://app.asana.com/0/1202258919887896/1202445528223665 please refer to Asana issue for background

If a managing user has their role changed or is deleted by another admin, that admin won't be able to "manage roles" if they are the only remaining admin. If there are 2 site administrators, and one of the administrators is removed or has their WP role downgraded the other admin will not be able to change Dashboard Sharing roles, while the option to manage view access doesn't appear.

Recording of experience

I think we could detect that the "managing user" is no longer an admin and show a different notice here, which would probably be best. It might even warrant a general error notice, not sure 🤔

Steps to reproduce

1. Setup SK without Analytics (only SC) on a site with 2 administrators
2. Login as the other administrator (adminB), set up SK and connect the Analytics module
3. Check the dashboard sharing options. You'll notice that SC is managed by adminA while you (adminB) are managing the Analytics module.
4. Log back in to the site from adminA and change the role of adminB from "administrator" to "Editor"
5. Open the dashboard sharing options. It's now not possible to change the dashboard sharing roles, while the "Who can manage view access" options don't appear

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• When an admin, having set up a module and shared it via the Dashboard Sharing pop up, gets deleted or "demoted" to a lesser role, then the message in the pop up for all other Admin users should be modified to be:
  • Managing user required to manage view access. Learn more
  • The message should be styled using the new WarningNotice component as per this Figma mock.
• The "Who can manage view access" column is currently hidden when there is just one single admin on the site. This should not be the case if more than one module has been shared (originally by more than one admin), even if there is just one admin eventually.
• Site Kit Documentation Updates:
  • The first FAQ in the documentation should be removed/updated.
  • Other changes have been outlined in this Asana task and should go live with this issue being released.

Implementation Brief

• In assets/js/components/dashboard-sharing/DashboardSharingSettings/index.js:
  • Create a new flag in this component, hasRecoverableModules. Use the getRecoverableModules selector from the core/modules datastore and set the flag to true if there are one or more recoverable modules.
  • Create a new flag, showManageColumn that should be true if either hasMultipleAdmins OR hasRecoverableModules is true.
  • De-structure the recoverable property when mapping through sortedShareableModules and pass it as a new prop to the Module component.
• In assets/js/components/dashboard-sharing/DashboardSharingSettings/Module.js:
  • Within the googlesitekit-dashboard-sharing-settings__column--view div, after the conditional rendering of UserRoleSelect, check if the recoverable prop is true. If it is, then render the new message from the AC using the <WarningNotice> component.
  • Follow similar logic from above to showManageColumn and use this to render the third column content instead of simply relying on hasMultipleAdmins.

Test Coverage

• No new tests required.

QA Brief

• Set up Site Kit and some modules. Using the Dashboard Sharing Settings modal, share at least one module (say Analytics) as Admin1. Verify that this Admin1 is able to edit the roles and sees all three columns as usual. On another module (say search console), ensure that "all admins" is selected for "who can manage view access". This is to test that another admin can edit roles.
• Now login using Admin2 and sign in using google. Verify that the Dashboard Sharing settings modal view column shows the "Contact managing user to manage view access" for the module shared by Admin1. Verify that Admin2 can edit roles for the module where Admin1 has allowed this.
• Now, while logged into Admin2's account, change the capability/role of Admin1 to be a non-editing role (say contributor). Refresh the dashboard and check the dashboard sharing settings modal and verify the message is shown as per the AC.

Changelog entry

• Update dashboard sharing to restore sharing capabilities for modules whose owner lost sharing capabilities.

[aaemnnosttv]

This should be covered by the existing functionality for module recovery. I don't think we should further complicate the interface here to facilitate module recovery but we could adjust the language if the module were recoverable. IMO this isn't launch blocking.

[eclarke1]

Changing to P1 then to reflect this as a nice to have

[aaemnnosttv]

@felixarntz @marrrmarrr this is an odd case because the module isn't shared yet, so it isn't recoverable. In the user's experience they'll not be able to share it because it's still technically owned by another user, even though that user is really no longer capable of being the module owner.

In this case, it's more of a case of module take over, similar to how we handle shared ownership modules although we'd only want to allow it if the user had access to the configured entity. If they did have access, we could consider allowing them to take over by enabling sharing. This way they wouldn't be blocked from enabling sharing, but otherwise no takeover would be needed.

Said another way, if a module owner loses their ability to share the module and sharing isn't enabled yet, we could resolve that modules sharing management value to "all admins" allowing any other admin signed in with Google to enable sharing for it via the settings. For these users, we would check if they have access to the current configured entity and if so we could enable the interface for managing shared roles. If they enabled sharing by adding roles, we could make them the new module owner on save. This would probably require tweaking the UI a bit and maybe adding a new case for the language at the bottom but I'm not sure how else we might address this other than perhaps updating the logic for modules that are considered shareable to also require their owner is capable of sharing. The latter is the easier change but makes it harder for users to know what needs to be done to enable sharing for such a module.

[aaemnnosttv]

As discussed yesterday with @felixarntz and @marrrmarrr, the plan is to first enhance the module settings screens to allow for module takeover, even if the user does not have access to the current configuration. See #5496

Then the sharing settings interface could be enhanced here in such a situation, if the current user had access to the configured entity, there could be a single-click button to take over which would then be replaced by the user role select, allowing the user to enable sharing. If the user did not have access, this could link to the settings edit view for the module instead where it could be reconfigured, which would have the side-effect of taking ownership, that would then allow them to enable sharing if desired.

[FlicHollis]

Hi @aaemnnosttv what is the next steps here? Can this be moved to IB?

[aaemnnosttv]

@FlicHollis this is blocked by #5496 so we need to wait for that one to at least get AC and maybe even an IB before we can start moving this one along.

[marrrmarrr]

@aaemnnosttv left a comment on #5496 on how to handle that corner case. Once we finalise how that should look like, I think we can either link to that state from the dashboard sharing modal, or directly to the "redo setup" flow.

[mxbclang]

@aaemnnosttv Following up on this one, thanks!

[aaemnnosttv]

I've updated the title here to be a bit more clear. #5496 is still the one we need to do first to unblock this one.

[ivonac4]

@aaemnnosttv Should this one stay assigned to you to work on it soon or you want someone else to pick it up?

[tofumatt]

ACs here look good 👍🏻

Moving to IB 🙂

[jimmymadon]

@andreylipattsev @aaemnnosttv Even though the ACs here have been reviewed (thanks @tofumatt), being a user facing message, I wanted to get this reviewed by you too. Also, while writing the IB, I have suggested a modification to this message and the addition of a learn more link. This is getting a bit too long now and crowded. (c.c. @sigal-teller) Do you all have any other suggestions here or is this fine?

@adamdunnage @jamesozzie On a completely separate note, the "Recovering a module" section describes what module recovery is. However, in the second case, we mention "If an administrator accesses Site Kit and doesn’t have access to the services that are recoverable, they will see the same message displayed but only the modules they have access to will be listed." However, we do not give any "next steps" on how to "fix" this scenario. Perhaps we should say that the new administrator should be granted access via the dashboard of the respective google services or the new admin should disconnect the module and attempt to reconnect the module using different settings? Have we got (m)any supports requests on module recovery?

[jamesozzie]

We didn't receive any support topics regarding module recovery at this time @jimmymadon.

We do have a section on the Dashboard Sharing guide on the plugin website, which I can update to include the steps to regain access at service level. I've created a task to do this. Thank you. After updating, maybe we could even including a "Get help" link on the dashboard sharing modal.

[aaemnnosttv]

Thanks @jimmymadon, I agree the current wording is much too long for the space. I think we should try to reduce it to something of similar length to the existing "Contact managing user to manage view access" and add a tooltip to provide the more complete/verbose explanation. Maybe something like "Unable to manage view access" or "Managing user needed to manage view access"?

[aaemnnosttv]

New message LGTM!

[jimmymadon]

@tofumatt I've moved this to IBR as we approved these ACs on our AC sync yesterday. Thanks.

[tofumatt]

Looks good to me. IB ✅

[mohitwp]

QA Update ⚠️

• Tested on dev environment.
• Verified that when an admin, having set up a module and shared it via the Dashboard Sharing pop up, gets deleted or "demoted" to a lesser role, then the message in the pop up for all other Admin users modified to be:
  ---Managing user required to manage view access. Learn more
  ---- The message styled using the new WarningNotice component as per this Figma mock.
  Verified The "Who can manage view access" column is currently hidden when there is just one single admin on the site. This should not be the case if more than one module has been shared (originally by more than one admin), even if there is just one admin eventually.

Question> @jimmymadon I have a question related to one scenario where if any module "Who can view manage access" is not provided by demoted admin1 then even after recovering a module admin2 is not able to get access. In this case Admin2 get access only after resetting the plugin. So, here in this case if any module is not shared then admin2 is not able to get manage view access for that module.

Scenario -

• Login as admin1.
• Setup SK with Analytics.
• Shared analytics view access to all users and set manage view access to only me.
• Do not share SC view but set manage access to any admin.
• Login As admin2.
• Demoted Admin 1 role to contributor.
• On dashboard recover analytics because only analytics module was shared.
• Now open dashboard sharing modal.
• Notice that for SC - managed by Admin1 is showing and admin 2 is not able to manage the view access for search console.

Recording.1254.mp4

PASS CASES

Admin User have access

Admin user don't have access

[jimmymadon]

@mohitwp Thanks for flagging this issue. Clearly, we have only implemented Module Recovery for a module that was already shared. Maybe we should create a new issue with this edge case because the AC of this issue clearly states that:

"When an admin, having set up a module and shared it via the Dashboard Sharing pop up"

So this criteria has been met for now. I am not sure if there are any implications of allowing a module to be recovered in the case when:

1. The module was never shared before nor was the "Who can manage view access" property changed.
2. The module wasn't shared and the "Who can manage view access" property was changed to "All admins".

In the second case, it perhaps makes sense to think about considering the module to be "recoverable". I have created a new issue #9127 and will discuss this in our next AC sync with Evan and Andrey.

[mohitwp]

QA Update ✅

• Tested on dev environment.

• Verified that when an admin, having set up a module and shared it via the Dashboard Sharing pop up, gets deleted or "demoted" to a lesser role, then the message in the pop up for all other Admin users modified to be:
  ---Managing user required to manage view access. Learn more
  ---- The message styled using the new WarningNotice component as per this Figma mock.
  Verified The "Who can manage view access" column is currently hidden when there is just one single admin on the site. This should not be the case if more than one module has been shared (originally by more than one admin), even if there is just one admin eventually.

• For the issue reported above @jimmymadon created a separate ticket Dashboard Sharing: unshared modules are blocked from module recovery / sharing if owner loses capability #9127

Note : Changes in this ticket require update in documentation. cc @adamdunnage @jamesozzie

Admin User have access

Admin user don't have access