Benutzerverwaltung
Die D-QUANTUM Administration beinhaltet eine einfache Funktion zur Anlage von Benutzern und Rollen. Hier werden Rollen mit entsprechenden Privilegien versehen, die global oder entitätstyp-spezifisch definiert sein können.
Nutzer können direkt angelegt oder über die bestehenden externen Systeme angeliefert werden. Neu ist die Möglichkeit der Selbstregistrierung, mit welcher Anwender sich im Rahmen einer definierten Rolle die Daten in D-QUANTUM ansehen können.
Die Definition von Rollen und Zuordnung globaler oder entitätstyp-spezifischer Privilegien erfolgt über eine intuitives User Interface.
Rollen werden durch die Zuweisung von Privilegien mit dem entsprechenden Berechtigungsumfang ausgestattet und User mit ein oder mehrere Rollen verknüpft. Dies alles passiert zentral in der Administration.
Wie wird mein Berechtigungskonzept von Confluence Gruppen in die neuen Privilegien übersetzt?
Da die Privilegien nicht 1:1 den früheren Confluence Gruppen entsprechen, muss das Mapping während der Migration manuell angepasst werden. Die Privilegien sind nun logisch nach Komponenten gruppiert und Abhängigkeiten werden transparent gemacht.
Das Employee Role Mapping in den Globalen Einstellungen entfällt, da die Rollen-Definition in der D-QUANTUM Administration stattfindet.
Was ist zu beachten, wenn man bisher Employee Role Mapping oder das User Role Mapping genutzt hat?
Das Mapping von Privilegien zu Rollen findet nun nicht mehr in den Globalen Einstellungen statt. Diese werden im Rahmen der Migration entfernt und die Rollen in der Administrationsoberfläche definiert.
Gibt es keinen anonymen User-Zugriff mehr?
Nein, jeder, der den vorliegenden Datenbestand sehen und nutzen möchte, muss sich namentlich mit einer E-Mail-Adresse registrieren. Dies geht einfach und unkompliziert über eine Selbstregistrierung, sofern diese Funktion über die Globalen Einstellungen aktiviert ist:
GlobalConfig | Register | true (möglich, wenn keine LDAP und SSO Registrierung eingesetzt wird).
Was ein selbstregistrierter User sehen oder editieren darf, wird in einer Standardrolle definiert. Welche Rolle bei der Selbstregistrierung vergeben wird, wird in den globalen Einstellungen unter GlobalConfig | RegisterRole | {rolename} festgelegt.
Anpassungen im Bereich der Freigabeprozesse
Die neue Benutzerverwaltung hat auch zu Anpassungen im Bereich der Freigabeprozesse geführt.
So gibt es keine ‘Default’-Gruppe mehr. Alle Freigabeaktionen sind in entitätstyp-bezogenen Globalen Einstellungen definiert. Die Syntax der Global Settings wurde etwas vereinfacht.
Mit einem neuen Global Setting kann gesteuert werden, ob nur User mit dem entitätstyp-spezifischen Privileg die Workflow-Aktion durchführen dürfen oder alle User, welche entweder die entitätstyp-spezifische oder globale Berechtigung für die entsprechende Aktion haben.
Müssen die Globalen Einstellungen zum Workflow angepasst werden?
Bei der Migration Ihrer V4 auf Version 5 wird die neue Syntax in Bezug auf die Workflow-Gruppe angepasst. Die SynExpl zu einem Workflow-Setting muss überprüft werden, da die Funktion §getMembersOf durch die Funktionen §getPrivilegeUsers bzw. §getRoleUsers ersetzt wurde. Die Anpassung erfolgt im Rahmen der Migration.
Wie steuere ich, dass man für bestimmte Workflow-Aktionen explizit das entitätstyp-spezifische Privileg benötigt?
Gruppe: <ET Name>
Name: Workflow::explicit
Wert: true/false
Der Wert “true” bedeutet, dass nur User mit dem entitätstyp-spezifischen Privileg die Workflow-Aktion durchführen dürfen. Im Gegensatz dazu, dürfen bei “false” alle User, welche entweder die entitätstyp-spezifische oder globale Berechtigung für die entsprechende Aktion haben, den jeweiligen Schritt durchführen.