Fetch managedInUserStore data for sub org claim validation

[PasinduYeshan]

Purpose

$subject

Related Issues

• Selective Configuration of Store Location for Claims product-is#26159

Summary by CodeRabbit

• Chores
  • Improved local claim update validation to respect an explicitly provided "managed-in-user-store" flag.
  • Adjusted internal retrieval during claim validation so the managed-in-user-store attribute is conditionally considered.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[wso2-engineering]

AI Agent Log Improvement Checklist

⚠️ Warning: AI-Generated Review Comments

• The log-related comments and suggestions in this review were generated by an AI tool to assist with identifying potential improvements. Purpose of reviewing the code for log improvements is to improve the troubleshooting capabilities of our products.
• Please make sure to manually review and validate all suggestions before applying any changes. Not every code suggestion would make sense or add value to our purpose. Therefore, you have the freedom to decide which of the suggestions are helpful.

✅ Before merging this pull request:

• Review all AI-generated comments for accuracy and relevance.
• Complete and verify the table below. We need your feedback to measure the accuracy of these suggestions and the value they add. If you are rejecting a certain code suggestion, please mention the reason briefly in the suggestion for us to capture it.

Comment	Accepted (Y/N)	Reason
#### Log Improvement Suggestion No: 1

[coderabbitai]

Walkthrough

validateLocalClaimUpdate now inspects the incoming claim's properties for MANAGED_IN_USER_STORE_PROPERTY and passes that boolean into getLocalClaim(...), changing claim retrieval to conditionally fetch the managed-in-user-store property.

Changes

Cohort / File(s)	Change Summary
Server claim update logic components/org.wso2.carbon.identity.api.server.claim.management/.../ServerClaimManagementService.java	Added import for MANAGED_IN_USER_STORE_PROPERTY. In validateLocalClaimUpdate, compute fetchManagedInUserStoreProperty from incomingLocalClaim.getClaimProperties().containsKey(MANAGED_IN_USER_STORE_PROPERTY) and pass it as a third argument to getLocalClaim(...), altering retrieval to respect that flag.

Sequence Diagram(s)

sequenceDiagram
    participant Caller
    participant Service as ServerClaimManagementService
    participant Store as ClaimStore

    Caller->>Service: validateLocalClaimUpdate(incomingLocalClaim, claimURI, tenant)
    Service->>Service: compute fetchManagedInUserStoreProperty = incomingLocalClaim.claimProperties contains MANAGED_IN_USER_STORE_PROPERTY
    Service->>Store: getLocalClaim(claimURI, tenant, fetchManagedInUserStoreProperty)
    Store-->>Service: LocalClaim (with/without managedInUserStore)
    Service-->>Caller: validation result / proceed

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Pay attention to the correctness of the property key import and the boolean computation.
• Verify that passing the flag to getLocalClaim aligns with other call sites and does not change error handling.

Possibly related PRs

• Introduce managedInUserStore claim property #1030: Introduced/used the fetchManagedInUserStoreProperty flag and related managedInUserStore handling in getLocalClaim call sites.

Suggested reviewers

• sadilchamishka

Poem

🐰 A tiny flag I found today,
I hop inside the claim update way.
One boolean saved, one call made new,
Fetching just what the properties cue.
🥕✨

Pre-merge checks and finishing touches

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The PR description is incomplete, missing critical sections like Goals, Approach, User Stories, Developer Checklist, Release notes, Documentation, and other required template sections.	Complete the PR description by filling out all required sections from the template, particularly Goals, Approach, Release notes, and Documentation sections.
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately and specifically describes the main change: fetching managedInUserStore data for sub-org claim validation, which aligns with the code modifications.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

• Provide your own instructions using the high_level_summary_instructions setting.
• Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
• Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
4. 📊 Contributor Summary — Include a Markdown table showing contributions:
   | Contributor | Lines Added | Lines Removed | Files Changed |
5. ✔️ Additional Notes — Add any extra reviewer context.
   Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[jenkins-is-staging]

PR builder started
Link: https://github.com/wso2/product-is/actions/runs/19563849358

[jenkins-is-staging]

PR builder completed
Link: https://github.com/wso2/product-is/actions/runs/19563849358
Status: failure

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 4bb95b1 and fad2d63.

📒 Files selected for processing (1)

• components/org.wso2.carbon.identity.api.server.claim.management/org.wso2.carbon.identity.rest.api.server.claim.management.v1/src/main/java/org/wso2/carbon/identity/rest/api/server/claim/management/v1/core/ServerClaimManagementService.java (2 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

components/org.wso2.carbon.identity.api.server.claim.management/org.wso2.carbon.identity.rest.api.server.claim.management.v1/src/main/java/org/wso2/carbon/identity/rest/api/server/claim/management/v1/core/ServerClaimManagementService.java (1)

components/org.wso2.carbon.identity.api.server.common/src/main/java/org/wso2/carbon/identity/api/server/common/ContextLoader.java (1)

• ContextLoader (42-146)

🔇 Additional comments (1)

components/org.wso2.carbon.identity.api.server.claim.management/org.wso2.carbon.identity.rest.api.server.claim.management.v1/src/main/java/org/wso2/carbon/identity/rest/api/server/claim/management/v1/core/ServerClaimManagementService.java (1)

179-179: LGTM - Import is appropriate.

The import for MANAGED_IN_USER_STORE_PROPERTY is correctly added to support the conditional fetching logic below.

[PasinduYeshan]