Limit widget areas and contexts displayed on the shared dashboard to those which the user has access to

Feature Description

Building on the work started in #4807 and #4813, users on the shared dashboard should only see widget contexts that have non-empty widget areas. As it is now, the dashboard will show all areas and contexts

---

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

Acceptance criteria

• The isWidgetContextActive and isWidgetAreaActive selectors of the core/widgets store should be extended with a second (optional) options parameter that includes a single modules (string[] module slugs) option (just like getWidgets)
  • The functionality of this option is already handled by getWidgets so this is mostly about passing it through where needed
  • If provided, both selectors should only consider the given context/area active if it has any non-empty areas/widgets respectively (after filtering by the given modules)
  • All usage of these selectors in the following components should be updated to include the new modules argument (from getViewableModules) if in view-only context (relying on the useViewOnly() hook from #4814)
    • DashboardEntityApp
    • DashboardMainApp
    • DashboardNavigation
    • WidgetContextRenderer
    • WidgetAreaRenderer

Implementation Brief

• Using assets/js/googlesitekit/widgets/datastore/areas.js and assets/js/googlesitekit/widgets/datastore/contexts.js,
  • Update the following selectors to include a new optional parameter, options that includes a single modules (string[] module slugs) option (just like getWidgets).
    • isWidgetAreaActive
      • Pass modules as second parameter to the getWidgets selector.
    • isWidgetContextActive
      • Pass modules as second parameter to the isWidgetAreaActive selector.
• Using the components listed in the last point from the AC,
  • Query the user data store via the getViewableModules selector to retrieve the list of viewable modules for the user.
  • Check if we are in view-only mode via the useViewOnly hook.
  • If in view-only mode and there is a list of modules, update calls to isWidgetAreaActive and isWidgetContextActive to include the list of viewable modules as second parameter.

Test Coverage

• Update tests to the isWidgetAreaActive and isWidgetContextActive selectors to include tests when a list of modules is passed as second parameter.

QA Brief

See https://github.com/google/site-kit-wp/issues/4813#issuecomment-1135037589 about how to reach the shared dashboard before #5188 is done.

Once the Shared Dashboard can be viewed we should verify that only widgets which are shared with the user’s role are visible on the Shared Dashboard (both the Main and the Entity Dashboard).

The shared roles will eventually be configurable via the UI, but in order to configure them prior to the UI controls being implemented use the Dashboard Sharing tester plugin.

## Changelog entry

* Limit widget areas and contexts displayed on the shared dashboard to modules which are shared with the user.

[techanvil]

Hi @aaemnnosttv, thanks for pointing that out! I hadn’t spotted that subtle disconnect between the AC and the implementation.

I think we can make that correction here too, will go ahead and make it happen. Cheers

[wpdarren]

QA Update: ✅

Verified:

I have been through the steps in the QAB and can see that I have access to the shared dashboard, and in particular Speed widget on main and entity dashboard. I am seeing an error though Error: Site Kit can’t access the relevant data from PageSpeed Insights because you haven’t granted all permissions requested during setup. but from Evan’s update on the engineering call, these are expected right now.

The same message appears if I change access to the editor for Search Console and/or Analytics.