Prozedur zum Anlegen, Bearbeiten und Löschen von Zugriffsbeschränkungen auf Personen-Merkmale für (Datenbank-)Benutzergruppen.

Zum Verständnis - die Logik einer Zugriffsbeschränkung eines Benutzers für ein Merkmal ist diese :

1.) Eine direkt zu einem Benutzer („UserID“) gespeicherte Konfiguration hat Vorrang vor anderen Einstellungen zum selben Merkmal (z.B. zu einer Gruppe, der der Benutzer angehört).
Besonderheit : Es kann auch explizit „AccessRestriction = 0“ konfiguriert sein, was „keine Beschränkung“ bedeutet - sinnvoll wenn für einen Benutzer eine AUSNAHME (weil z.B. „global“, siehe Punkt 3, eine Beschränkung konfiguriert ist) gelten soll.

2.) Falls für ein Merkmal zu einem Benutzer („UserID“) nichts konfiguriert ist, gelten die evtl. vorhandenen Konfigurationen zu Gruppen („UserGroupID“s), denen der Benutzer zugeordnet ist. Da ja eine Zuordnung zu MEHREREN Gruppen vorhanden sein kann und somit für ein Merkmal MEHRERE Konfigurationen in Frage kommen können, wird nach folgender Regel verfahren :
PRO Merkmal gelten die Zugriffsbeschränkungen der Gruppe, denen der Benutzer mit der kleinsten „SortNo“ (bedeutet „höchste Priorität“) zugeordnet ist.
Besonderheit auch hier (wie schon bei Punkt 1) : Es kann „AccessRestriction = 0“ konfiguriert sein, was „keine Beschränkung“ bedeutet.

3.) Nur wenn weder zum Benutzer („UserID“) noch zu einer der Gruppen („UserGroupID“s), denen der Benutzer zugeordnet ist, eine Konfiguration zu einem Merkmal heranzuziehen ist, greift eine evtl. zur speziellen „UserID = -1“ (also „global“) gespeicherte Einstellung.
Wie schon bei den ersten beiden Punkten kann eine „AccessRestriction = 0“-Einstellung herauskommen, was „keine Beschränkung“ bedeutet (weil man z.B. „global keine Beschränkung, aber Einschränkungen für bestimmte Benutzer“ realisieren möchte).

Anmerkungen zu den Rückgabespalten „AccessRestriction“ und „ReadAccessRestrictionPattern“ :

1. „AccessRestriction“ gibt an, welche Beschränkungen (für den Benutzer „RestrictionForUserGroupID“) gelten. Der Wert ist als „bitmap“ zu verstehen, sprich es handelt sich um eine Summe aus folgenden möglichen Werten :

• „1“ : Neu-Anlage von Eigenschaften/Details zum Merkmal verboten
• „2“ : Ändern von Eigenschaften/Details zum Merkmal verboten
• „4“ : Löschen von Eigenschaften/Details zum Merkmal verboten
• „8“ : Zum einen ist das Lesen von Eigenschaften zum Merkmal komplett verboten oder eingeschränkt (je nach „ReadAccessRestrictionPattern“) und zum anderen ist das Lesen von Details komplett verboten. „Komplett verboten“ (im Gegensatz zu „Lesen eingeschränkt gemäß ReadAccessRestrictionPattern“) bedeutet, daß Datensätze zum Merkmal GANZ fehlen.

2. Es kann auch der Wert „0“ für „AccessRestriction“ vorkommen, was „KEINE Zugriffsbeschränkung“ bedeutet - sinnvoll wenn eine AUSNAHME gelten soll (weil z.B. „global“ eine Beschränkung definiert ist).

3. Die Spalte „ReadAccessRestrictionPattern“ ist IMMER „NULL“ wenn KEIN Lese-Verbot bzw. KEINE Lese-Beschränkung existiert (wenn also „AccessRestriction & 8 = 0“ ist, sprich der Summand „8“ NICHT in der „AccessRestriction“-Summe vorkommt) ! Andernfalls KANN hier ein „pattern“ stehen, das angibt, welcher Teil von Eigenschaften zurückgegeben wird, also die Art der Beschränkung definiert. „NULL“ bedeutet bei gegebenem Lese-Verbot, daß Datensätze zur Eigenschaft komplett fehlen - für Details gilt dies im Falle eines Leseverbots („AccessRestriction & 8 = 8“) IMMER, sprich „ReadAccessRestrictionPattern“ hat KEINE Bedeutung für Details ! Derzeit sind folgend „pattern“ möglich :

• „#left(<n>)#“ : nur die ERSTEN n Zeichen der Eigenschaft zum Merkmal werden ausgegeben
• „#right(<n>)#“ : nur die LETZTEN n Zeichen der Eigenschaft zum Merkmal werden ausgegeben

