Shared requests should not be attempted for recoverable modules
See original GitHub issueBug Description
If a request for module data which is shared by its owner happens to be for a module which is also recoverable, it should not be attempted although this is currently what’s happening.
Steps to reproduce
- Connect with Admin A
- Share Search Console with Admins
- Disconnect Admin A
- Connect with Admin B
- See data errors about lack of granted scopes, even though the current user has the scopes
Screenshots

Do not alter or remove anything below. The following sections will be managed by moderators only.
Acceptance criteria
- Module data requests for recoverable modules should not qualify to be executed as a shared request
Implementation Brief
- Define a new public
Module::is_recoverablemethod, similar tois_shareable - Return a boolean from a new filter
googlesitekit_is_module_recoverablewhich defaults tofalseand passes through its slug as the only extra parameter - Update
Modulesto hook into this filter and run the callback through itsis_module_recoverablemethod - Update the condition in
Module::get_oauth_client_for_datapointto additionally require the module is not recoverable (using the new method) in order to return the owner oauth client- Additionally, ensure the owner’s client satisfies the base scopes (using
validate_base_scopes) as a final check before returning, otherwise falling back to the default client
- Additionally, ensure the owner’s client satisfies the base scopes (using
- Finish and merge https://github.com/google/site-kit-wp/pull/5384
Test Coverage
- Add test for added
is_recoverablemethod
QA Brief
- Follow steps to reproduce above before and after to ensure the request works as expected when the current admin has the granted scopes if the module is recoverable
Changelog entry
- Do not attempt to make requests for module data where the module is shared and also recoverable.
Issue Analytics
- State:
- Created a year ago
- Comments:6 (1 by maintainers)
Top Results From Across the Web
PK25284: DYNAMIC BACKOUT REQUEST SLDS MOUNTS FAR ...
While attempting to dynamically backout databases for an application that received ABENDU0240, an IMS TYPE43 pad record is returned instead of a TYPE50...
Read more >'module' object not callable when trying to log into webpage ...
It seems like that is no dedicated URL for the log-in. The code that I wrote is as such: import requests from bs4...
Read more >How to fix "The following module is missing from the file ...
Then either go to the Modules page and disable/uninstall it from there, or use Drush ( drush dis module_name && drush pm-uninstall module_name...
Read more >Best practices for using Terraform | Google Cloud
... is responsible for the module. Before any pull request is merged, an owner should approve it. ... Shared modules must not declare...
Read more >Windows Admin Center known issues | Microsoft Learn
In the 1910.2 release of Windows Admin Center, you may not be able to ... version numbers of OSS running in Windows Admin...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

After taking a closer look here, the problem is that while the module’s owner is properly updated, the recovering user’s capabilities are not updated to reflect this. This is why the settings show properly after a page refresh but not immediately after recovering the module.
I’ve opened #5416 to address this. @mohitwp as mentioned before this is a related bug but caused by this issue. Thanks for raising it 👍
Thank you @aaemnnosttv
QA Update ✅
Verified
https://user-images.githubusercontent.com/94359491/175037151-a12618a6-7702-4281-beaf-749262294c69.mp4