Restore staged HDR add/replace/remove in the existing post editor #1

New issue

Open

opened 2026-10-24 22:57:22 +00:00 by Michael Westergaard · 0 comments

Michael Westergaard commented

2026-10-24 22:57:22 +00:00

Owner

Restore add/replace/remove HDR controls for images already attached to a post. Deferred feature on michael; do not include in the current rollout fixes.

Canonical shared contract and backend dependency: klafbang/VernissageServer#1 (section "Shared contract: atomic HDR edits v1"). This issue depends on the backend capability and staging/save guarantees there; it does not authorize unsafe direct attached HDR writes.

Implementation plan:

Gate on enabled supported 1.x plus atomicAttachmentEdits === true and new atomicHdrEdits === true. Missing/false retains today's explanation and disabled attached controls. Preserve existing unattached HDR behavior.
Stage AVIF via POST /api/v1/post-access/statuses/{statusId}/attachments/{attachmentId}/hdr-stages, multipart file, account/XSRF and a retained UUID-v4 upload key. Match the contract's strict file-size boundary. Keep binary/draft references until Save outcome is known; use local blob URLs for preview and release them appropriately. Cancelled file selection changes nothing; failed replacement preserves the previously selected/saved HDR and offers retry.
Add separate StatusRequest.attachmentHdrEdits?: {id:string; stageId:string|null}[]. Omit unchanged entries; null explicitly removes HDR. Never add binary fields to full metadata snapshots. Removing HDR is a local draft action until Save. Wait for staging to finish before saving; retain the same upload key/file on uncertain upload outcomes.
Track base, draft stage/removal intent and latest HDR separately. Dirty-state detection, Cancel/navigation cleanup and reconciliation must include HDR. On 412/428 preserve staged choices and let the user explicitly choose draft/latest with attachment membership/order/metadata; do not auto-apply them. If the attachment is removed, do not submit its HDR edit. Abandoned unconsumed stages can be cancelled best-effort; backend expiry remains authoritative.
Save through existing PUT with original revision/key/full body. Retain exact unchanged retry state after lost responses and committed 503 media errors. If the user edits after an uncertain outcome, reconcile before changing keys/body or cancelling stages that may have committed. Do not treat stageAlreadyCommitted as permission to create another write. Display committed origin-cleanup pending state through the existing controls.
When an unconsumed stage expires, offer explicit re-upload of the retained file using a fresh upload key, preserving the rest of the draft; if file bytes are no longer available, request reselection. Do not silently restage during retries whose Save may already have committed. Use successful replay before interpreting consumed/expired-stage errors. For cancelled/expired/wrong-target stages handle the canonical errors without dropping unrelated draft edits.
Accept the committed StatusDto/ETag and display its originalHdrFile through existing per-file authorization, protected blob loading and ordinary-image fallback. Keep private media/API JSON outside SSR/HTTP-transfer/service-worker caches. Never call the legacy direct attached HDR POST/DELETE endpoints.

Verification:

Unit/browser tests for add/replace/remove, no-op/preserve, cancelling replacement, stage failures, size/type boundaries, upload-key retry and stage expiry.
Combined HDR/metadata/visibility/order saves, repeated conflicts, explicit draft/latest reconciliation and attachment removal.
Lost upload/save response, unchanged replay after stage consumption/expiry, committed 503 recovery and safe cancellation after ambiguous outcomes.
Real API/disposable-storage integration with SERVICE WORKERS ENABLED: private staged previews, protected/public saved HDR, authorized history after replacement/removal, no cached private data, origin revocation/recovery and ordinary fallback.
Record both source versions; coordinate with the backend issue when implemented. Update shared contract copies consistently. No implementation is requested now.

Restore add/replace/remove HDR controls for images already attached to a post. Deferred feature on `michael`; do not include in the current rollout fixes. Canonical shared contract and backend dependency: https://git.westergaard.cloud/klafbang/VernissageServer/issues/1 (section "Shared contract: atomic HDR edits v1"). This issue depends on the backend capability and staging/save guarantees there; it does not authorize unsafe direct attached HDR writes. Implementation plan: 1. Gate on enabled supported 1.x plus `atomicAttachmentEdits === true` and new `atomicHdrEdits === true`. Missing/false retains today's explanation and disabled attached controls. Preserve existing unattached HDR behavior. 2. Stage AVIF via `POST /api/v1/post-access/statuses/{statusId}/attachments/{attachmentId}/hdr-stages`, multipart `file`, account/XSRF and a retained UUID-v4 upload key. Match the contract's strict file-size boundary. Keep binary/draft references until Save outcome is known; use local blob URLs for preview and release them appropriately. Cancelled file selection changes nothing; failed replacement preserves the previously selected/saved HDR and offers retry. 3. Add separate `StatusRequest.attachmentHdrEdits?: {id:string; stageId:string|null}[]`. Omit unchanged entries; null explicitly removes HDR. Never add binary fields to full metadata snapshots. Removing HDR is a local draft action until Save. Wait for staging to finish before saving; retain the same upload key/file on uncertain upload outcomes. 4. Track base, draft stage/removal intent and latest HDR separately. Dirty-state detection, Cancel/navigation cleanup and reconciliation must include HDR. On 412/428 preserve staged choices and let the user explicitly choose draft/latest with attachment membership/order/metadata; do not auto-apply them. If the attachment is removed, do not submit its HDR edit. Abandoned unconsumed stages can be cancelled best-effort; backend expiry remains authoritative. 5. Save through existing PUT with original revision/key/full body. Retain exact unchanged retry state after lost responses and committed 503 media errors. If the user edits after an uncertain outcome, reconcile before changing keys/body or cancelling stages that may have committed. Do not treat stageAlreadyCommitted as permission to create another write. Display committed origin-cleanup pending state through the existing controls. 6. When an unconsumed stage expires, offer explicit re-upload of the retained file using a fresh upload key, preserving the rest of the draft; if file bytes are no longer available, request reselection. Do not silently restage during retries whose Save may already have committed. Use successful replay before interpreting consumed/expired-stage errors. For cancelled/expired/wrong-target stages handle the canonical errors without dropping unrelated draft edits. 7. Accept the committed StatusDto/ETag and display its originalHdrFile through existing per-file authorization, protected blob loading and ordinary-image fallback. Keep private media/API JSON outside SSR/HTTP-transfer/service-worker caches. Never call the legacy direct attached HDR POST/DELETE endpoints. Verification: - Unit/browser tests for add/replace/remove, no-op/preserve, cancelling replacement, stage failures, size/type boundaries, upload-key retry and stage expiry. - Combined HDR/metadata/visibility/order saves, repeated conflicts, explicit draft/latest reconciliation and attachment removal. - Lost upload/save response, unchanged replay after stage consumption/expiry, committed 503 recovery and safe cancellation after ambiguous outcomes. - Real API/disposable-storage integration with SERVICE WORKERS ENABLED: private staged previews, protected/public saved HDR, authorized history after replacement/removal, no cached private data, origin revocation/recovery and ordinary fallback. - Record both source versions; coordinate with the backend issue when implemented. Update shared contract copies consistently. No implementation is requested now.

Michael Westergaard referenced this issue from klafbang/VernissageServer

2026-10-24 22:57:22 +00:00

Restore HDR editing on existing posts with private staging and atomic saves #1

No labels

No milestone

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

klafbang/VernissageWeb#1

No description provided.

Rows
Columns