fix: Request taxonomies with view context for Author/Editor roles by dcalhoun · Pull Request #23291 · wordpress-mobile/WordPress-Android

dcalhoun · 2026-09-03T17:39:09Z

Description

Fix CMM-2398.

An Author or Contributor on an Atomic or self-hosted site got a blocking "Category refresh error" when opening the category picker in the post editor, and could not assign categories at all. Switching the user to Editor cleared it.

Root cause. TaxonomyRsApiRestClient.fetchTerms listed terms with listWithEditContext, i.e. GET /wp/v2/categories?context=edit. WP core gates that context on the taxonomy's edit_terms capability — manage_categories for category, manage_post_tags for post_tag — which Authors and Contributors do not hold, so the API answered 403 rest_forbidden_context. The client turned that into a generic error and the picker reported a refresh failure instead of listing the site's terms.

Listing terms is a read, and the view context returns every field this client maps (no term field is edit-only, and name/description are identical across contexts), so it now requests context=view.

Scope. The taxonomies_rest_api_migration flag is rolled out to 50% of users on 26.9+, so this affects Authors and Contributors on Atomic and self-hosted sites, for both categories and tags. The tags breakage was silent: TagsFragment ignores fetch errors, so tag suggestions simply came back empty.

Testing instructions

Note

Requires a test user set to Author on an Atomic site. The taxonomies_rest_api_migration feature flag must be enabled in the dev menu.

Note that SelectCategoriesActivity only fetches when its list is empty, so clear app storage or sign out and back in before each cold-cache run — a warm cache hides the bug.

Categories (the reported issue):

On trunk, as the Author, open a post → Post Settings → Categories.

Verify the blocking "Category refresh error" appears and no categories are listed

Switch to this branch, clear app storage, sign in as the same Author, and repeat.

Verify the category list loads
Verify selecting categories persists back to the post

Tags (same fix, no cache clearing needed):

As the Author, open a post → Post Settings → Tags and type a letter.

Verify existing tag suggestions appear (on trunk they are silently empty)

Refresh failure handling (unchanged from trunk):

With categories already loaded, use a proxy to fail */categories* with a 500, then pull to refresh.

Verify the cached list stays on screen and a "Category refresh error" toast appears

Regressions:

As an Editor or Admin on the same Atomic site, open the category picker and create a category from the "+" menu.

Verify the list loads and creation still works

Open Site Settings → Categories.

Verify create, rename and ~~delete~~ still work¹

Repeat the category picker check on a WP.com Simple site and on a self-hosted site with an application password.

Verify both still list categories

🤖 Generated with Claude Code

https://claude.ai/code/session_01Y3eKPoHZwqK4AP3GQBSgEG

Deleting is broken: https://github.com/wordpress-mobile/WordPress-Android/issues/23293 ↩

wpmobilebot · 2026-09-03T17:49:37Z

📲 You can test the changes from this Pull Request in WordPress Android by scanning the QR code below to install the corresponding build.

	App Name	WordPress Android
	Build Type	Debug
	Version	pr23291-176af40
	Build Number	`1498`
	Application ID	`org.wordpress.android.prealpha`
	Commit	`176af40`
	Installation URL	1uh3u2l2go69g

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

wpmobilebot · 2026-09-03T17:49:38Z

📲 You can test the changes from this Pull Request in Jetpack Android by scanning the QR code below to install the corresponding build.

	App Name	Jetpack Android
	Build Type	Debug
	Version	pr23291-176af40
	Build Number	`1498`
	Application ID	`com.jetpack.android.prealpha`
	Commit	`176af40`
	Installation URL	3bkf32549uej8

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

codecov · 2026-09-03T17:53:17Z

Codecov Report

❌ Patch coverage is 83.78378% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 38.04%. Comparing base (9fa0185) to head (176af40).
⚠️ Report is 1 commits behind head on trunk.

Files with missing lines	Patch %	Lines
...ork/rest/wpapi/taxonomy/TaxonomyRsApiRestClient.kt	83.78%	2 Missing and 4 partials ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##            trunk   #23291   +/-   ##
=======================================
  Coverage   38.04%   38.04%           
=======================================
  Files        2353     2353           
  Lines      128876   128893   +17     
  Branches    17940    17949    +9     
=======================================
+ Hits        49030    49043   +13     
  Misses      75827    75827           
- Partials     4019     4023    +4

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Listing categories and tags over wordpress-rs used context=edit, which WP core gates on the taxonomy's edit_terms capability (manage_categories / manage_post_tags). Authors and Contributors hold neither, so the REST API answered 403 rest_forbidden_context and the post editor's picker reported a refresh error instead of listing the site's terms. The listing is a read and the view context carries every field this client maps, so request that instead. Term failures now also map 401 and 403 to TaxonomyErrorType.UNAUTHORIZED, keeping the parity TaxonomyXMLRPCClient already has as the wp-rs path replaces it. No caller branches on the type yet, so this shows up only in the taxonomy log lines. Failures are logged through toLogErrorString() rather than interpolating the raw result, which put response bodies in the log. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y3eKPoHZwqK4AP3GQBSgEG

