Skip to content

fix: normalize space id in SpaceCategoryPlugin so category links apply to spaces - EXO-88506 - #5895

Open
bmestrallet wants to merge 3 commits into
feature/ai-contributionfrom
feat/EXO-88506-space-category-id-normalization
Open

fix: normalize space id in SpaceCategoryPlugin so category links apply to spaces - EXO-88506#5895
bmestrallet wants to merge 3 commits into
feature/ai-contributionfrom
feat/EXO-88506-space-category-id-normalization

Conversation

@bmestrallet

Copy link
Copy Markdown

Fixes the space half of EXO-88506: MCP category linking (and any caller passing a non-technical space id) succeeded and read back as linked, but the space UI/REST never reflected it.

Root cause

Category links are generic (objectType, objectId) metadata, but the space UI/REST read a denormalized space.getCategoryIds() kept in sync only by CategoryLinkModifiedListener, whose SPACE branch does spaceService.getSpaceById(Long.parseLong(object.getId())) — i.e. it requires the space technical id. SpaceCategoryPlugin never overrode getObject(), so when a caller passed the space identity id (how spaces are referenced across the platform) or a pretty name, the raw link was written + read back under that id (false success), but the listener resolved the wrong space/null and never updated categoryIds. Activities worked because they have a single id.

Fix

Override CategoryPlugin.getObject(...) in SpaceCategoryPlugin to normalize any incoming id form (technical id / identity id / pretty name) to the canonical technical id String.valueOf(space.getSpaceId()). Because link()/unlink()/getLinkedIds() and the listener all funnel through getObject(), the write, read-back and denormalization now agree regardless of which id was passed. Resolution tries getSpaceById first (so a valid technical id is never re-interpreted), then identity-id via IdentityManager, then pretty name; unresolvable ids pass through unchanged.

Tests + live verification

  • SpaceCategoryPluginUnitTest (technical/identity/pretty-name all normalize) + a new CategoryLinkServiceTest case linking a space by identity id and asserting space.getCategoryIds() reflects it (fails without this fix). Both green.
  • Verified live on a 7.3.x-ai-contribution build: linking a space by technical id (UI path) and by identity id (MCP path) both make the space appear under the category directory filter; the working technical-id path is unchanged (idempotent normalization).

🤖 Generated with Claude Code

aycherif and others added 3 commits July 14, 2026 01:38
The Theme management page's default page background color (used both as
the picker's placeholder and normalized when reading an already
persisted 6-digit value) had no alpha channel, so the color picker
silently dropped its transparency slider. Also stop the gradient from/to
parser from garbling non-linear-gradient values (e.g. conic gradients
set elsewhere) instead of falling back to solid color.
…y to spaces - EXO-88506

Category links are generic metadata keyed on (objectType, objectId), but the
space UI/REST reads a denormalized space.getCategoryIds() kept in sync only by
CategoryLinkModifiedListener, whose SPACE branch resolves the space via
spaceService.getSpaceById(object.getId()) and therefore requires the space
technical id. SpaceCategoryPlugin did not override getObject(), so when a caller
(e.g. the MCP tooling) passed the space identity id or its pretty name, the raw
link was written/read-back under that id (false success) while the listener
resolved the wrong space or null, leaving space.categoryIds untouched and the UI
empty.

Override CategoryPlugin.getObject() to normalize any incoming space id form
(technical id, social Identity id or pretty name) to the canonical technical id
String.valueOf(space.getSpaceId()). Since link()/getLinkedIds() and the listener
all funnel through getObject(), the write, the read-back and the denormalization
now agree regardless of which id was supplied. Unresolvable ids are returned
unchanged rather than silently corrupted.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@bmestrallet
bmestrallet requested a review from ahamdi July 19, 2026 23:49
@sonarqubecloud

Copy link
Copy Markdown

Jihed525 added a commit that referenced this pull request Jul 20, 2026
…y to spaces - EXO-88506

Backport of #5895 onto develop.

Overrides CategoryPlugin.getObject() in SpaceCategoryPlugin to normalize the technical id / identity id / pretty name to the canonical String.valueOf(space.getSpaceId()), so space category links written via non-technical ids (e.g. MCP calls) are correctly reflected in space.getCategoryIds(). Unresolvable ids are returned unchanged rather than silently corrupted.

Note: source PR #5895 is still open upstream (not yet merged into feature/ai-contribution); this backport is being pushed to develop at the requester's explicit direction, in parallel with mcp-server #16 and content #838, which all address the same category-MCP-tools ticket (EXO-88506).
Backport notes

Cherry-picked commit 70db850 cleanly onto develop, no conflicts.
Test

    mvn -pl component/core -am -Dcheckstyle.skip=true -DskipTests install → BUILD SUCCESS
    mvn -pl component/core -Dcheckstyle.skip=true -Dtest=SpaceCategoryPluginUnitTest,CategoryLinkServiceTest test → 8 tests, 0 failures/errors

🤖 Generated with Claude Code
@exo-swf
exo-swf force-pushed the feature/ai-contribution branch 7 times, most recently from 66cf47b to 102b2fa Compare July 27, 2026 01:39
@exo-swf
exo-swf force-pushed the feature/ai-contribution branch from 102b2fa to ce9ed1d Compare July 28, 2026 11:13
@bmestrallet
bmestrallet force-pushed the feature/ai-contribution branch from ce9ed1d to d7293f4 Compare July 28, 2026 12:18
@exo-swf
exo-swf force-pushed the feature/ai-contribution branch from d7293f4 to 266691b Compare July 28, 2026 13:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants