Refresh list of recoverable modules from the server after recovering a module.

Feature Description

The recoverModules action currently updates the list of recoverable modules by directly removing the recovered modules from local state.

This should be changed so the recovered modules list is refreshed from the server instead, in keeping with the rest of recoverModules, where the recovered module settings and the list of modules are both refreshed from the server after the modules are recovered.

In order to achieve this the mechanism for determining the recoverable modules list should be updated. Rather than inlining the data in the page as _googlesitekitDashboardSharingData.recoverableModules, include a recoverable flag in the module objects returned by the GET core/modules/data/list endpoint, and update the getRecoverableModules selector to reference this data.

---

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

Acceptance criteria

• The serialized module data returned by the GET core/modules/data/list endpoint should be updated to include a per-module recoverable flag.
• The getRecoverableModules selector should be updated to reference the recoverable flag in the modules list.
• The recoverModules action should be updated to remove the now-unnecessary logic to update the recoverable modules list in local state.
• From a UI perspective the module recovery flow should continue to behave as it does now.

Implementation Brief

In includes/Core/Modules/Modules.php:

• Within the register method:
  • Remove the code that sets recoverableModules in the googlesitekit_dashboard_sharing_data hook handler.
• Within the prepare_module_data_for_response method:
  • Add a recoverable flag to the module data, with the value of $module->is_recoverable().

In assets/js/googlesitekit/modules/datastore/modules.js:

• Within the getRecoverableModules resolver function:
  • Remove the references to global._googlesitekitDashboardSharingData.
  • Instead, make a call to the getModules selector and create a list of module slugs for modules where the recoverable flag is true. Then pass this list to receiveRecoverableModules.
• Within the recoverModules action:
  • Remove the code that calls getRecoverableModules and receiveRecoverableModules.
  • Instead, yield a call to invalidateResolver for the getRecoverableModules selector.
• Delete the unused recoverModule action. It’s not used, the behaviour is covered by recoverModules, and it’s not worth the maintenance effort to keep an unused and unneeded function around. If we were to keep it, we’d need to update it in the same way as recoverModules, along with its tests.

Test Coverage

• Update the tests for getRecoverableModules and recoverModules to reflect the new implementations.
• Remove the recoverModule tests.
• Fix any failing tests.

QA Brief

• Regression test the “Recover modules” banner.
  • Site up Site Kit and enable the dashboardSharing feature flag.
  • Put the Search Console and/or PageSpeed Insights modules into the recoverable state. This can be achieved by sharing them as a user and then disconnecting that user from Site Kit.
  • View the Dashboard as the first user to see the “Recover modules” banner.
  • Press Recover to recover the module(s).
  • The banner should disappear and the modules should be recovered (settings editable in Dashboard Sharing modal).

“Recover modules” banner:

Changelog entry

• Improve recoverable modules list handling in Dashboard Sharing.

[tofumatt]

Very nice, looks good 👍🏻

IB ✅

[aaemnnosttv]

Just a heads up that I just opened https://github.com/google/site-kit-wp/issues/5416 which is similar to this but specific to permissions. That issue will require a bit more to it but flagging here as a related issue ready for an IB.