yakamara
Idee: Zusammenarbeit an YForm Tables optimieren | konkurrierende Zugriffe vermeiden
Wir haben zunehemnd Projekte in der Mache, wo eine gewisse Zahl an Backend-Nutzern in diversen YForm Tables arbeitet. Kontext ist CRM aber auch andere Verwaltungs-Kontexte.
Es kommt dabei vor, dass 2 (oder mehr) Nutzer, die sich nicht anderweitig absprechen, denselben Datensatz öffnen. Dann gewinnt, wer zuletzt speichert.
Einfacher / schneller Lösungs-Ansatz:
Beim Laden eines Datendatzen (edit-Modus) wird ein Hash der aktuellen Daten erzeugt. Beim Speichern wird das wiederholt und der Datensatz nur dann gespeichert, wenn der Hash übereinstimmt. Andernfalls erscheint eine Fehlermeldung.
Weiterführend könnte man in der Fehlermeldung noch ein (ausklappbares) Diff anzeigen - sodass man die zwischenzeitlichen Änderungen sieht. Es sollte am Ende 2 Buttons geben "Trotzdem speichern", "Verwerfen". Im Idealfall sogar einen 3.: "Zusammenführen und speichern". Wer die Standard-Abschlussfelder updatedate und updateuser einsetzt, hat dann auch gleich die Info, wer da dazwischen gefunkt hat (das kann der Tabellen-Einrichter aber selbst übernehmen).
Sollte man dann drüberspeichern wollen und es ghätte wieder einer dazwischen gefunkt, würde sich der Spaß wiederholen.
Komplexer Weg (evtl. für gesamtes REDAXO Backend nützlich):
Man schafft via Websocket und DB ein Live-Monitoring. Wer in der Table-Übersicht unterwegs ist, bekommt rötlich eingefärbte Zeilen mit Fähnchen dran, wo man sieht welcher andere Backend-Nutzer aktuell einen spezifischen Datensatz bearbeitet. Dort werden dann on-the-fly auch die Buttons entzogen sodass der 2. Nutzer (der gern bearbeiten würde aber nicht darf, weil ein anderer schneller war) das Nachsehen hat. Verlässt Nutzer 1 wieder den Datensatz (speichern, onClose, ...) werden die Buttons wider freigschalten.
Hat Nutzer 2 den Link zum Datendatz bspw. in der History oder anderswo her und ruft den direkt auf, während der Datensatz eig. durch Nutzer 1 schon bearbeitet wird, komt ein Overlay ins Spiel oder das Form wird ausgeblendet und eine Warnung ausgegeben, dass Nutzer 1 seit x Minuten schon dran arbeitet oder.
Generell wäre die ngabe des bearbeitenden Nutzers und der Dauer sinnvoll aus diversen Gründen.
Die Einhorn-Lösung:
Dieser Mechanismus wird global gefasst - an rex_list allgemein oder noch besser das REDAXO Backend allgemein. Der Websocket kann also mit verschiedenen Kontexte bestückt werden. Die einzelnen AddOns könnten aus dem Websocket Daten für widerum eigene "collaboration"-Plugins ziehen (YForm, Structure, Sked, Medienpool ...) und dort für das jeweilige Segment passende Handling implementieren.
IM Header (oder in der Footer-Bar, die aktuell ein eigentsändiges AddOn ist glaube ich) könnte man sehen, welche Nutzer eingeloggt sind, wie lange, wo sie gerade überall unterwegs sind. Alles jeweils mit eigenen Rechten versehen. Man will ja unter den MAs keine Stasis-Athmosphäre aufbauen.
Alle genannten Ansätze könnte man als "collaboration"-Plugins implementieren, da das sicherlich nicht jeder in jedem AddOn braucht. Mit persönlich liegt bei dem ganzen der Fokus auf YForm, weshalb hier das Ticket entsteht. Ich sehe aber auch bei der Strukturverwaltung einen gewissen Bedarf, wenn eine größere Installation mit mehreren Redakteuren betrieben werden soll.
Auch wenn noch keine gute Antwort gekommen ist, habe ich es gelesen und sehe natürlich auch das Problem. Mehr Info kommt noch.
@bitshiftersgmbh hast du sowas inzwischen gebaut? Ich könnte mir gut vorstellen, ein eigenes Value mit diesem Verhalten umzusetzen, das dann per AJAX bspw. alle 5 Sekunden nachfrägt, was der Stand der Dinge in dem Datensatz ist und ob dieser geöffnet wurde.
Es gibt ja mit 4.0 auch eine readonly-Ansicht der Datensätze.
Ja, tatsächlich arbeite ich genau daran derzeit für ein Kundenprojekt. Es wird Lösung 2 mit WebSocket. Das Ganze wird als AddOn entwickelt und soll später ein FOR Realease werden.
Das AddOn liefern eine grundsätzliche Kommunikationsschnittstelle, Plugins für YForm , Sked und Structure sollen das Zusammenarbeiten für die entsprechenden Bereiche regeln. Dazu können die Plugins in die Kommunikation rein-hooken, serverseitig und clientseitig. Für YForm sollte Ende der Woche ein erster Prototyp stehen.
Die Schwierigkeit bei dem Weg ist die Websocket Schnittstelle (mit SSL) auf Produktivsystemen. Man muss dazu an Host Configs ran und man muss das Serverskript auch serverseitig starten. Das sind leider 2 Barrieren die einen etwas üblen Beigeschmack erzeugen.
Mehr dazu später, evtl. n Video im Slack Ende der Woche ...
Verrückt, dass wir hier vor 1,5 Jahren schon mal drüber geschnackt hatten. Völlig aus meinem Gedächtnis gelöscht. 🤣
@bitshiftersgmbh wolltest du nicht ein Addon bauen?
Wärste mal zum REX Day gekommen, dann wüsstest du das jetzt. 😉😘 Ja, ich bin gerade dran. Wird jetzt auch doch noch ne etwas größere Nummer, wird aber die Tage schon einen ersten Release geben. @dergel und einige andere sind involviert.
Willst du dem Teil icht vielleicht schon einen Namen geben, und den bei friendsofredaxo eintüten? Das Issue schliesse ich hier einfach mal - weil ich auf dich baue :D