docs(icp): update ICP docs to reflect current configuration, UI, and behavior#555
docs(icp): update ICP docs to reflect current configuration, UI, and behavior#555itsvishwa wants to merge 5 commits into
Conversation
|
Warning Review limit reached
Next review available in: 47 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThis PR updates ICP documentation for secret encryption, user-store setup, management console labels and table descriptions, and reverse-proxy backend endpoint wording. ChangesSecret encryption documentation
User store setup documentation
ICP management walkthrough docs
Estimated code review effort: 3 (Moderate) | ~25 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
Actionable comments posted: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
en/docs/manage/icp/encrypt-secrets.md (1)
136-157: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winMake the Step 4 TOML example pasteable.
The first half of the example shows
$secret{...}assignments without the enclosing[icp_server.*]sections, so copying this block verbatim would place those keys at the TOML root. Either keep the original section headers around the reference values or mark the snippet as illustrative instead of copy/paste-ready.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@en/docs/manage/icp/encrypt-secrets.md` around lines 136 - 157, The Step 4 TOML example is not pasteable as written because the `$secret{...}` reference assignments appear without their enclosing `[icp_server.secrets]` and `[icp_server.storage]` section headers, which would place them at the TOML root if copied verbatim. Update the example in the encrypt-secrets doc so each reference block keeps the same section context as the ciphertext blocks, or otherwise clearly label it as illustrative only; use the existing `[icp_server.secrets]`, `[icp_server.storage]`, and `[icp_server.storage.secrets]` sections as the anchors for the fix.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@en/docs/manage/icp/encrypt-secrets.md`:
- Around line 165-190: Clarify the note in encrypt-secrets.md so it
distinguishes path resolution from credential matching: in the ICP keystore
setup section, update the guidance near the deployment.toml example and the
`cipherKeystorePath`/`cipherKeystoreAlias` entries to say the keystore file path
only needs to resolve to the same file, while `cipherKeystoreAlias`,
`cipherKeystorePassword`, and `cipherPrivateKeyPassword` must exactly match the
values from `cipher-standalone-config.properties`. Keep the environment variable
note consistent with this distinction.
In `@en/docs/manage/icp/manage-integrations.md`:
- Around line 114-117: The Most Used APIs bullet in the documentation no longer
mentions the error-count field, which is inconsistent with the observability
description. Update the “Most Used APIs” entry in the manage-integrations doc to
include error count alongside per-endpoint request counts and average response
times, keeping the wording aligned with the related APIs observability section.
In `@en/docs/manage/icp/manage-runtimes.md`:
- Around line 46-47: Update the empty-state text in the secrets panel
documentation to reflect that it now includes both bound and unbound secrets. In
manage-runtimes.md, revise the copy associated with the secrets panel so it no
longer says “No bound secrets...” and instead uses wording that matches an empty
list of all secrets for the environment, keeping the surrounding description in
sync with the secrets panel behavior.
In `@en/docs/manage/icp/reverse-proxy.md`:
- Line 21: The default endpoint wording in the reverse-proxy documentation is
incorrect and should reflect the full path-specific defaults. Update the text
around the settings description so it references the actual default endpoints
used by the console frontend, including the GraphQL, auth, and observability
paths, and adjust the surrounding explanation in the reverse-proxy section to
keep the `deployment.toml` propagation guidance consistent.
---
Outside diff comments:
In `@en/docs/manage/icp/encrypt-secrets.md`:
- Around line 136-157: The Step 4 TOML example is not pasteable as written
because the `$secret{...}` reference assignments appear without their enclosing
`[icp_server.secrets]` and `[icp_server.storage]` section headers, which would
place them at the TOML root if copied verbatim. Update the example in the
encrypt-secrets doc so each reference block keeps the same section context as
the ciphertext blocks, or otherwise clearly label it as illustrative only; use
the existing `[icp_server.secrets]`, `[icp_server.storage]`, and
`[icp_server.storage.secrets]` sections as the anchors for the fix.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 4c0ef5c0-b5d4-4d3c-9bd5-10c0aef5d339
📒 Files selected for processing (9)
en/docs/manage/icp/access-control.mden/docs/manage/icp/encrypt-secrets.mden/docs/manage/icp/manage-environments.mden/docs/manage/icp/manage-integrations.mden/docs/manage/icp/manage-projects.mden/docs/manage/icp/manage-runtimes.mden/docs/manage/icp/reverse-proxy.mden/docs/manage/icp/user-stores/default-user-store.mden/docs/manage/icp/user-stores/ldap-user-store.md
Broken links, images & orphan pages
Links/images come from one crawl of the production build (baseUrl-aware). Orphans are docs not referenced by Summary
Broken links & imagesIntroduced by this PRNo new broken link(s)/image(s) introduced by this PR. ✅ Already on
|
|
Please hold off on merging this PR until issue #1779 (wso2/product-integrator#1779) is resolved. Once that's done, we'll need to incorporate the related SSO configuration documentation changes into this PR before it goes in. |
We cannot add the new callback path to the documentation until after the next release because the users will not have the updated pack |
Sure, then let's handle the SSO config doc separately. |
| 2. Authenticates the user by attempting an LDAP bind with their DN and password. | ||
| 3. Reads the user's group memberships from the directory. | ||
| 4. If any group matches a configured admin role, the user is granted ICP super-admin **on first login** (by adding them to the built-in *Super Admins* group). | ||
| 4. If any group matches a configured admin role, the user is granted ICP super-admin (by adding them to the built-in *Super Admins* group). This happens only on the user's **first login** and is not re-evaluated on subsequent logins. |
Purpose
Fix missing configuration steps, incorrect UI labels, and outdated behavior descriptions across multiple ICP management pages.
resolves https://github.com/wso2-enterprise/integration-engineering/issues/1713
Approach
Summary by CodeRabbit
Summary by CodeRabbit