Hinweis : n = 0 ist möglich, was dazu führt, daß anstelle der Eigenschaft „NULL“ ausgegeben wird (egal ob die „ERSTEN 0 Zeichen“ oder die „LETZTEN 0 Zeichen“ definiert ist). Im Gegensatz zum kompletten Lese-Verbot (wenn also „NULL“ im „ReadAccessRestrictionPattern“ steht) kann der Aufrufer so wenigstens erkennen, ob die betreffende Person eine Eigenschaft hat oder nicht (beim kompletten Lese-Verbot fehlt der Datensatz ja gänzlich) !

Beispiele zu den Rückgabespalten „AccessRestriction“ und „ReadAccessRestrictionPattern“ :

1. Kann eine Benutzergruppe zu einem Merkmal keine neuen Eigenschaften/Details anlegen und keine bestehenden Eigenschaften bzw. Details löschen (besitzt aber uneingeschränkten lesenden Zugriff und kann bereits bestehende Eigenschaften bzw. Details zum Merkmal ändern), enthält die Spalte „AccessRestriction“ den Wert „5“, sprich die Summe der Werte „1“ (Neu-Anlage verboten) und „4“ (Löschen verboten). Die Spalte „ReadAccessRestrictionPattern“ ist bedeutungslos, daher also „NULL“.

2. Sollen Benutzer einer Gruppe eine Eigenschaft zu einem Merkmal zwar anlegen bzw. ändern dürfen, und möchte man ihnen auf der anderen Seite verbieten, Eigenschaften dazu einsehen oder löschen zu können, enthält die Spalte „AccessRestriction“ den Wert „12“, was der Summe aus „4“ (Löschen verboten) und „8“ (Lesen verboten oder eingeschränkt) entspricht. Da der lesende Zugriff aber nicht unbedingt KOMPLETT verboten sein soll (die Benutzer der Gruppe also durchaus sehen können sollen, ob eine Eigenschaft vorhanden ist oder nicht) ist, steht in der Spalte „ReadAccessRestrictionPattern“ z.B. „#left(0)#“.
Anmerkung : Realistischer Anwendungsfall für so ein Szenario ist z.B. ein „Passwort-Merkmal“, das für Benutzer z.B. einer Gruppe „Support“ zum einen „verborgen“ sein soll (aber durchaus erkennbar sein soll, ob überhaupt eine Passwort-Eigenschaft vorhanden ist oder nicht), sie aber andererseits ein neues Passwort vergeben können sollen.

(parameterunabängige Sortierung)

• RestrictionForUserGroupID (aufsteigend)
• PersonCharacteristicID (aufsteigend)

Die Prozedur hat keine Output-Parameter.

Die Rückgabe erfolgt als XML-Dokument welches gegen das Schema Response/EngineProcedure_v1_0.xsd validiert.

Der folgende Link öffnet in einem separaten Fenster den Engine Playground der fest mit dem dbap-demo System verbunden ist:

• pm_GetPChAccRestrForGroups_Ad im Engine Playground öffnen

Unformatierte Ausgabe:

curl -X GET  'http://<partner>-<project>.dstore.de/default/engine/pm_GetPChAccRestrForGroups_Ad'

Mit xmllint ⁶⁾ formatierte Ausgabe:

curl -X GET  'http://<partner>-<project>.dstore.de/default/engine/pm_GetPChAccRestrForGroups_Ad' | xmllint --format -

use dStore_php\WebService;
 
$service = new WebService\Service( WebService\Scheme::HTTP,'<partner>-<project>.dstore.de', 80);
 
$request = new WebService\Requests\Engine\Procedure\Request(
			new WebService\Requests\AccessData('default'),
	'pm_GetPChAccRestrForGroups_Ad',
		array(
			// 'UserGroupID' => NULL,
			// 'PersonCharacteristicID' => NULL
		)
);
 
$service->execute($request);
 
			$xml_result = $request->getResponse()->getBody()->toSimpleXmlDocument();
			$ResultSet = $xml_result->getRowsAsArray();

XML zur Ausführung mit der Methode engine/execute, z.B. per

curl --header 'Content-Type: application/xml' -X POST 'http://<partner>-<kunde>.dstore.de/default/engine/execute' -d '<xml-daten>'

<?xml version="1.0" encoding="UTF-8"?>
<ListOfBatches>
	<Batch No="0">
		<Procedure Name="pm_GetPChAccRestrForGroups_Ad">
			<Parameters>
				<!-- <Parameter Name="UserGroupID">NULL</Parameter> -->
				<!-- <Parameter Name="PersonCharacteristicID">NULL</Parameter> -->
			</Parameters>
		</Procedure>
	</Batch>
</ListOfBatches>