CMM-2304: Detect Jetpack status on the application-password path - #23262
Conversation
Generated by 🚫 Danger |
|
|
|
|
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## trunk #23262 +/- ##
==========================================
- Coverage 37.82% 37.80% -0.03%
==========================================
Files 2347 2348 +1
Lines 128362 128445 +83
Branches 17774 17805 +31
==========================================
+ Hits 48555 48560 +5
- Misses 75851 75925 +74
- Partials 3956 3960 +4 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Resolve the stored row before dispatching a site fetch, carry it into every WPAPI fetch as previousSite (one carry-forward mechanism with fresh-over-stale precedence), yield a blog id another row already owns before writing instead of retrying after the constraint fires, treat non-null detection results as definitive, and reuse one WpRequestExecutor in the connection fetcher.
Collapse the three identical JetpackConnectionState constructions into one and derive isConnected from wpComSiteId, making the null-iff- disconnected invariant structural instead of documented.
This comment was marked as resolved.
This comment was marked as resolved.
Replace the UrlUtils scheme handling in storedWPAPISite with plain string checks (UrlUtils touches unmocked Android APIs under plain JUnit), and let the fetchSite error tests tolerate the intended stored-row read while still asserting nothing is written.
|
Could you double check this is intended?
And I think this one is worth a shot too.
|
There was a problem hiding this comment.
This is a great fix and it works as expected!!
I just left a couple of comments and another addition:
- When asked to log into WP.COM account after trying to open stats, I'm being redirected to MySite screen. Would it be possible to be redirected ti stats directly?
An absent namespaces list now carries the stored Jetpack state forward instead of definitively clearing it, and the stored-row lookup tries both schemes even when the caller's URL already has one.


Description
TL/DR: Sites added with an application password never get their Jetpack flags detected, so the Jetpack app shows "Install Jetpack" when tapping Stats on a site that already has it. This PR adds detection to the WPAPI fetch path in fluxc.
During the site fetch, the
jetpack/REST namespace is used as a cheap negative filter, thenwp/v2/pluginsconfirms the actual Jetpack plugin (the namespace alone also comes from Boost/Protect/Social), andjetpack/v4/connection(via wordpress-rs) supplies the connection state and WP.com blog id. Anything that can't be determined — e.g. a non-admin application password can't list plugins — is carried forward from the stored row, never flipped.SiteStorealso stops discarding the whole update when the discovered blog id collides with an existing WP.com copy of the same site, and refreshes from the stored row so a stale in-memory model can't undo previous writes.No app-module changes: once the flags are real, the existing stats gate routes correctly. The WordPress app's Jetpack-removal overlay false positive (Bug 2 in the Linear issue) is a separate follow-up PR.
Fixes Bug 1 of https://linear.app/a8c/issue/CMM-2304/
Testing instructions
Jetpack app, site with Jetpack connected:
Site without Jetpack: