Skip to content

[Epic] Generischer Freigabeworkflow (4-Augen-Prinzip)

Warum

Das Self-Service-Portal wird von Teams genutzt. Innerhalb eines Teams kann es verschiedene Rollen geben. Die von einem Team im SSP verwaltete Ressourcen gliedern sich in Bereiche. Selbst innerhalb eines Bereiches, kann es Daten von unterschiedlicher Wichtigkeit geben. Nutzer des SSP wollen daher ihre Arbeit im SSP organisieren können. Das betrifft sowohl den Zugriff der Teammitglieder auf Bereiche und Ressourcen innerhalb eines Bereiches, als auch den Workflow der Bearbeitung.

Ziel

Der / die Owner eines Teams sollen den Team-Mitgliedern differenzierten Zugriff auf Objekte (Bereiche und sogar einzelne Ressourcen innerhalb eines Bereichs) gewähren können. Dabei soll es möglich sein, für Objekte einen zwei- oder dreistufigen-stufigen Freigabeworkflow zu aktivieren und die entsprechenden Rechte zu verwalten. Im Sinne einer generischen Umsetzung sollen die Module (FIT-Connect-Verwaltung, Parameter-Pflege, Statusmeldungen für 115) die Informationen selbst tragen bzw. der Owner ggf. selbst Objekte innerhalb eines Moduls definieren können.

Beispiel für ein sehr differenzierten Objekt-Gestaltung: Bei der Parameter-Pflege ist nicht nur die fachliche Zuständigkeit von Teammitgliedern von Bedeutung. Es gibt auch Parameter von unterschiedlicher technischer Relevanz. Einige Parameter enthalten technisch wenig brisante Informations-Texte, andere hingegen technisch relevante Werte, deren Fehlkonfiguration zu technischen Störungen führen kann. Entsprechend werden unterschiedliche Nutzer(-Gruppen) die Pflege übernehmen und je nach der Brisanz ein Freigabeworkflow verwendet werden.

Links, Hinweise, Bemerkungen

Entwurf_für_die_Umsetzung

Objekte können je nach Bereich feingranular sein. Bsp:

  • Zustellpunkte sind insgesamt ein Objekt eine tiefergehende Differnezierung der Attribute wir eher nicht benötigt (es sind alles technische Daten)
  • 115 unterscheidet zwischen den Objekten "Onlinedienst" und "Statsumeldung". Für beide kann unabhängig ein Workflow eingerichtet werden.
  • Bei der Parameter-Pflege kann am stärksten differneziert werden. bei den Feldern zu einem "Onlinedienst" kann der Owner ggf. Feldergruppen definieren, für die er eigene Workflows einführt.

Die Differenzen bei einer Änderungen (Ist/Soll-Zustand) müssen für die Freigabe deutlich sein.

Fragestellungen / Entscheidungen

  1. Darf der Owner weiterhin alles und kann damit auch das 4-Augen-Prinzip umgehen?
    -> Ja, Zweck des 4-Augenprinzip ist es untergeordnete Stellen und externe Dienstleister zu managen.

  2. Wie wird die Kombination der Rechte "bearbeiten" und "freigeben" umgesetzt?

  • Variante 1: Bearbeiten und Freigeben kann durch diselbe Person erfolgen, wenn sie beide Rechte hat, aber in 2 Schritten.
  • Variante 2: Die Freigabe muss durch eine andere Person als den Bearbeiter erfolgen, selbst wenn dieser auch das Freigaberecht hat.
  • Variante 3: Kombination von Variante 1 und 2. Es wird zwischen den Rechten "bearbeiten", "freigeben der Bearbeitungen anderer" und "freigeben eigener Bearbeitungen" unterschieden.
    -> Variante 1 wird bevorzugt, da sie flexibler ist und es den Nutzern erlaubt, das ggf. durch eine interene Arbeitsanweisung zu regeln.

  1. Sind Änderungen (Change-Requests) möglich, während die Freigabe für eine Änderung aussteht? Kann es nur einen Änderungsdatensatz geben oder parallel mehrere? Wie gehen wir damit um, wenn sich während der Freugabe am Ausgangszustand etwas ändert.
    -> Für dieselbe Ressource kann es nicht mehr als einen Change-Request geben. Der Change-Request kann aber nach einer Warnung von einem anderen Mitarbeiter übernommen und angepast werden.

  2. Wie wird der Fall behandelt, dass währen ein Change-Request aussteht per API Änderungen vorgenommen werden?
    -> Wenn ein Zielobjekt per API geändert wird, wird der Change-Request verworfen. In dem Augenblick, indem ein Change-Request für die Freigabeprüfung aufgerufen wird, prüft das SSP, ob es Änderungen per API gab. Wenn ja, wird eine Meldung angezeigt und der Change-Request verworfen. Alternative (wird estmal nicht umgesetzt): Die Diff-Übersicht Zeit auf einer Seite den IST-Uzstand (ggf. nach API-Änderungen) an und auf der anderen Seite die Änderungen durch den Change-Request. Dabei sieht man, welche Felder übereinstimmen, welche Felder bewusst im Rahmen des Change-Requests geändert werden sollten und welche Felder sich deswegen unterscheiden, weil seit Erstellen des Change-Requests per API etwas geändert wurde.

  3. Kann der Freigebende Cherry-Picking betreiben und nur einzelne Werte freigenen?
    -> Nein, zu kompliziert

  4. Workflow
    Zurückweisung mit Kommentar, "Antragsteller" wird per Mail informiert, sieht den Kommentar und kann den ChangeRequest bearbeiten und neu einreichen

  5. Bis zu 2 Freigabestufen

  • Konfigurierbar pro Ressource, ob 1 oder 2 stufig
  • Unterschiedliche Rechte Freigabe1 und Freigabe2
  • Workflow: ChangeRequest -> Benachrichtigung User mit Freigabe1 (-ChangeRequest-Ersteller) -> Benachrichtigung User mit Freigabe2 (-ChangeRequest-Ersteller und -User Freigabe1)
  1. Fernziel
  • Bei den Paramtern kann der Freigabe für Feldergruppen konfiguriert werden
  • Rechte werden über User-Gruppen verwaltet
  • Freigabe / Rechte können nicht nur für Ressourcentypen sondern auch für spezifische Ressourcen konfiguriert werden (Bsp. Freigabeworkflow bzw. Rechte für Parameter-Service-Onlinedienste grundsätzlich oder für spezifische Onlinedienste)
  1. MVP
  • 4-Augenprinzip nur für Parameter-Pflege
  • Noch keine User-Gruppen
  • Noch keine Felder-Grupppen, nur die Objekttypen "Organisationseinheit" und "Onlinedienst"
  • Noch keine differenzierte Berechtigung für einzelne Onlinedienste

Stories

Akzeptanzkriterien

  1. ...
  2. ...
  3. ...
  4. Definition of Done wurde überprüft.

Mögliche Folgeaktivitäten

Offene Fragen

Edited by Andreas Aschauer