docs(adr): ADR-0075 — configurable, opt-out-able post-login landing#2367
Closed
os-zhuang wants to merge 2 commits into
Closed
docs(adr): ADR-0075 — configurable, opt-out-able post-login landing#2367os-zhuang wants to merge 2 commits into
os-zhuang wants to merge 2 commits into
Conversation
The console hardcodes the post-login landing (CloudAwareRootRedirect's literal PREFERRED_APPS=['cloud_control'] → /apps/cloud_control, else /home launcher), so a deployment can neither opt out of the outer /home nor customize it without forking the SPA, and app `isDefault` is a badge that doesn't route. Propose resolving the landing from a `console.default_landing` setting reusing ADR-0007's SettingsService order (env override → tenant → user → manifest default), values auto | home | app:<name> | page:<name>; wire isDefault into the `auto` resolver; replace CloudAwareRootRedirect with a LandingResolver and demote cloud to a consumer. Back-compat: default `auto` equals today's multi-app /home. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
github-actions
Bot
added
documentation
… Settings UI Per review: the post-login landing is a product-definition decision the developer/ISV makes in metadata/source at build time, not a runtime per-tenant admin preference. Drop the Settings-Manifest namespace + sys_setting story. Resolve from existing app metadata instead: wire `isDefault` into root routing (land in the default app; its existing `homePageId` selects the page), with a single-app/`/home` fallback and an optional deploy-time env override as a secondary ops escape hatch. Concentrates the change in objectui (one resolver replacing the PREFERRED_APPS hardcode); likely no framework spec change. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Contributor
Author
|
Closing without merging — per review, this change is too small to warrant a standalone ADR. It reuses existing app metadata ( |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Design proposal — for review (docs only)
Makes the post-login landing a metadata-declared, opt-out-able capability instead of a hardcode.
Problem
The console hardcodes where users land after sign-in:
CloudAwareRootRedirectcarries a literalPREFERRED_APPS = ['cloud_control'](→/apps/cloud_control, else the/homelauncher). A deployment can neither opt out of the outer/home(e.g. our cloud service doesn't want it) nor land somewhere custom without forking the SPA. AppisDefaultis a badge that doesn't route.Key framing (from review)
The landing is a product-definition decision made at build/dev time by whoever builds a product on the framework (declared in metadata/source) — not a runtime, per-tenant, admin-UI preference.
Proposal (metadata-native, near-zero new schema)
Resolve from existing app metadata:
isDefaultinto root routing — land in theisDefaultapp; its existinghomePageIdselects the landing page inside it. "Custom home" = your app + itshomePageId(an ADR-0065 page). No settings namespace, nopage:<name>top-level concept.isDefault): single visible app → it; else today's/homelauncher (unchanged).CloudAwareRootRedirect's hardcode with a genericLandingResolver. Cloud already hascloud_controlisDefault: true, so behavior is preserved and the hardcode is deleted.Explicitly NOT doing
No
console.default_landingSettings-Manifest namespace, no per-tenantsys_setting, no Settings UI, no per-tenant runtime landing. (An earlier draft proposed the Settings route — dropped per review.)Back-compat
No
isDefaultapp → unchanged/home. Cloud → unchanged (still lands oncloud_control), minus the hardcode. Likely no framework spec change beyond documentingisDefault's routing semantics; the work concentrates in objectui.Seeking design sign-off before implementing.
🤖 Generated with Claude Code