Elements: Support create-and-publish and update-and-publish as a single operation

[AndyButland]

Description

This applies the "save and publish as a single operation" capability — introduced for documents in #22812 — to elements.

Background

#22812 introduced atomic create-and-publish and update-and-publish operations for documents, so the backoffice can create/update and publish in a single server round-trip rather than a save followed by a separate publish call. It added:

• IContentService.SaveAndPublish(...) with the underlying single-scope implementation.
• IContentEditingService.CreateAndPublishAsync / UpdateAndPublishAsync.
• Management API CreateAndPublishDocumentController / UpdateAndPublishDocumentController (with an additional publish-permission check on top of create/update).
• Client wiring: combined createAndPublish / updateAndPublish data-source methods, a shared request-body mapper, and a persist-strategy in the document publishing workspace context (replacing the old two-step save-then-publish), plus publish-failure notifications.

Elements are a publishable content type built on the same content base classes as documents and support save-and-publish, but had not received this capability. This PR closes that gap.

Changes

Server (services)

• Promotes SaveAndPublish to the shared IPublishableContentService<T> (default implementation) and PublishableContentServiceBase<T> (real single-scope implementation), so both documents and elements inherit one implementation — aligning with how Save / Publish / Unpublish already live on the base.
• Adds CreateAndPublishAsync / UpdateAndPublishAsync to IElementEditingService / ElementEditingService.

Server (Management API)

• CreateAndPublishElementController (POST …/create-and-publish) and UpdateAndPublishElementController (PUT …/{id}/update-and-publish), plus the corresponding request models. Both perform the additional ActionElementPublish authorization check on top of create/update.

Client (backoffice)

• Regenerated OpenApi.json and the typed API client for the new endpoints.
• Adds element-detail-request.mappers.ts, combined createAndPublish / updateAndPublish on the element publishing data-source and repository, and a persist-strategy rewrite of the element publishing workspace context.
• Refactors the element split-view variant selector to reuse the shared UmbPublishableSplitViewVariantSelectorElement base class.
• Aligns publish-failure and reload-failure notifications with the document behaviour.

Testing

Automated

Automated testing has been added for service and management APIs, aligned with documents and following the existing pattern of not being exhaustive when it's shared logic that's being tested.

Manual

1. Create an element type allowed in the element library (invariant), and a culture-variant element type (e.g. en-US + da-DK).
2. Create a new element and choose Save and publish. Confirm (Network tab) a single create-and-publish request is sent — not a save followed by a separate publish — and the element is created and published.
3. Edit the element, change a value, and Save and publish again. Confirm a single {id}/update-and-publish request and that the change is published.
4. For the variant element, select a subset of cultures to publish. Confirm only those cultures are published, while edits to the non-selected cultures are saved but remain unpublished (still shown as pending/edited).
5. Confirm a successful publish shows the "Element published" notification, and that a publish failure surfaces a danger notification (rather than failing silently).

[claude]

Claude finished @iOvergaard's task in 9m 11s —— View job

---

PR Review

Target: origin/main · Based on commit: 5be8624
· Skipped: 4 noise files (sdk.gen.ts, types.gen.ts, backend-api/index.ts, OpenApi.json) out of 31 total

Extends the "save-and-publish as a single operation" capability — introduced for documents in #22812 — to elements by promoting SaveAndPublish to the shared publishable-content base, adding CreateAndPublishAsync/UpdateAndPublishAsync to IElementEditingService, wiring two new Management API controllers, and refactoring the backoffice element publishing workspace context to use the combined operations.

• Modified public API: IPublishableContentService<T> gains SaveAndPublish (with two-step default impl for backward compat); IContentService.SaveAndPublish removed from the direct declaration (now inherited from base); IElementEditingService gains CreateAndPublishAsync and UpdateAndPublishAsync (default: throw new NotImplementedException())
• Affected implementations (outside this PR): External implementors of IElementEditingService — calling the new endpoints without implementing the new methods will throw NotImplementedException at runtime (intentional per Pattern 3; V19 cleanup noted in TODO)
• Other changes: New Management API endpoints POST /element/create-and-publish and PUT /element/{id}/update-and-publish; new element publish-failure notification (speechBubbles_editElementPublishedFailed); element variant selector refactored to extend UmbPublishableSplitViewVariantSelectorElement

---

Suggestions

• src/Umbraco.Core/Services/IElementEditingService.cs:48 (and line 69): The TODO comments use the terse form // TODO (V19): Remove default implementation. — the CLAUDE.md Pattern 3 template reads // TODO (V{next-major}): Remove the default implementation when {obsolete method} is removed. The fuller "when" clause helps reviewers in V19 understand why the default can go. The V19 version is correct (this is a default-impl cleanup, not an [Obsolete] member removal; the V20 rule applies only to [Obsolete] attributes). → Fix this →

• src/Umbraco.Web.UI.Client/src/packages/elements/publishing/workspace-context/element-publishing.workspace-context.ts (~line 372): The old #performSaveAndPublish explicitly called this.#clear() before reload() to prevent a brief false-positive "pending changes" state. The new flow removes that call (the custom performCreateOrUpdate strategy returns freshly-loaded data, so the workspace state is updated atomically). A short comment at the callsite explaining why #clear() is no longer needed would help future maintainers who are familiar with the old pattern.

---

Approved with Suggestions for improvement

Good to go. The architecture is sound — SaveAndPublish correctly lives in the shared base, the new controllers mirror their document counterparts exactly, the frontend wiring handles error paths and notification alignment cleanly, and the tests follow the established integration-test pattern. The suggestions above are minor and don't block merge.

[iOvergaard]

Tested and approved from a frontend perspective. Aligned a few calls with the document-publishing context, which seems to have been implemented as the v18 work was ongoing (validateAndSubmit vs validateVariantsAndSubmit where we now use the latter).

[sonarqubecloud]

Quality Gate passed

Issues
20 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
1.5% Duplication on New Code

See analysis details on SonarQube Cloud