Skip to content

feat(design): a new workspace's portal starts on Home - #849

Closed
mortondev wants to merge 1 commit into
feat/portal-design-v2-phase4-menufrom
feat/portal-design-v2-phase4-home-default
Closed

mortondev wants to merge 1 commit into
feat/portal-design-v2-phase4-menufrom
feat/portal-design-v2-phase4-home-default

Conversation

@mortondev

@mortondev mortondev commented Oct 31, 2026 •

Copy link
Copy Markdown
Member

The sixteenth of the stack that builds a new design engine for the portal, and the fourth of phase 4. A new workspace's portal starts on Home; an established workspace's root never changes on upgrade. Behind the portalDesignV2 flag, which new workspaces start with.

What setup does

When a new workspace finishes the goal step, setup publishes the design it starts with:

  • its branding converted, the same conversion an established workspace's branding gets on read;
  • Home on, laid out from the pages its goals turned on (starterHomeBlocks): Welcome, Share an idea with Status, Top ideas with Latest updates, the roadmap and help topics, each only when its page exists.

It is the first published version, from setup (source: 'conversion') with no author, so History shows where it came from.

When it does not

  • An established workspace: its root stays as it is, Home off, until someone turns Home on in Appearance.
  • The design engine off, or custom CSS that a switch would have to carry over: the workspace stays on its theme, as it would today.
  • A workspace that already has a design, published or drafted: it keeps it. Saving the goals again does not lay Home out a second time.
  • PORTAL_DESIGN_ENGINE=legacy still keeps every portal on its theme, published design or not.

Also

The two setup tests that stood in for the settings helpers now pass the real ones through, since setup reads the portal config to lay Home out.

Verification

  • New tests, each checked by breaking the code it covers: the starting design is published as version 1 with no author, and a workspace with a design is left alone; a new workspace's portal starts on Home with the blocks its goals call for (no Status block without the Status goal) and keeps that layout when the goals are saved again; an established workspace with the design engine on, and a new one with it off, get no design.
  • The onboarding, settings, design and server suites pass. Running many onboarding DB suites in parallel on one local database can deadlock on the workspace slug; that happens the same way without this change.

@mortondev
mortondev added this pull request to stack #833 October 31, 2026 03:17
@mortondev
mortondev force-pushed the feat/portal-design-v2-phase4-home-default branch from 1094dbb to f91a5b2 Compare October 31, 2026 04:36
Setup publishes the design a new workspace starts with: its branding
converted, as an established workspace's is on read, with Home on and laid
out from the pages its goals turned on. It is the first version, from
setup, with no author.

Only setup does this, and only for a new workspace with the design engine
on and no custom CSS a switch would have to carry over. A workspace that
already has a design keeps it, and an established workspace's root never
changes on upgrade.

The setup tests that stand in for the settings helpers now pass the real
ones through, since setup reads the portal config to lay Home out.
@mortondev

Copy link
Copy Markdown
Member Author

Condensed into #879. The stack is now five PRs, #878 to #882; this branch is kept as it was.

@mortondev mortondev closed this Nov 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant