docs(cloud): document the operations Layer5 Cloud refuses against platform-provisioned Environments - #1238
Conversation
…e and connection changes Some Environments are provisioned for an organization by the platform rather than created by someone in it, and they hold configuration the platform relies on. The Environments page refuses three operations against them: deleting the Environment, and assigning or removing its Connections. Those Connections are managed from the settings page that owns the feature instead. Documents the refusal where a reader meets it rather than only where it is implemented. Both notes say what to do instead, and the delete note explains why such an Environment stays visible rather than being hidden, since a reader who cannot delete something they can see will otherwise assume a fault. Avoids naming a brand in the new copy: the product's display name resolves from the organization, so the notes describe the platform rather than hardcoding a name. Signed-off-by: miacycle <184569369+miacycle@users.noreply.github.com>
…the managed-Environment notes Re-verifying the preceding commit against meshery-cloud found the refusal set has grown since it was written. The Environments page refuses three operations against a platform-provisioned Environment, but a fourth verb refuses one page over: linking such an Environment to a Workspace (ErrProvisionedEnvironmentWorkspaceMappingRefused, meshery_cloud-3273, landed after the note was drafted). A mapping is a link in the inherited-access chain, so it would hand a Workspace's teams read on the Environment's Connections and the identity-provider credential behind them. Unlinking is deliberately unguarded - it only ever ends access, and it is the remediation for rows written before the guard existed - so the new note says so. Names Layer5 Cloud rather than "the platform". This repository is the user-facing documentation for the hosted product, so the product name is the correct wording here; the branding rule targets the Cloud interface, whose display name resolves per organization. Points both existing notes at the Identity Providers tab by link instead of describing an unnamed "settings page that owns the feature", and states that a managed Environment can still be renamed - only Connection membership, deletion and Workspace linking are refused. The delete note also covers bulk selection, which is refused per row like the single-card delete. Corrects the Identity Providers bullet on the Organization Management page while adjacent to it: it named the control "Delete All \"Identity Providers\"" (the button reads Delete All Identity Providers) and described the teardown as deleting "the environment named, 'Identity Providers'". Resolution no longer keys on that name - the name-based lookup was the escalation the purpose column replaced - and the revert target is Layer5's default identity providers, not "Provider Organization's defaults". Verified by building master and this branch to separate directories and diffing the id= attribute of every heading across both trees: no anchor changed. Signed-off-by: miacycle <184569369+miacycle@users.noreply.github.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe documentation updates describe managed Environment restrictions and the Delete All Identity Providers action. They explain membership, Workspace linking, editing, and deletion behavior. ChangesManaged Environment documentation
Priority: ⬇️ Low Estimated code review effort: 1 (Trivial) | ~5 minutes Merge Risk: ⚪ Minimal · up to The documentation now clearly explains managed Environment restrictions and the Delete All Identity Providers workflow, with no current merge-readiness risk identified. Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 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.
🟢 Approval recommended
The changes are clear, internally consistent with existing linking patterns, and limited to low-risk documentation updates in the intended sections.
Pull request overview
This PR updates Layer5 Cloud documentation to clarify that certain organization-provisioned (“managed”) Environments are intentionally restricted in the UI, and explains why those restrictions exist (notably around identity-provider credentials access) while calling out the few operations that remain allowed.
Changes:
- Adds info callouts explaining that managed Environments cannot be linked to Workspaces, cannot have Connections reassigned from the Environments page, and cannot be deleted from the Environments page (with guidance to the Identity Providers tab instead).
- Clarifies that unlinking managed Environments from Workspaces remains allowed (as a remediation path), and that renaming/editing managed Environments is still permitted.
- Fixes the Identity Providers documentation wording to match the UI control name and correct the described teardown behavior.
File summaries
| File | Description |
|---|---|
| content/en/cloud/guides/workspaces/managing-environments/index.md | Documents managed Environment restrictions for workspace linking, connection membership changes, and deletion, including rationale and remediation guidance. |
| content/en/cloud/guides/organizations/org-management/_index.md | Corrects Identity Providers bullet text to match the UI label and accurately describe the “Delete All Identity Providers” effect. |
Review details
- Files reviewed: 2/2 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
🚀 Preview deployment: https://docs.layer5.io/pr-preview/pr-1238/
|
What this does
Documents that some Environments are provisioned for an organization by Layer5 Cloud rather than created by someone in it - the Environment behind an organization's own identity providers is the shipping example - and that the interface refuses several operations against them.
Two commits:
meshery-cloud@master, plus the corrections that verification turned up.Re-verified against the product
Every claim was checked against
origin/masterin meshery-cloud, not against a summary:ErrProvisionedEnvironmentDeletionRefused(meshery_cloud-3272),server/dao/environment.go:371ErrEnvironmentConnectionAssignmentRefused(meshery_cloud-3270),server/dao/environment.go:537server/dao/environment.go:620ErrProvisionedEnvironmentWorkspaceMappingRefused(meshery_cloud-3273),server/dao/workspace.go:739WorkspaceDAO.RemoveEnvironmentFromWorkspacecarries no purpose predicateUpdateEnvironmentis unguardedWhat had drifted
The refusal set is four operations, not three. The workspace-mapping guard landed in meshery-cloud on 2026-09-05 at 18:02, about an hour after the documentation note was drafted at 16:54, so the note was accurate when written and is not any more. A mapping is a link in the inherited-access chain (
workspaces_environments_mappings->workspaces_teams_mappings), so linking a managed Environment into a Workspace would grant that Workspace's teams read on its Connections and the identity-provider credential behind them. Unlinking is deliberately left unguarded - it only ever ends access, and it is the remediation for rows written before the guard existed - and the new note says so, since a reader who cannot link will otherwise assume they cannot unlink either.Also in this PR (flagged for reviewers)
Delete All "Identity Providers"(the button reads Delete All Identity Providers) and described the teardown as deleting "the environment named, 'Identity Providers'". Resolution no longer keys on that name - the name-based lookup was the escalation thepurposecolumn replaced - and the revert target is Layer5's default identity providers, not "Provider Organization's defaults".Verification
hugobuilds clean; all threerefshortcodes resolve and the#configuring-identity-providers-bring-your-own-credentialstarget anchor exists in the built HTML.id=attribute of every<h1>-<h6>across both trees: no anchor changed, so no external heading link breaks.Summary by CodeRabbit