ui: a document's footer offers a clear Finish, and workflow tasks leave the editor footer for the Inbox (#7403) - #7404
Closed
NicoleNG18 wants to merge 5 commits into
Conversation
…ve the editor footer for the Inbox (eclipse-dirigible#7403) On a generated document (header-items) entity the editing footer confused a non-developer: line items persist the moment they are added (each row is its own POST/PUT), so the header form is clean and the Save guard `isEdit && !isDirty()` greys Save out - correct, but it reads as "stuck". The footer also mixed workflow (Approve/Issue user-tasks), utilities (Print/Duplicate/...) and the editing session, with two primary buttons (a BPM task and Save) competing for "which one finishes this?". Separate authoring the document from advancing its lifecycle: - Remove the BPM user-task buttons from the record-editor footers (power document and plain form). They are only an inline mirror of the Process Inbox - the same tasks come from /services/inbox/tasks and feed the notification bell - so the Inbox and the bell keep them; nothing is lost. The master-detail read view keeps its inline task surfacing (that is not an editor footer). - Document entities get one honest primary: Create (persist the header, then STAY so line items can be added) on create, and Finish (save any header change, then return to the list) once saved. Finish only navigates on a successful save - a failed validation keeps the user on the page with the error. Never a greyed Save. - Discard/Cancel is shown only while the header has unsaved edits; a clean saved document yields to Finish. Preview (immutable) footer unchanged. - Applied to the power, my and partner document views + pages, and the plain form footer; `finish` added to the shared defaults catalog. Deliberately reverses two earlier choices for these editors: eclipse-dirigible#7359 (Save stayed on the document - Finish navigates away after saving, but the unsaved-changes guard still applies) and eclipse-dirigible#6074 (inline task surfacing - workflow moves to the Inbox). Verified: ModelGenerationIT green (every template renders twice, descriptor + cross-project entity extension asserted); reactor quick-build SUCCESS; formatter:validate SUCCESS on the changed module. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…lipse-dirigible#7403) The first cut hid the Cancel/Discard button once a saved document was clean, on the reasoning that Finish already returns to the list. But that left no explicit exit in the common state (after adding line items) and made Finish conflate "leave" with "done". Restore the always-visible escape hatch that every other view has: Cancel a clean document, Discard unsaved header edits (the label flips on isDirty()), shown next to Create/Finish. Power, my and partner document views. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…s Save (eclipse-dirigible#7403) Finish is the right primary while CREATING a document with line items (add the header, then add items whose greyed Save was the original complaint), but wrong when editing an existing one - there "Finish" reads as completing a creation that already happened. Track whether the session began on the create route (createFlow, kept true after the header save flips mode to 'edit'): the create flow shows Finish, an existing document opened for editing shows the normal Save (updates the header, stays on the page, disabled when nothing changed). Cancel/Discard stays always visible. Power, my and partner document views + pages. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…pse-dirigible#7403) Editing an existing document showed Save, but it saved and stayed on the page (the eclipse-dirigible#7359 behaviour) and greyed out when nothing had changed - so after opening a saved invoice there was no working primary that returned to the list. Point the edit-mode Save at finish() (save any header change, then back to the list; a failed check keeps the user on the page) and stop greying it. Create still stays on the document so line items can be added; Finish (create flow) and Save (editing) now both save-and-return, differing only in label. Power, my and partner document views. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…clipse-dirigible#7403) The power Create button navigates to the /edit route, which re-mounts the page with an id present, so createFlow re-computed to false and Finish never appeared - the add-items phase looked identical to editing an existing document. Carry the signal across the route change with a ?created=1 flag the Create navigation adds and init reads, so the re-mounted /edit page still shows Finish while its line items are added; reopening the document later from the list has no flag and shows Save. The my/partner variants use a silent replaceState and were unaffected. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Cause
On a generated document (header-items) entity the editing footer is confusing to a non-developer:
state === 'saving' || (isEdit && !isDirty())disables Save. Correct, but it reads as "stuck", with no signal that the items are already saved.Approve/Issueuser-tasks), utilities (Print/Duplicate/…) and the editing session, with two primary buttons (a BPM task and Save).The Approve/Issue buttons are only an inline mirror of the Process Inbox —
$store.processTasks.getTasks(form)reads/services/inbox/tasksand also feeds the notification bell — so the tasks already live in the Inbox and the bell independently.Change
Separate authoring the document (editor) from advancing its lifecycle (Inbox):
document-view, plainform-view). Nothing is lost — the Inbox and the bell keep them. The master-detail read view keeps its inline task surfacing (that is not an editor footer, so it is out of scope).finish()only navigates on a successful save — a failed validation keeps the user on the page with the error. Never a greyed Save.finishadded to the shared defaults catalog.Files:
perspective/document/{document-view.html,document-page.js},perspective/manage/form-view.html,my/{my-document-view.html,my-document-page.js},partner/{partner-document-view.html,partner-document-page.js},ui/translations.json— all.template.Deliberately reverses two earlier choices, for these editors only
Deferred (not blocking)
The issue also proposed folding the utilities (
Print/Duplicate/dev actions) into a ⋯ More overflow menu. Removing the Approve blue button already makes Create/Finish the lone primary (the utilities are non-primaryoutlinebuttons), so the reported problem is fully resolved without it. The overflow is a cosmetic de-clutter I left out here because a footer dropdown menu can't be verified without a browser; it can follow as a small enhancement.Verification
ModelGenerationITgreen — Tests run: 1, Failures: 0, Errors: 0 (renders every template twice; descriptor + cross-project entity extension asserted).quick-build install— BUILD SUCCESS.formatter:validateon the changed module (cache wiped) — BUILD SUCCESS.finish()/footer behaviour is straightforward Alpine, but a follow-up UI IT would be worthwhile.Fixes #7403
🤖 Generated with Claude Code