feat(flex-linux-setup): add entry to services status permission in all feature READ capability in adminUIResourceScopesMapping table

[duttarnab]

closes #2447

Summary by CodeRabbit

• Chores
  • Extended read-only access permissions across administrative components including dashboards, licenses, settings, webhooks, audit logs, encryption keys, user management, authentication systems, security features, SCIM integration, SAML configuration, session management, and various configuration services.

[coderabbitai]

📝 Walkthrough

Walkthrough

A single LDIF template file is updated to expand read-only access permissions. The license.readonly scope is added to admin UI license and dashboard entries, while data.readonly scope is broadly applied across numerous resource mappings to enable services status endpoint evaluation.

Changes

Cohort / File(s)	Summary
Admin UI Resource Scopes Configuration flex-linux-setup/flex_linux_setup/templates/adminUIResourceScopesMapping.ldif	Adds license.readonly scope to dashboard and license entries; broadly applies data.readonly scope across dashboards, license, mau, settings, webhooks, audit logs, keys, scope resources, configuration, session, user resources, scripts, attributes, cache, persistence, smtp, scim, fido, saml, lock, security, ssa, and authentication components

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Verify that license.readonly was correctly added to both dashboard and license entries
• Confirm data.readonly scope additions are consistent across all intended resource mappings
• Check for any accidental removals or malformed LDIF syntax

Poem

🐰 Scopes expand like clover in spring,
Read-only permissions to everything,
Dashboards and licenses, now they can see,
Services status flowing wild and free,
Admin menus dance with newfound glee! 📊✨

Pre-merge checks and finishing touches

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately reflects the main change: adding data.readonly scope (services status permission) to all feature READ capabilities in the adminUIResourceScopesMapping table.
Linked Issues check	✅ Passed	The PR successfully implements both objectives: adds data.readonly scope to all feature READ capabilities for services status endpoint access, and adds license.readonly scope to Dashboard-Read capability.
Out of Scope Changes check	✅ Passed	All changes are directly aligned with the linked issue objectives and are within scope.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch admin-ui-2447

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d7996d3 and 2f65577.

📒 Files selected for processing (1)

• flex-linux-setup/flex_linux_setup/templates/adminUIResourceScopesMapping.ldif (27 hunks)

🧰 Additional context used

🧠 Learnings (2)

📚 Learning: 2025-11-11T15:17:34.651Z

Learnt from: devrimyatar
Repo: GluuFederation/flex PR: 2440
File: flex-linux-setup/flex_linux_setup/flex_setup.py:519-519
Timestamp: 2025-11-11T15:17:34.651Z
Learning: In flex-linux-setup/flex_linux_setup/flex_setup.py, the webhook LDIF (aui_webhook.ldif) should only be imported during fresh Admin UI installations, not during updates. The import is correctly guarded by the check `client_check_result['2001.'] == -1` which ensures it only runs when the Admin UI Web Client doesn't already exist. Docker update workflows differ from Linux update workflows in this regard.

Applied to files:

• flex-linux-setup/flex_linux_setup/templates/adminUIResourceScopesMapping.ldif

📚 Learning: 2025-11-07T12:55:26.241Z

Learnt from: kdhttps
Repo: GluuFederation/flex PR: 2378
File: admin-ui/plugins/admin/components/Cedarling/CedarlingConfigPage.tsx:93-104
Timestamp: 2025-11-07T12:55:26.241Z
Learning: In the Cedarling configuration feature (admin-ui/plugins/admin/components/Cedarling/CedarlingConfigPage.tsx), the sync role to scopes mappings operation depends on the `auiPolicyStoreUrl`. The backend fetches content from this URL and syncs roles based on the response. Therefore, the audit log for the sync operation should include the `auiPolicyStoreUrl` in its payload to provide proper audit context.

Applied to files:

• flex-linux-setup/flex_linux_setup/templates/adminUIResourceScopesMapping.ldif

🔇 Additional comments (4)

flex-linux-setup/flex_linux_setup/templates/adminUIResourceScopesMapping.ldif (4)

1-11: LGTM! Dashboard READ entry correctly implements both PR objectives.

The dashboard READ entry now includes:

• data.readonly scope (line 7, pre-existing) for services status endpoint access
• license.readonly scope (line 9, newly added) for displaying license details

This aligns with the PR objectives to enable menu visibility based on service availability and show license details on the Dashboard.

---

23-609: Correctly scoped changes - only READ entries modified.

The changes appropriately target only READ access entries. All WRITE and DELETE entries remain unmodified, which correctly implements the PR objective to add the services status permission scope to "all feature READ capabilities" only.

---

1-609: Verify the update mechanism for existing deployments.

This LDIF template is used during setup/installation. For existing deployments upgrading to this version, please confirm:

1. How are changes to this LDIF template applied during upgrades/updates?
2. Will existing adminUIResourceScopesMapping entries be updated automatically to include the new scopes?
3. Do any migration scripts or update procedures need to be modified to handle these scope additions?

Based on learnings, Admin UI updates have specific workflows. Please ensure that the LDIF changes are properly handled during the update process for both fresh installations and upgrades.

Based on learnings

---

13-589: I need to search for where scope definitions are located in the codebase to verify if the data.readonly scope is actually defined.

Based on my analysis of the codebase and verification results, I have identified a critical issue with the original review comment's assumptions.

The adminUIResourceScopesMapping.ldif file references scopes but does not define them—it maps resources to existing scopes. The verification reveals that the data.readonly scope is referenced across 27 READ entries but no evidence exists confirming this scope is actually defined in the system.

The original review comment asks to verify scope definitions and endpoint mappings, but the execution confirms:

• The /jans-config-api/api/v1/health/service-status endpoint exists in the jans-config-api health configuration
• The data.readonly scope is referenced 27 times in all READ access entries (consistent application)
• No service-status endpoint references or scope-to-endpoint mapping configurations were found in the codebase
• The LDIF template file only contains resource-scope mappings; actual scope definitions should exist elsewhere

The verification cannot confirm whether data.readonly is properly defined in the OAuth scope registry. The presence of this scope in the adminUIResourceScopesMapping.ldif alone does not guarantee it is registered and functional. This is a configuration gap that requires verification at deployment time.

---

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.}

[sonarqubecloud]

Quality Gate passed for 'flex_linux_setup'

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud