/
Berechtigungsmodell

Berechtigungsmodell

Owned by Samuel Weber
Last updated: Jul 07, 2023 by atlassian@swarmit.ch (Unlicensed)

Ausgangslage

Für die Vergabe der Berechtigungen im Aussendienst-Portal müssen entsprechende Modelle im VinX eingelesen werden, welche mittels Schema-Migration in die DB integriert werden.

PerformX bietet dazu bereits eine Vorlage. Darauf soll aufgebaut werden. Allerdings ist der Use Case beim PX-Portal anders als beim Aussendienst-Portal. In PX meldet sich ein Kursteilnehmer, Student, etc. an. Also eine Person, die Zugriff auf seinen Adress-Datensatz haben möchte. Im Aussendienst-Portal meldet sich ein Aussendienst-Mitarbeitender an, welcher Zugriff auf seinen Adressstamm haben möchte.

Datenmodell

Erläuterungen

Unterschied Benutzer Portal zu Benutzern in VinX

Die Portal-Benutzer sind ergänzend zu den VinX Benutzern. Im Unterschied zu einem VinX Benutzer, der immer auch ein Mitarbeiter des Unternehmens ist, kann ein Portal Benutzer auch eine Adresse sein oder an eine andere Entität angebunden sein. Performa hat dazu eine Funktion entwickeln lassen, womit aufgrund frei definierbarer Kriterien in einer Hintergrundverarbeitung die Benutzer angelegt werden. Passwörter werden dabei nicht vergeben, sondern diese vergibt der Benutzer nach seiner ersten Anmeldung.

Rolle

Dem Benutzer wird mindestens eine Rolle zugewiesen. Im Falle der Aussendienst-Lösung ist dies ein Mitarbeiter. Auf der Mitarbeiter haben wir eine Vertreter-ID hinterlegt, die auf die Vertreter-Tabelle verweist. Über diese Vertreter-ID lassen sich die globalen Einschränken nutzen, so dass ein Aussendienst-Mitarbeiter nur seine Kunden und Belege sieht.


FragenAntworten

Braucht es folgende Tabellen auch:

  • Translation
  • Layout
  • Client Configuration
Die Layouts werden für die Konfiguration der Views benötigt. Das ist ein Kernstück damit die Supporter danach auch entsprechend Views pro Kunde erweitern/ändern können.
Die Client Configuration läuft in eine ähnliche Richtung. Darin finden sich diverse Einstellungen für den Client/Server Bereich. Dokumentiert sind die Sachen hier:
https://encodo.atlassian.net/wiki/spaces/EB/pages/150601729/Konfigurationsschl+ssel

Bei PX werden Portal-Logins für Adressen erstellt. Im VinX sind für das Aussendienst-Portal folgende Quellen möglich:

  • Datenbank-Benutzer
  • Entität Mitarbeiter
  • Entität Vertreter

Vorschlag samw ist, dass wir es über die Entität Mitarbeiter lösen. Auf einem Mitarbeiter-Datensatz wird auch auf den Datenbank-Benutzer verwiesen. Denkbar ist auch, dass man eine Relation zwischen Mitarbeiter- und Vertreter-Tabelle erstellt.

Allerdings ist in einem späteren Ansatz auch angedacht, dass sich Kunden des Wein- oder Getränkelieferanten im Web anmelden können. In diesem Fall müssten wir auch die Möglichkeit via Adresse à la PerformX haben.

Beissen sich diese Ansätze?

Das Mapping konnten wir theoretisch über die Rollenzuweisung machen. Auf dieser kann ein Objekt als "Context" angegeben werden. Dieses Objekt kann danach auch in Expressions zur Einschränkung der sichtbaren Entitäten verwendet werden (Object-Level-Security). So wie ich das lese/verstehe sollte das kein Problem sein mit dem aktuellen Setup. Die Frage stellt sich evt. ob wir aus der MA-Tabelle noch automatisch entsprechende Benutzer generieren wollen.




****

Da verbauen wir uns nichts. Ein Benutzer kann theoretisch beliebig viele Rollen einnehmen und entsprechend abweichende Berechtigungen/Context-Mappings haben.

Performa hat Quino-Attribute "PortalMutationDatum" und "PortalMutationUserID" auf der Entität Pendenz. Ich nehme an, da im Portal Pendenzen erstellt und bearbeitet werden können. Ist das Prozess da verlgeichbar mit den Kontakteinträgen in VinX? Müssten wir diese Felder also auch noch auf die Kontakteinträge nehmen?Das können wir machen wenn gewünscht. Bei Performa kommen die Mutationen halt teilweise aus sehr unterschiedlichen Ecken (Teilnehmer, Dozenten etc.). Fall gewünscht ist das aber keine grosse Sache. Wir haben ein Standard-Change-Tracking das aktuell gewisse Properties einschliesst und direkt ausfüllt - am sinnvollsten wäre es wohl auf diesem Standard-Schema aufzubauen um danach entsprechend beliebige Klassen damit erweitern zu können.

Performa hat auf diversen bestehenden Enitäten das Boolean "PortalVisibility" hinzugefügt. Müssen wir das in VinX auch für alle Entitäten machen, die in der Aussendienstlösung ausgegeben werden?

Die PortalVisibility ist aktuell vor allem relevant da es teilweise öffentliche Bereiche gibt (Event-Module) auf welchen nicht alles sichtbar sein soll. Teilweise werden damit auch zusätzliche Restriktionen gemappt damit z.B. neu erfasste Events nicht sofort für alle mit Berechtigung sichtbar sind.