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
| Fragen | Antworten |
|---|---|
Braucht es folgende Tabellen auch:
| 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:
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. |