Liefert Zugriffsbeschränkungen von (Datenbank-)Benutzern auf Personen-Merkmale.

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 „RestrictionForUserID“) 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 ein Benutzer 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. Soll ein Benutzer eine Eigenschaft zwar anlegen und ändern dürfen, man ihm aber verwehrt, Eigenschaften dazu zu löschen und der Benutzer Datenätze zum Merkmal GAR NICHT sehen soll (komplettes Leseverbot), 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 komplett verboten ist, steht in der Spalte „ReadAccessRestrictionPattern“ nichts (also „NULL“).
Anmerkung : Realistischer Anwendungsfall für so ein Szenario ist z.B. ein „internes Merkmal“ der Art „Bonitätsindex“, das für den „publicuser“ beschränkt werden soll. Dieses wird auf der Webseite - auf der in aller Regel die Prozedur-Aufrufe durch den Benutzer „publicuser“ erfolgen - zwar gesetzt (aufgrund webservice-Calls auf entsprechende Dienstleister z.B.), das soll aber dem Kunden auf der Webseite verborgen bleiben und nicht etwa aufgrund eines Programmierfehlers (durch den allein schon zu erkennen ist, daß es das Merkmal überhaupt gibt) doch sichtbar sein (und gelöscht werden soll die Eigenschaft auch nicht aus Versehen).

(parameterunabängige Sortierung)

• RestrictionForUserID (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_GetPChAccRestrForUsers_Ad im Engine Playground öffnen

Unformatierte Ausgabe:

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

Mit xmllint ⁶⁾ formatierte Ausgabe:

curl -X GET  'http://<partner>-<project>.dstore.de/default/engine/pm_GetPChAccRestrForUsers_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_GetPChAccRestrForUsers_Ad',
		array(
			// 'UserID' => NULL,
			// 'PersonCharacteristicID' => NULL,
			// 'EffectiveRestrForUserID' => 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_GetPChAccRestrForUsers_Ad">
			<Parameters>
				<!-- <Parameter Name="UserID">NULL</Parameter> -->
				<!-- <Parameter Name="PersonCharacteristicID">NULL</Parameter> -->
				<!-- <Parameter Name="EffectiveRestrForUserID">NULL</Parameter> -->
			</Parameters>
		</Procedure>
	</Batch>
</ListOfBatches>