Fehlende Auftrags-/Angebotsüberwachung

[r.czech@…]

Zwei angemeldete User können gleichzeitig einen vorhandenen Vorgang (z.B.
Angebot) schreibend öffnen und bearbeiten. Beim Speichern gewinnt der letzte
speichernde User. Betrifft wahrscheinlich alle Bereiche.

Problem ist bekannt. In das nächste Major-Release wird wahrscheinlich ein
elemantarer Locking-Mechanismus eingebaut. Wenn Ideen für die Umsetzung
vorhanden sind, bitte melden.

Rudimentäre Idee aus einem anderen Projekt:

Beim Laden die mtime auslesen und mitschleifen.
Beim speichern alte mtime mit aktueller vergleichen.
(Soweit offensichtlich)

Bei Konflikt wird es in der Tat haarig. Einzelne textuelle Felder kann man gut
anzeigen und rot hinterlegen wenn ein Konflikt besteht, aber bei Sachen wie
Währung, die globale Auswirkungen haben würde die ganze Maske rot werden, ohne
dass der User wüsste wo der Ansatzpunkt ist.

Weitergehende Konflikte wie Zahlungen in Rechnungen, oder sogar Stornos würden
den Rahmen komplett sprengen, daher votiere ich dafür Konfliktänderungen
komplett abzulehnen.

Ein Lockingmechanismus ist zwar machbar, aber IMO nicht sinnvoll, da bei
Webanwendungen das unlocking nicht zwangsläufig ankommt. onwindowclose u.ä.
werden gerne von Browsern geblockt, weil für Popups misbraucht, und Timeouts
kranken an den berüchtigten Fenster-über-Nacht-Auflassern.

Problem besteht noch (2.7.0-unstable), ist fuer ein zukuenftiges Release geplant

(Vorschlag: Zeitstempel mit Maske hidden ausliefern, Zeitstempel beim Abspeichern gegen das Datum der letzten Aenderung pruefen lassen. Falls Letzte Aenderung neuer als Zeitstempel Warnung ausgeben und User darauf hinweisen, dass er mit "Zurueck"-Button wieder in die Maske mit seinen Aenderungen kommt, die sollte er dann in einem zweiten tab mit dem neuen Stand abgleichen, ggfs manuell mergen wo noetig)

Ich find einen Mechanismus wie bei Contenido nicht schlecht, da kommt dann eine Meldung, der Artikel ist gerade von Bearbeiter xyz in Bearbeitung, wollen Sie diese Warnung ignorieren.

Das sollte organisatorisch schon eine Menge helfen, ist aber zum implementieren noch genügend Aufwand ...

Replying to s.schoeling@…:

Ein Lockingmechanismus ist zwar machbar, aber IMO nicht sinnvoll, da bei
Webanwendungen das unlocking nicht zwangsläufig ankommt. onwindowclose u.ä.
werden gerne von Browsern geblockt, weil für Popups misbraucht, und Timeouts
kranken an den berüchtigten Fenster-über-Nacht-Auflassern.

Dann macht man's genau andersherum und resettet den Timeout solange das Browserfenster offen ist. Heutzutage ist das ja mit AJAJ/AJAX möglich. Vielleicht auch zusammen mit dem Contenido-Ansatz.