Skip to content

Promote from the editor (MVP: reuse the existing sandbox merge) #4929

Description

@elias-ba

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.
  • After a successful merge the parent workflow reflects the change and a new version is recorded (Record a version at each go-live and promote #4866).
  • 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.
  • Diverged workflows are surfaced in the merge summary, informational and non-blocking (see Promote safety: surface diverged workflows in the merge #4863).
  • No promotion-request object is created. There is nothing to approve or withdraw.
  • Covered by tests (the promote/merge path and the header behavior).

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, 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.

Part of #4852.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    Status
    New Issues

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions