[feature]: move project to different workspace

[Quadrubo]

Is there an existing issue for this?

• I have searched the existing issues

Summary

It would be nice to be able to move a project to a different workspace.

Why should this be worked on?

When new requirements come in or when projects are being reevaluated, a project may belong to a different workspace than before.

[shadimostafa]

The documentation does not specify the procedure for transferring a project to a different workspace. Hello @vihar , I believe the documentation requires revision, or maybe, the issue may still be unresolved.

[sombek]

any idea how to do this?

[yihaozhadan]

It is pretty easy to achieve by updating the database by SQL query. So it should not be complecated to implement I think.

[hstern]

Verified the SQL approach on CE 1.3.1. Sharing the recipe and the structural facts that make it work — hopefully useful both as a user-side workaround and as a reference for the eventual feature.

Three facts that make the move clean

1. Identifier uniqueness is per-workspace, not global. The projects table has UNIQUE (identifier, workspace_id, deleted_at) plus a partial unique index WHERE deleted_at IS NULL on (identifier, workspace_id). Moving FOO into a workspace that doesn't already have a FOO is conflict-free.

2. Issue assignment is by global user_id, not by workspace_member. issue_assignees.assignee_id references users(id) directly. workspace_members is a separate roles/permissions table that doesn't participate in assignment. So a moved issue's assignees keep working as long as the user is also a member of the destination workspace.

3. The project tree's FKs are DEFERRABLE INITIALLY DEFERRED. All UPDATEs can run in any order within one transaction.

Shape of the work

workspace_id is denormalised onto roughly 83 tables system-wide. For one project transfer, only the subset with rows touching that project needs updating. Discover it dynamically:

SELECT table_name, (xpath('/row/c/text()', xq))[1]::text::int AS rows
FROM (
  SELECT table_name, query_to_xml(format(
    'SELECT COUNT(*) AS c FROM %I WHERE project_id=%L', table_name, '<project-uuid>'
  ), false, true, '') AS xq
  FROM information_schema.columns
  WHERE table_schema='public' AND column_name='workspace_id'
    AND EXISTS (SELECT 1 FROM information_schema.columns c2
                WHERE c2.table_schema='public' AND c2.table_name=table_name AND c2.column_name='project_id')
) t
WHERE (xpath('/row/c/text()', xq))[1]::text::int > 0
ORDER BY rows DESC;

For a typical small project (~163 issues, ~127 comments, ~959 activity rows) this returns ~16 tables and the whole move is ~2,000 rows in one transaction, sub-second.

The transaction

BEGIN;

\set src_project  '''<source-project-uuid>'''
\set dst_ws       '''<destination-workspace-uuid>'''

-- the project row
UPDATE projects SET workspace_id = :dst_ws WHERE id = :src_project;

-- every project-scoped table the discovery query returned, e.g.:
UPDATE issue_activities    SET workspace_id = :dst_ws WHERE project_id = :src_project;
UPDATE issue_labels        SET workspace_id = :dst_ws WHERE project_id = :src_project;
UPDATE issues              SET workspace_id = :dst_ws WHERE project_id = :src_project;
UPDATE issue_sequences     SET workspace_id = :dst_ws WHERE project_id = :src_project;
UPDATE descriptions        SET workspace_id = :dst_ws WHERE project_id = :src_project;
UPDATE issue_comments      SET workspace_id = :dst_ws WHERE project_id = :src_project;
UPDATE issue_assignees     SET workspace_id = :dst_ws WHERE project_id = :src_project;
UPDATE labels              SET workspace_id = :dst_ws WHERE project_id = :src_project;
UPDATE issue_subscribers   SET workspace_id = :dst_ws WHERE project_id = :src_project;
UPDATE issue_relations     SET workspace_id = :dst_ws WHERE project_id = :src_project;
UPDATE states              SET workspace_id = :dst_ws WHERE project_id = :src_project;
UPDATE project_pages       SET workspace_id = :dst_ws WHERE project_id = :src_project;
UPDATE issue_links         SET workspace_id = :dst_ws WHERE project_id = :src_project;
UPDATE project_members     SET workspace_id = :dst_ws WHERE project_id = :src_project;
-- + project_user_properties, user_recent_visits, file_assets, issue_versions, etc. when present

-- pages have workspace_id but no project_id — link via project_pages
UPDATE pages SET workspace_id = :dst_ws
WHERE id IN (SELECT page_id FROM project_pages WHERE project_id = :src_project);

COMMIT;

Sharp edges I'd flag for an official implementation

• Stranded user references. created_by_id, updated_by_id, assignee_id on moved rows should be validated against the destination workspace's membership. Out of the box the SQL doesn't check this — Plane will still render, but permission checks may behave oddly. An official feature should refuse or warn on stranded references.
• Attachments / file_assets. Carries workspace_id; include in the move.
• issue_versions. Carries workspace_id; include for projects using revision history.
• Page subgraph. pages plus page_labels, page_logs, page_versions all need updating, keyed by page_id derived from project_pages.
• Redis cache. Workspace/project metadata cached; a targeted invalidate (or a FLUSHDB during a quiet window) avoids ~1 min of stale workspace routing.
• Constraint surface drift. All of the above held on CE 1.3.1. EE / future CE versions may add tables (e.g. epics, initiatives, stickies) — the discovery query above stays valid because it traverses information_schema.

