You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a workflow builder editing in a sandbox, I want a Promote action that merges my changes back into the parent project using the sandbox merge we already have, with the same authorization, so that I can complete the round trip now without waiting on a review-and-approval system we have not built yet.
Context
For the first release, promotion is simply merging. It reuses the existing sandbox merge (Sandboxes.merge/4 into MergeProjects) and the existing merge_sandbox authorization policy (owner and admin). There is no promotion request, no pending or withdraw, and no approval gate. Those belong to the later branch-protection phase (#4861, #4862).
Acceptance criteria
From the collaborative editor while in a sandbox, a Promote action merges the edited workflow back into the parent using the existing merge, scoped to that workflow.
Authorization matches today's sandbox merge (merge_sandbox: owner and admin). No new policy is introduced.
The promote flow archives the sandbox by calling schedule_sandbox_deletion after the merge succeeds. Note: Sandboxes.merge/4 does not archive on its own, the existing sandbox-merge LiveView does it as a separate call, so this flow must replicate that (see sandboxes: soft delete on merge #4649). Archiving is not atomic with the merge, so the merged-but-not-archived case is handled gracefully.
The collaborative editor header must be coherent inside a sandbox: show Promote, and suppress the go-live / switch-to-draft controls that only apply to a workflow on its own project. After a successful promote the sandbox is archived, so the header should reflect the archived, read-only state rather than leaving stale controls.
Scope and key surfaces
Collaborative editor header (the in-sandbox Promote action and the control suppression above), Sandboxes.merge/4, the merge_sandbox policy, schedule_sandbox_deletion, and the existing merge summary UI in the sandbox LiveView (reuse rather than rebuild where practical).
Dependencies
Builds on Edit in sandbox (#4859). Pairs with the diverged surfacing (#4863) and the parent-added-workflow fix (#4919). Version recording (#4866) hangs a release off this promote, so this path must create a snapshot of the merged parent workflow and record who promoted (to be confirmed against the merge/provisioner path).
Note
Promotion requests (pending and withdraw) and the approval-and-validation step are deliberately deferred to the branch-protection phase (#4861, #4862). This issue is the now-path.
As a workflow builder editing in a sandbox, I want a Promote action that merges my changes back into the parent project using the sandbox merge we already have, with the same authorization, so that I can complete the round trip now without waiting on a review-and-approval system we have not built yet.
Context
For the first release, promotion is simply merging. It reuses the existing sandbox merge (
Sandboxes.merge/4intoMergeProjects) and the existingmerge_sandboxauthorization policy (owner and admin). There is no promotion request, no pending or withdraw, and no approval gate. Those belong to the later branch-protection phase (#4861, #4862).Acceptance criteria
merge_sandbox: owner and admin). No new policy is introduced.schedule_sandbox_deletionafter the merge succeeds. Note:Sandboxes.merge/4does not archive on its own, the existing sandbox-merge LiveView does it as a separate call, so this flow must replicate that (see sandboxes: soft delete on merge #4649). Archiving is not atomic with the merge, so the merged-but-not-archived case is handled gracefully.In-sandbox header (deferred here from #4901)
The collaborative editor header must be coherent inside a sandbox: show Promote, and suppress the go-live / switch-to-draft controls that only apply to a workflow on its own project. After a successful promote the sandbox is archived, so the header should reflect the archived, read-only state rather than leaving stale controls.
Scope and key surfaces
Collaborative editor header (the in-sandbox Promote action and the control suppression above),
Sandboxes.merge/4, themerge_sandboxpolicy,schedule_sandbox_deletion, and the existing merge summary UI in the sandbox LiveView (reuse rather than rebuild where practical).Dependencies
Builds on Edit in sandbox (#4859). Pairs with the diverged surfacing (#4863) and the parent-added-workflow fix (#4919). Version recording (#4866) hangs a release off this promote, so this path must create a snapshot of the merged parent workflow and record who promoted (to be confirmed against the merge/provisioner path).
Note
Promotion requests (pending and withdraw) and the approval-and-validation step are deliberately deferred to the branch-protection phase (#4861, #4862). This issue is the now-path.
Part of #4852.