PROBLEM

In rare but frequeent situations segments are not saved by the frontend:

• the segment was edited (target) and saved, the editor closed and the segment markup was changed in the grid
• the "red triangle" marking the "dirty"-state was not visible
• when the saving was finished the segment was reset to the original / pre-editing state in the grid

Also, the save-chain has know deficiencies:

• the saveChainEnd function is usually called twice, leading to two "segmentEditSaved" Events, one BEFORE the callback of the segment record save and one after. This already leads to quirks e.g. in the visual WYSIWYG feature - what depends on those events
• the reason for above certainly lies in the onAfterSaveCall of the ChangeAlike controller (there are FIXMEs already). Working with callbacks here is the wrong approach anyway as this will not solve async problems / race-conditions ...

SOLUTION

The scope of this issue includes two major TODOs:

a) specify the actions the chain should cover, define the sequence of actions and events: what can be async / in parallel and what needs to be synced. This should happen in the grooming phase

b) implement a new save chain (with "modern" tecniques like promises etc.) that  really follows this specification

SPECIFICATION OF THE SAVE CHAIN

Conceptual Model For Redesign

Treat the save chain as a segment-editor lifecycle coordinator, not just a save button handler.

It currently has three responsibilities mixed together:

1. Editor close/finalize: pull rich editor content into the record, validate, stop time tracking.
2. Persistence: dirty check, state changes, REST save, backend response handling.
3. Post-save orchestration: ChangeAlike, progress updates, quality/term/visual/spellcheck refreshes, navigation continuation.

The important compatibility point is that callers need two different completion signals:

• “the old segment data is no longer needed; navigation may continue” currently segmentUsageFinished
• “all save-chain work is finished” currently segmentEditSaved

Those two meanings should probably remain separate. ChangeAlike especially depends on that distinction.

Current core flow

The save chain lives in public/modules/editor/js/app/controller/Segments.js:627. Editor.controller.Segments listens to Editor’s saveSegment event and routes it to saveChainStart.

Sequence:

1. saveChainStart(config)
   Captures the active row editor, edited field, record, snapshots the pre-save value, calls ed.completeEdit(), and optionally registers one-time callbacks for segmentEditSaved / segmentUsageFinished.
2. RowEditorNew.completeEdit()
   Saves rich editor content into the record via saveMainEditorContent(), validates length/tag/content errors, updates autoStateId, and writes editing durations. See public/modules/editor/js/app/view/segments/new/RowEditorNew.js:91 and public/modules/editor/js/app/view/segments/new/RowEditorNew.js:734.
3. saveChainCheckAlikes(record)
   Waits for an in-flight ChangeAlike load operation if needed. The load of the changealikes is triggered on segment open. Shows the ChangeAlike dialog if needed.
4. saveChainSave(record)
   If the record is dirty, sets draft/pending state, calls record.save() against the segment REST proxy, updates sibling meta cache, then fires afterSaveCall.
5. saveChainSaveCallback(record, operation, success)
   Handles server errors, backend-modified-field diagnostics, progress updates, fires beforeSaveCall, then fires saveComplete.
6. saveChainEnd(record, extraParams)
   Removes loading masks, clears mutex, fires segmentUsageFinished, resets wasOriginalTargetUpdated, then fires segmentEditSaved.

Major Participants

• ChangeAlike hooks into afterSaveCall and saveComplete, may pause chain completion, open the repetition dialog, save alike segments, then call back into saveChainEnd. See public/modules/editor/js/app/controller/ChangeAlike.js:259 and public/modules/editor/js/app/controller/ChangeAlike.js:402.
• Search/replace can call Editor.save() / saveDraft() after replacements. See public/modules/editor/js/app/controller/SearchReplace.js:405 and public/modules/editor/js/app/controller/SearchReplace.js:1641.
• SpellCheck replacement opens a segment, changes editor content, then calls Editor.save(). See application/modules/editor/Plugins/SpellCheck/public/js/controller/SpellChecker.js:351.
• TrackChanges “accept/reject and next” uses saveCurrentAndOpenNext(), which leads into saveOtherRow(). See public/modules/editor/js/app/controller/Editor.js:1106 and application/modules/editor/PrivatePlugins/TrackChanges/public/js/controller/Editor.js:1098.

Consumers Of Save Events

Several UI areas refresh from save-chain events:

• Quality rendering base listens to segmentEditSaved → does applyQualityStylesForRecord
• Quality filter panel listens to segmentEditSaved and beforeSaveCall. → does refreshQualitiesPanel
• TermTagger listens to beforeSaveCall. → re-loads the termpanel for the segment (why before save? Should be imho after save)
• VisualReview segment mapping listens to beforeSaveCall. → updates mapping store and does updateSegmentInIframe
• SpellCheck listens to segmentEditSaved. → process and reset pendingDataForSave
• OpenAI quality estimate listens to segmentEditSaved. → triggers qualityScoreEstimate for the segment