dotCMS / dotCMS/core

UVE Layout: add a persistent save-state indicator (Unsaved / Saving / Saved / Failed + retry)

Open
#37,523 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

dotCMS : UVE OKR : Customer Support Team : Maintenance Type : Defect
Dominant language
Java
Stars
970
Forks
486
Avg merge
3d 33m
Merged PRs (30d)
170

Description

Problem Statement

Split out of #36197, which had two halves:

  1. The data-loss race — the Layout canvas was never locked during a save. Fixed and QA-verified (PRs #37244 + #37480).
  2. The save-state feedback / trust halfthis issue. Not implemented anywhere, and not tracked by any other issue.

On the UVE Layout tab, save state is still communicated only by short-lived toasts ("Saving...", "All changes Saved"), and there is no indication at all during the 5s auto-save debounce window — the interval where the user has unsaved changes. This is the originally reported "they wait and nothing happens" symptom: on a slow or unreliable connection the editor cannot tell whether their layout work has been persisted.

This is a trust/observability problem, not a data-integrity one — the canvas lock now prevents the actual loss.

Current behavior (QA-verified on main @ f95c6bf90b)

  • During the 5s debounce (changes made, not yet sent): a DOM scan of the layout UI for any save-state text returns empty. No signal whatsoever.
  • During the save: transient toast "Saving...", inside p-toast.
  • After success: transient toast "All changes Saved". No timestamp, nothing persistent once it auto-dismisses.
  • On failure (verified by forcing the layout POST to HTTP 500): local edits are correctly preserved and the canvas unlocks, but there is no persistent Failed state and no retry affordance — only a transient error toast.

Acceptance Criteria

Carried over verbatim from #36197, where they were in scope but intentionally not addressed by PR #37480:

  • The Layout tab shows a persistent save-state indicator with distinct states: Unsaved changesSaving…Saved (timestamp)Failed. It does not auto-dismiss while a save is pending.
  • On save failure, the indicator shows a Failed state with a retry affordance, and local edits are not discarded (the user does not lose work and is not misled into thinking the save succeeded).

Note the first criterion covers the debounce window too — "Unsaved changes" should appear as soon as an edit is made, not only once the POST is sent.

Notes

  • Not covered by #36165. That issue adds a feature flag to switch the Layout tab to an explicit manual Save. Even with an explicit Save action, the editor still needs to know the current save state — these are complementary, not duplicates. If #36165 lands first, this indicator should reflect both modes.
  • The lock/spinner from #37244 is a save-in-progress affordance only; it is absent during the debounce window and gone after the save settles, so it does not satisfy these criteria.

Severity

Medium — no data loss (that half is fixed), but editors on slow networks cannot confirm their work persisted.

Split from #36197.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at the UVE Layout tab's existing save flow, including the 5s auto-save debounce and transient toast states, and trace how the layout POST reports success or failure. Done means the tab persistently shows Unsaved changes, Saving, Saved with a timestamp, or Failed with retry, while preserving edits after failure.

Written by the indexing model from the issue text.

Assessment

Domain
frontend
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
50/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.