MotirBuilding in public
MOTIR · moooon
onMotir
You’re viewing a public project. Anyone can view it — no account needed. Sign in to submit, upvote, or comment on requests.View-only — you can’t edit work items
MOTIR-394

6.10.9 Copy-on-create — seed a new workspace’s config from the source workspace (the "looks-inherited" behaviour)

Cancelled
Description

Estimate: 75m · Depends on: 6.10.4, 6.10.10

❌ CANCELLED (Yue, 2026-06-14) — will NOT be built. Kept as a tombstone for traceability. This card assumed config lives at the org/workspace level and a new workspace would inherit it. The shipped schema disagrees: workflow statuses, boards, custom fields, labels, components, automation rules and saved filters are all projectId-scoped (only dashboards are workspace-scoped), seeded per-project at project-create from hardcoded defaults — and a freshly-created workspace has no project, so there is nothing workspace-level to clone. Decision (Path B, Yue): a new workspace simply starts with its own fresh defaults — different custom fields / components / workflow per workspace is desirable, not a bug — and config is not copied automatically. The shipped 6.10.5 create flow (createWorkspaceAction → name-only workspacesService.createWorkspace) already does exactly this, so the cancellation requires no code change. If an "open pre-configured" experience is ever wanted, it belongs at PROJECT create (copy settings from an existing project — Jira’s actual shape, the cited mirror), as a future enhancement, NOT here. The 6.10.10 design’s copy-source-picker / "what gets copied" panels are superseded by this decision (the dialog stays name-only). Original spec below, retained for the record.

Make a newly-created workspace open already configured like the workspace it was created from, so multi-workspace looks inherited — WITHOUT any data-inheritance layer (6.10.2 §6e). When a user creates a 2nd+ workspace under an org, deep-copy the source workspace’s config into the new workspace in the SAME transaction as the workspace creation; thereafter the workspaces are fully independent and either can overwrite. There are NO org-level config defaults, NO override rows, and NO runtime resolution — config stays purely Workspace-scoped; this is a one-time snapshot at creation.

Why its own subtask. The copy spans MANY workspaceId-scoped config tables, each with intra-workspace references that must be remapped to the new workspace’s rows (e.g. a board column points at a workflow status; an automation rule references a field/label) — a naive row-copy that keeps old ids would cross-link the two workspaces. So it needs a dedicated, carefully-ordered clone with an old→new id map, not a one-liner folded into 6.10.4.

What to copy (the workspace-config surface): workflow statuses + transitions, custom field definitions, labels, components, board(s) + board columns + column→status mappings, automation rules, dashboards, and saved filters — i.e. the workspaceId-scoped config models, NOT the work items / sprints / comments (content, never copied). The source workspace = the org’s existing workspace the user is creating from (for the first split, the sole existing workspace); document the selection.

4-layer (motir-core/CLAUDE.md). A workspacesService flow (extending the existing create-workspace path that 6.10.4 made org-aware) wraps the create + the clone in ONE prisma.$transaction; each table’s rows are copied via its repository (writes require tx); the old→new id map is built in the service. Returns the new workspace DTO. Idempotency is not required (each create is a fresh workspace), but the clone must be ALL-or-nothing (one tx).

Acceptance criteria

  • Creating a workspace under an org with an existing workspace produces a new workspace whose workflow statuses/transitions, custom fields, labels, components, board(s)+columns+column→status mappings, automation rules, dashboards and saved filters MATCH the source at creation time.
  • No cross-linking: every copied row references the NEW workspace’s rows (the id map is applied) — e.g. a copied board column points at the copied status, never the source workspace’s; editing one workspace’s config does not affect the other.
  • Work items, sprints, comments and other CONTENT are NOT copied (only config).
  • The whole create+clone is ONE transaction (all-or-nothing); the service owns it, repositories are single-op with required tx.
  • No org-level config / override / resolution is introduced (config stays Workspace-scoped — the copy is a one-time snapshot).

Context refs

  • 6.10.2 §6e — the copy-on-create decision (no data inheritance).
  • 6.10.10 — the create-workspace flow DESIGN this implements (the dialog, the copy-source picker, the states); build to it, do not improvise the surface.
  • 6.10.4 — the org-aware create-workspace flow this extends + the signup auto-provision (the first workspace) it mirrors.
  • motir-core/prisma/schema.prisma — the workspaceId-scoped config models to clone (workflowStatuses/transitions, customFieldDefinitions, labels, components, boards/boardColumns/boardColumnStatuses, automationRules, dashboards, savedFilters) + their intra-workspace FKs to remap.
  • motir-core/CLAUDE.md § 4-layer (service owns the tx; repos single-op, required tx on writes).