Hallo Gabriel.
Ja, den User-Sync habe ich mir selbstverständlich schon angeschaut und auch implementiert. Die alten Login-Formulare waren aus meiner Sicht nämlich tatsächlich etwas erklärungsbedürftig, und stellenweise auch zu unflexibel.
Zusammen mit den neuen Variablen konnte ich mir in einem Formular so auch einen Workaround zusammenbasteln, indem ich die Login-ID in einem versteckten Feld mitführe, und mit Hilfe von Backend-Funktionen eine Konvertierung mit Hilfe von Daten aus anderen Tabellen vornehme. Die Backend-Funktionen werden nach dem Laden des Formulars oder beim Ändern des Wertes in dem Variablen-Feld aufgerufen. Das ist allerdings ziemlich umständlich, und widerspricht ein wenig dem "Low-Code" Gedanken, wenn ich wirklich schnell eine einfache Lösung implementieren will.
Beim Erstellen einer Frontend-Funktion kann ich mit get_user_id() grundsätzlich erstmal nur die ID des Benutzers ermitteln, welche sich aber nicht direkt in Beziehung zu einem Datensatz setzen lässt, den ich über den User-Sync erzeugt habe.
Etwas unglücklich finde ich, dass diese Option quasi "stillschweigend" entfernt wurde. In den Release-Notes habe ich keinen eindeutigen Hinweis in dieser Richtung gefunden. Noch dazu wird die alte Einstellung im Builder nicht mehr angezeigt, so dass ich als App-Entwickler auf den ersten Blick die unterschiedliche Darstellung der Feldinhalte in Apps aus alten Versionen a) nicht nachvollziehen kann, und b) höllisch aufpassen muss, dass ich nicht durch ein versehentliches Auswählen von "Standard" oder "Wertschieber", gefolgt von einem anschließendem Speichern, in einen Zustand komme, in welchem ich das alte Verhalten des Felds nicht wiederherstellen kann.
Da ich die Darstellung der Login-ID in sehr vielen Formularen verwende, sehe ich aktuell also nur die Möglichkeit diese mit sehr viel Aufwand umzubauen.
Bitte nicht falsch verstehen: ich finde, dass ihr mit dem User-Sync, und vor allem auch den neuen Variablen, wieder einen großen Schritt in eine sehr gute Richtung gemacht habt. Den Wegfall von Optionen solltet ihr aber etwas sorgfältiger ankündigen und dokumentieren.
Ideen, welche ich zur "Lösung" des Problems hätte:
a) Kurzfristig die Darstellung als Login wieder aktivieren - wenn das nach euren Erweiterungen und Anpassungen unter der Haube überhaupt so einfach möglich ist.
b) Könnte man die Systembenutzer-Tabelle im Builder nicht in einem Read-Only-Modus zur Verfügung stellen, so dass man aus eigenen Relationen eine 1:n Beziehung auf die Tabelle (User-ID) herstellen, und auf die Attribute des Benutzers zugreifen kann - wie z. B. Vor- / Nach- / Anzeigenamen / Status (aktiv/inaktiv) - zugreifen kann?
Noch ein Hinweis zu den anfangs erwähnten Login-Formularen: diese sind in R3.9 grundsätzlich wegen der Abwärtskompatibilität noch vorhanden. Bei der Umstellung auf den User-Sync habe ich die Beispiel-Funktion verwendet und angepasst. Als ich dann im Benutzer - weil mir zu diesem Zeitpunkt noch nicht klar war, dass auch diese Änderung den User-Sync auslöst - die Zuweisung des zugeordneten Login-Formulars entfernt habe, hat die User-Sync Funktion (example works-as-designed) den Vor- und Nachnamen in meiner Kontaktetabelle mit leeren Feldinhalten überschrieben - weil ja kein Benutzerdatensatz mehr zugeordnet war. Vielleicht sollte man beim Aktivieren des User-Syncs eine Warnung implementieren, dass besser vorher alle Login-Formular-Zuordnung entfernt werden.