Happy to share the dry-run output / row counts from a real (small) project move if useful for testing a built-in implementation.

[DouglasAR01]

Verified the SQL approach on CE 1.3.1. Sharing the recipe and the structural facts that make it work — hopefully useful both as a user-side workaround and as a reference for the eventual feature.

Three facts that make the move clean

1. Identifier uniqueness is per-workspace, not global. The projects table has UNIQUE (identifier, workspace_id, deleted_at) plus a partial unique index WHERE deleted_at IS NULL on (identifier, workspace_id). Moving FOO into a workspace that doesn't already have a FOO is conflict-free.
2. Issue assignment is by global user_id, not by workspace_member. issue_assignees.assignee_id references users(id) directly. workspace_members is a separate roles/permissions table that doesn't participate in assignment. So a moved issue's assignees keep working as long as the user is also a member of the destination workspace.
3. The project tree's FKs are DEFERRABLE INITIALLY DEFERRED. All UPDATEs can run in any order within one transaction.

Shape of the work

workspace_id is denormalised onto roughly 83 tables system-wide. For one project transfer, only the subset with rows touching that project needs updating. Discover it dynamically:

SELECT table_name, (xpath('/row/c/text()', xq))[1]::text::int AS rows
FROM (
SELECT table_name, query_to_xml(format(
'SELECT COUNT(*) AS c FROM %I WHERE project_id=%L', table_name, ''
), false, true, '') AS xq
FROM information_schema.columns
WHERE table_schema='public' AND column_name='workspace_id'
AND EXISTS (SELECT 1 FROM information_schema.columns c2
WHERE c2.table_schema='public' AND c2.table_name=table_name AND c2.column_name='project_id')
) t
WHERE (xpath('/row/c/text()', xq))[1]::text::int > 0
ORDER BY rows DESC;
For a typical small project (~163 issues, ~127 comments, ~959 activity rows) this returns ~16 tables and the whole move is ~2,000 rows in one transaction, sub-second.

The transaction

BEGIN;

\set src_project ''''''
\set dst_ws ''''''

-- the project row
UPDATE projects SET workspace_id = :dst_ws WHERE id = :src_project;

-- every project-scoped table the discovery query returned, e.g.:
UPDATE issue_activities SET workspace_id = :dst_ws WHERE project_id = :src_project;
UPDATE issue_labels SET workspace_id = :dst_ws WHERE project_id = :src_project;
UPDATE issues SET workspace_id = :dst_ws WHERE project_id = :src_project;
UPDATE issue_sequences SET workspace_id = :dst_ws WHERE project_id = :src_project;
UPDATE descriptions SET workspace_id = :dst_ws WHERE project_id = :src_project;
UPDATE issue_comments SET workspace_id = :dst_ws WHERE project_id = :src_project;
UPDATE issue_assignees SET workspace_id = :dst_ws WHERE project_id = :src_project;
UPDATE labels SET workspace_id = :dst_ws WHERE project_id = :src_project;
UPDATE issue_subscribers SET workspace_id = :dst_ws WHERE project_id = :src_project;
UPDATE issue_relations SET workspace_id = :dst_ws WHERE project_id = :src_project;
UPDATE states SET workspace_id = :dst_ws WHERE project_id = :src_project;
UPDATE project_pages SET workspace_id = :dst_ws WHERE project_id = :src_project;
UPDATE issue_links SET workspace_id = :dst_ws WHERE project_id = :src_project;
UPDATE project_members SET workspace_id = :dst_ws WHERE project_id = :src_project;
-- + project_user_properties, user_recent_visits, file_assets, issue_versions, etc. when present

-- pages have workspace_id but no project_id — link via project_pages
UPDATE pages SET workspace_id = :dst_ws
WHERE id IN (SELECT page_id FROM project_pages WHERE project_id = :src_project);

COMMIT;

Sharp edges I'd flag for an official implementation

• Stranded user references. created_by_id, updated_by_id, assignee_id on moved rows should be validated against the destination workspace's membership. Out of the box the SQL doesn't check this — Plane will still render, but permission checks may behave oddly. An official feature should refuse or warn on stranded references.
• Attachments / file_assets. Carries workspace_id; include in the move.
• issue_versions. Carries workspace_id; include for projects using revision history.
• Page subgraph. pages plus page_labels, page_logs, page_versions all need updating, keyed by page_id derived from project_pages.
• Redis cache. Workspace/project metadata cached; a targeted invalidate (or a FLUSHDB during a quiet window) avoids ~1 min of stale workspace routing.
• Constraint surface drift. All of the above held on CE 1.3.1. EE / future CE versions may add tables (e.g. epics, initiatives, stickies) — the discovery query above stays valid because it traverses information_schema.

Happy to share the dry-run output / row counts from a real (small) project move if useful for testing a built-in implementation.

I just tested this with a small project and it worked flawlessly.