notifyFailedDeleting() wrote one line for two different failures, and once it took the request result it logged a literal null for the case where the request succeeded and the API reported the term as not deleted. Log at the call sites instead, where the result is still in scope, so the two are distinguishable, and let the function take the error it dispatches. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y3eKPoHZwqK4AP3GQBSgEG

createTestAnyTermWithViewContext() was a field-for-field copy of createTestAnyTermWithEditContext(), so every change to the term under test had to be made twice and a test updating only one would assert against divergent data. The generated edit and view types share no supertype, so keep the values in one place and build each type from them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y3eKPoHZwqK4AP3GQBSgEG

adalpari

LGTM and works as expected!

wpmobilebot · 2026-09-04T13:13:03Z

🤖 Build Failure Analysis

This build has failures. Claude has analyzed them - check the build annotations for details.

wordpress-rs 0.8.0 removed WpRequestResult.toLogErrorString(), which these call sites used to describe a failure without its response body. The library now offers a client-level error logger instead, but FluxC's WpApiClientProvider supplies none, so interpolating the result would write the whole body to the log. Log the TaxonomyError each site already maps: it names the failure and carries the server's message, and it omits the body. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Resolves an import conflict in TaxonomyRsApiRestClientTest: trunk's #23291 moved the list request to the view context, so the list response type is TermsRequestListWithViewContextResponse, while this branch's delete-by-remote-id test stubs the request executor and needs TermsRequestExecutor and UniffiWpApiClient. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011pj4FNhM3TFx83R5uDSuYh

dcalhoun changed the title ~~CMM-2398: Request taxonomy terms in the view context~~ fix: Request taxonomies with view context for Author/Editor roles Sep 3, 2026

dcalhoun force-pushed the fix/cmm-2398-author-category-picker branch from 26fd45e to 08a3f76 Compare September 3, 2026 19:15

dcalhoun and others added 3 commits September 3, 2026 15:34

dcalhoun force-pushed the fix/cmm-2398-author-category-picker branch from 08a3f76 to 6fdfbfe Compare September 3, 2026 19:35

dcalhoun marked this pull request as ready for review September 3, 2026 19:48

dcalhoun requested a review from adalpari September 3, 2026 19:48

dcalhoun added [Type] Bug Tag/Category Management labels Sep 3, 2026

dcalhoun added this to the 27.2 milestone Sep 3, 2026

adalpari approved these changes Sep 4, 2026

View reviewed changes

dcalhoun enabled auto-merge (squash) September 4, 2026 12:51

dcalhoun added 2 commits September 4, 2026 08:51

Merge branch 'trunk' into fix/cmm-2398-author-category-picker

d757693

Merge branch 'trunk' into fix/cmm-2398-author-category-picker

d61c729

dcalhoun disabled auto-merge September 4, 2026 14:07

dcalhoun merged commit 88310c2 into trunk Sep 4, 2026
23 checks passed

dcalhoun deleted the fix/cmm-2398-author-category-picker branch September 4, 2026 14:07

Navigation Menu

Uh oh!

fix: Request taxonomies with view context for Author/Editor roles - #23291

fix: Request taxonomies with view context for Author/Editor roles#23291
dcalhoun merged 6 commits into
trunkfrom
fix/cmm-2398-author-category-picker

dcalhoun commented Sep 3, 2026 •

edited by adalpari

Loading

Uh oh!

wpmobilebot commented Sep 3, 2026 •

edited

Loading

Uh oh!

wpmobilebot commented Sep 3, 2026 •

edited

Loading

Uh oh!

codecov Bot commented Sep 3, 2026 •

edited

Loading

Uh oh!

adalpari left a comment

Uh oh!

wpmobilebot commented Sep 4, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

dcalhoun commented Sep 3, 2026 • edited by adalpari Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Testing instructions

Footnotes

Uh oh!

wpmobilebot commented Sep 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wpmobilebot commented Sep 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecov Bot commented Sep 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

adalpari left a comment

Choose a reason for hiding this comment

Uh oh!

wpmobilebot commented Sep 4, 2026

🤖 Build Failure Analysis

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

dcalhoun commented Sep 3, 2026 •

edited by adalpari

Loading

wpmobilebot commented Sep 3, 2026 •

edited

Loading

wpmobilebot commented Sep 3, 2026 •

edited

Loading

codecov Bot commented Sep 3, 2026 •

edited

Loading