Rollen und Berechtigungen im SDK

Operator-Kennungen auflösen und aus ihnen ableiten, welche Schritte der angemeldete Benutzer an einem Dokument ausführen darf.

Die fachlichen Hintergründe stehen in der Anleitung Rollen.

Operator als Identitäts-Konzept

Jede Partei im Dokument ist ein WasteOperatorType mit zwei Pflichtangaben: PartyUuid (technische Kennung) und OperatorInternalId (Kennung im DiWaSS-Operator-Verzeichnis, xs:long). Ein Name genügt nicht — die Kennung musst du vorher auflösen:

// EORI → matches in the DiWaSS operator directory (a list, not a single match)
var hits = await client.DiwassApi.OperatorApi.FindOperatorForEori(eori);

// own operator IDs of the logged-in account
IReadOnlyList<long> mine = await client.MyAccount.GetOwnDiwassOperatorIds();

Berechtigungen im SDK

Das SDK bringt eine rollenbasierte Vorprüfung mit. Sie ist ein Pre-Check für Oberflächen, keine Autorisierung — entschieden wird serverseitig.

Baustein	Namespace	Zweck
Role	Zedal.Sdk.Apis.Diwass.Permissions	die sechs Rollen
PermissionMatrix	Zedal.Sdk.Apis.Diwass.Permissions	darf diese Rolle diesen Vorgang grundsätzlich auslösen?
PermissionMatrixInference	Zedal.Sdk.Apis.Diwass.Permissions	welche Rollen hält eine Operator-Kennung in diesem Dokument?
DiwassIntents	Infotech.Zedal.Documents.V1.Zewass.V1	die Vorgangsarten als Enum — auch der Inhalt von handler.FollowupIntents

// derive roles from the document and the operator ID
ISet<Role> roles = PermissionMatrixInference.InferRoles(operatorId, handler.Notification);

// role-based
bool allowed = PermissionMatrix.CanPerform(Role.Notifier, DiwassIntents.CreateSubmission);

// intersection of "allowed by role" and "allowed by lifecycle"
var usable = PermissionMatrix.Filter(roles, handler.FollowupIntents);

Beide Klassen arbeiten auch auf Rollenmengen: Eine Operator-Kennung kann mehrere Rollen gleichzeitig halten — etwa Notifizierender und Abfallerzeuger.

Die Allow-Listen im Überblick:

Rolle	Erlaubte Intents
Notifier	CreateSubmission, UpdateSubmission, CreateReplyToRequestInformation, SubmitRequestForChangeAfterConsent, CreateMovementTemplate, UpdateMovementTemplate, CreateMovementTakeBack, UpdateMovementTakeBack, SubmitMovementSignal, dazu die vier Annex-VII-Intents des Arrangers
Consignee	CreateConsigneeReception, UpdateConsigneeReception und die Annex-VII-Pendants
Carrier	CreateCarrierTransport, UpdateCarrierTransport und die Annex-VII-Pendants
WasteProducer	leer
RecoveryDisposalFacility	CreateFacilityReception, UpdateFacilityReception, CreateFacilityCompletion, UpdateFacilityCompletion und die Annex-VII-Pendants
Authority	CreateRequestInformation, UpdateRequestInformation, SubmitDecision, UpdateDecision, SubmitAcknowledgement, SubmitReplyToRequestForChangeAfterConsent, SubmitMovementSignal

Drei Eigenheiten, die eine Oberfläche kennen muss:

Role.Authority lässt sich nicht ableiten

PermissionMatrixInference inferiert nur Rollen, die als Operator-Kennung im Dokument stehen. Behörden haben keine. Wer als Behörde handelt, übergibt Role.Authority explizit an die rollenbasierten Methoden.

Die Inferenz arbeitet außerdem ausschließlich auf der Serversicht (den Get…-Information-Typen). Direkt nach CreateSubmission und vor dem ersten Nachladen kommt ein leeres Set zurück — die Rollen sind dann noch nicht final, weil erst der Server festlegt, welcher Operator in welchem Slot landet.

Zwei SDK-Methoden haben überhaupt keinen Intent

SubmitNotificationSignal und SetFacilityCompletionUnderArticle15 haben kein Gegenstück im DiwassIntents-Enum. Folge: Die Permission-Matrix kann sie nicht bewerten, und sie erscheinen auch nicht in handler.FollowupIntents. Eine Oberfläche, die ihre Schaltflächen ausschließlich aus den Followup-Intents ableitet, zeigt Stornierung und Artikel-15-Bescheinigung nie an.

Die Matrix ist nicht die letzte Instanz

Die Rücknahme-Intents (CreateMovementTakeBack, UpdateMovementTakeBack) stehen in der Allow-Liste des Notifier, nicht in der der Authority. Nach der DiWaSS-Spezifikation ordnen die beteiligten Behörden die Rücknahme an; die Nutzlast verlangt einen Behörden-Domain-Code und eine Behördensignatur.

Ob eine Aktion jetzt zulässig ist, entscheidest du deshalb anhand von handler.FollowupIntents — die Liste kommt vom Server. Die Matrix eignet sich, um Aktionen anderer Rollen auszugrauen, nicht als letzte Prüfung.