Combine dashboard and splash screens into a single screen in PHP

Feature Description

As noted in https://github.com/google/site-kit-wp/issues/4811#issuecomment-1118981281, the current logic behind our VIEW_SHARED_DASHBOARD capability makes it difficult to implement a conditional button on the splash screen due to the specific requirement of the shared_dashboard_splash dismissal as part of the criteria for granting the capability.

We should decouple the logic related to the splash screen dismissal from the capability for viewing the shared dashboard. This may mean a user may be redirected back to the splash from the dashboard if they don’t have the dismissal yet, but that’s okay.

---

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

Acceptance criteria

• The VIEW_SHARED_DASHBOARD capability should no longer require the shared_dashboard_splash dismissed item in its resolution
  • Going forward, this capability will be only the following criteria:
    • The user has a role which is included in the sharing settings for at least one module in the dashboard sharing settings (as today)
    • The user cannot view the authenticated dashboard
• The relevant behavior around the requirement of the dismissal to view the shared dashboard should be preserved as follows:
  • If a user can VIEW_SHARED_DASHBOARD but does not have the dismissal, they should be redirected to the splash page when attempting to access the dashboard
  • If a user can VIEW_SHARED_DASHBOARD but does have the dismissal, they should be redirected to the dashboard when attempting to access the splash page
  • If a user can VIEW_SHARED_DASHBOARD but does not have the dismissal, the splash page Screen should appear in the admin menu instead of the dashboard, the same as if an admin was not authenticated without dashboard sharing today
• VIEW_SHARED_DASHBOARD should continue to only be granted when the dashboardSharing feature is enabled (i.e. explicit checks for the feature flag are not needed when logic requires the capability)

Implementation Brief

• In Permissions.php, within the check_view_shared_dashboard_capability() method:

  • Remove the call to is_shared_dashboard_splash_dismissed().
  • Add a check if the given $user_id has the VIEW_AUTHENTICATED_DASHBOARD capability - use WP_User::has_capability(). If it returns true, fail the check, i.e. return array( 'do_not_allow' ).

• In Screens.php, within the get_screens() method:

  • When registering the googlesitekit-dashboard Screen, add an initialize_callback function. It should:
    • Check if the current user can VIEW_SHARED_DASHBOARD.
    • Also check if the shared_dashboard_splash item is dismissed using the Dismissed_Items class and its is_dismissed method.
    • If the user can VIEW_SHARED_DASHBOARD and does not have the dismissal, redirect the user to the splash page.
  • When registering the googlesitekit-splash Screen, update the initialize_callback function:
    • After the splash context revoked logic, check if the current user can VIEW_SHARED_DASHBOARD and if they have the shared_dashboard_splash dismissal as above. If both are true, redirect them to the dashboard (similar to how it’s done when the user has been authenticated).
    • Modify the current_user_can() check to VIEW_AUTHENTICATED_DASHBOARD instead of VIEW_DASHBOARD. Essentially, only redirect the user to the dashboard if the user can view the authenticated dashboard and if the user is authenticated.
  • The updates do not require the dashboardSharing feature flag to be enabled since the capabilities checked above are granted only if the feature flag is enabled.

Test Coverage

• Add new tests in ScreensTest.php:
  • add tests to check if the admin menu is constructed appropriately depending on a user’s capabilities.
  • add tests to check if the user is redirected correctly between the dashboard and splash screen depending on their capabilities.

QA Brief

• While the ACs in this issue focus on users who can view the shared dashboard (i.e. non-authenticated users whose role is shared within dashboard sharing settings), there are significant changes which also affect authenticated users. Changes have been made to both these types of users landing on the “Splash screen” or the “Dashboard” pages, and being redirected to the other depending on the conditions in the ACs. As such, their combinations should be tested, ensuring that there are no “infinite redirect” errors in the browser. Tests should include these scenarios:
• With dashboardSharing disabled, verify existing behaviour is not affected. Administrators can verify, authenticate, and setup the plugin. They can then also disconnect or reset the plugin as before.
  • Non-admins should not be able to see links to the plugin in the Admin menu.
• With dashboardSharing enabled, verify that an administrator can authenticate themselves and setup the plugin, as well as disconnect or reset. Also verify that without adding any shared roles, an editor/non-admin cannot see the SK Dashboard link in the admin menu.
• Using the new Dashboard Sharing Settings plugin, allow some roles, especially “administrators” and say, “editors” to be shared roles for some modules like search-console and pagespeed-insights. The management setting is not very relevant here and can be left to their default values. Create users with these shared roles, including another administrator. Since they have roles which are shared, these users are able to VIEW_SHARED_DASHBOARD and can be used to verify the ACs. To navigate directly to the dashboard, append the following to your test domain: /wp-admin/admin.php?page=googlesitekit-dashboard. To navigate directly to the splash, append: /wp-admin/admin.php?page=googlesitekit-splash
• Make sure to use the second administrator to click on “Skip Sign in and View Limited Dashboard” link on the splash page and verify the user is directed to the dashboard.

Changelog entry

[felixarntz]

I’ll also move this back to ACs for now, since the scope of this issue has changed. Will provide new ACs soon.

[felixarntz]

@aaemnnosttv ACs SGTM!

I think getting access to the WP dashboard widget and admin bar without going through the splash screen is not too big of a deal. I’ll move this to IB.

That raises another important point I just thought about though: We may want to be a bit more strict about WP dashboard widget and admin bar menu in another way. I don’t think the dismissal matters here much, but for example it would not make any sense to show these two areas in case a user e.g. had only access to shared data from AdSense or PageSpeed Insights since these don’t surface there at all.

That would definitely not be part of this issue, but maybe we should open an issue to introduce dedicated capabilities for viewing the WP dashboard widget and admin bar menu? Since those rely on “hard-coded” module data, the capabilities should probably check under the hood for shared access only to the modules that are relevant there, in order to make a decision whether to grant the capability. Does that make sense? In that case, could you open an issue for that?