You can work with confidence using a locked cluster that multiple users have open at the same time. The results view updates the saved tree and part data after changes are made, ensuring that no user continues working with outdated information.
For this procedure, you need two independent, logged-in sessions with clustering-view and clustering-edit. Use a completed clustering with one filled and one empty sheet cluster, which can be removed. The changes affect saved data; for testing or training purposes, use data that can be lost.
An independent session is a separately logged-in browser profile or a distinct browser context. Two tabs within the same browser session are not considered independent users.
Simultaneous Editing—Controls, Meaning, and Decisions During Operation
Keep the same completed clustering open in both editor sessions when you are reconciling a change. A change to the part status is saved via the respective editor’s request; afterward, the tree, selected parts, and metrics are reloaded. If the server accepts competing changes one after another, both sessions will display the most recently saved status after their next refresh.
The server may reject a change because the underlying data has changed. In that case, the results view restores the current server state before displaying the action error. The parts cards, tree, “Overview,” and graph will then reflect the same saved revision instead of showing outdated totals.
Changes to the tree follow the same principle. Removing an empty cluster updates the hierarchy and the current result data. A session in which the removed node was still selected must reload before continuing; the application remains operable within an existing tree context, rather than treating the removed node as valid .
The workspace reads the hierarchy and the current cluster data as a single, coherent result revision. If the responses temporarily point to different revisions because another user is modifying the clustering, the application repeats the joint load several times. A newer request replaces an older pending one so that no outdated response overwrites a newer selection.
If no consistent result can be loaded, the page displays an error message regarding consistency along with the “Reload” button. “Reload” requests the currently selected context again. Transmission errors also appear at this point; they are not automatically retried like differing revisions.
If there is an outdated revision of a preview image, the hierarchy graph requests the same update to the result. Read the graph only after the tree and result data have been updated.
After a successful update, both users work with the saved clustering status. A rejected, replaced, or outdated task does not result in an incorrect view: The workspace displays the error if necessary and offers an option to reload; the tree, result cards, “Overview,” and graph revert to a consistent, up-to-date state.
Do not include login credentials in documentation, source files, logs, or support requests.
If a concurrent process behaves unexpectedly, make a note of the affected clustering, the last two states observed, and the error message displayed.
This process was verified based on the source code and is described only as text . It was not tested by running it through a browser and intentionally does not include any screenshots.