Hallo Florian,
Zu deinen Fragen:
1) Es ist der korrekte Weg, wenn du bestehende Anwendungen aus dem Repository nutzen möchtest. Diese bauen meist ziemlich stark auf die Anwendung "Organisationen" auf. D. h. du legst einen Kontakt (und dessen Organisation) einmal an und andere Anwendungen können dann mit diesen Daten arbeiten um z. B. Urlaub einzutragen oder Aufgaben zuzuweisen. Du kannst auch entscheiden, deine eigenen Anwendungen auf "Organisationen" aufzubauen, wenn die Strukturen darin für deine Zwecke passen. Dann würdest du einen "Organisationskontakt" für jeden Benutzer anlegen und würdest dann in deinen Anwendungen auf die Relation contact in "Organisationen" verweisen.
Falls die Strukturen in "Organisationen" nicht passen sollte, musst du selbst eine Relation für Kontakte/Mitarbeiter/Schüler/usw. (was immer deine Nutzer in deiner App darstellen) anlegen. Auf dieser Relation hast du dann klassisch Vor-/Nachnamen, aber vor allem ein Login-Attribut - das ist dann ein Ganzzahl-Attribut (Integer).
Du brauchst dann nur noch ein Formular, wo du dein Kontakte/Mitarbeiter/Schüler/usw. bearbeiten kannst. Dieses Formular referenzierst du dann als "Login-Formular" im Builder. Wenn du das hast, erscheint im Admin-Panel auch der Link auf dein Login-Formular, um deinen Benutzern jeweils einen Datensatz anzulegen oder einen bestehenden zuzordnen.
Hier ist btw. die Doku hierzu: https://rei3.de/en/docs/builder#login-forms
Ist etwas veraltet, sehe ich grade, aber inhaltlich korrekt.
2) Du darfst jede Anwendung löschen. Es ist nur ein Problem wenn du die Anwendung selbst brauchst, oder eine nutzt, die darauf aufbaut. Im Fall von "Belegschaft" baut glaub ich nur die Anwendungen "Abwesenheit" & "Zeiterfassung" darauf auf (für Zeitinformationen von Mitarbeitern). Aber REI3 zeigt dir das an, wenn du die Löschung versuchst - kriegst dann eine Liste 🙂
3) Grundsätzlich über das Login-Attribut, s. 1) weiter oben. D. h. du hast bspw. die Relation part mit dem Beziehungsattribut created_by (n:1) auf die Relation employee. Auf employee hast du dann (neben Vor-/Nachnamen) auch das Login-Attribut login. Wenn du im Login-Formular deine Benutzer angelegt/zugewiesen hast, beinhaltet dieses Attribut auch immer die richtige Login-ID des aktuell angemeldeten Benutzers. Du kannst dann in Listen darauf filtern, um bspw. part-Datensätze anzuzeigen, die vom aktuellen Benutzer erstellt worden sind (Filter: employee.login = login ID).
Um den aktuellen Ersteller automatisch für einen neuen part-Datensatz zuzuweisen, kannst du in einer Trigger-Funktion den employee mit der Login-ID des aktuell angemeldeten Benutzers raussuchen (instance.get_login_id()) und zuweisen. Du kannst das aber auch im Frontend machen, sodass es als Feldwert vorbelegt ist - das würde dann über eine Sammlung funktionieren (https://rei3.de/en/docs/builder#collections).
Wenn du dabei Unterstützung brauchst, könnten wir einen kurzen Crash-Kurs remote machen. In 30 Minuten hast du alles aufgesetzt 🙂
