Quelltext der Seite Task-based role system and access control

== Einleitung ==
Das ehrenamtliche System der Freiwilligen ist hinsichtlich der Aufgabenverteilung hochdynamisch. Aufgaben werden mitunter wöchentlich neu vergeben, teilweise zerlegt und neu zusammengesetzt, so dass klassische Rollensysteme nicht angewandt werden können. Mit der Bewältigung von Aufgaben können auch stets spezielle Zugriffsrechte innerhalb des Pools verbunden sein. Daher impliziert eine neue Gestaltung des Rollensystems auch eine Umgestaltung der Konzeption der Zugriffsrechte.

Es soll also ein Konzept entwickelt werden, welches die Verwaltung von Zugriffsrechten über dem Nutzer zugeordnete Aufgaben erlaubt. Hierfür ist es notwendig Aufgaben im digitalen System zu verwalten (CRUD) und diese auf Ebene der Crews (und teilweise durch das Brunnenbüro) zu verteilen. Ein Nutzer kann dann auf eine Funktion zugreifen, wenn dem Nutzer Aufgaben zugewiesen sind, die den Zugriff auf die Funktion erlauben. 
Da es viele kleine Aufgaben geben wird, ist eine skalierbare Verteilung der Aufgaben nötig. Dies wird über dynamische Rollen erreicht. Eine Crew ist in der Lage Rollen zu definieren und diese Rollen einzelnen (oder auch parallel mehreren) Supportern zuzuweisen. 

== Access Control ==
*  Zuordnung Zugriffsrechte -> Aufgabe: Entwickler beschreiben kurz Sinn & Zweck einer Action, benennen diese und bündeln die Action ggf. mit anderen Actions. Diese beschriebenen Actions können dann Aufgaben (Tasks) zugeordnet werden, was einer impliziten Permission im Kontext des Tasks entspricht.
*  MS fragt Nutzer bei Drops (Nutzer via Shared Sessions) und Tasks MS (für Tasks des Nutzers) an --> beide Infos können in Session gespeichert werden --> Für Veränderungen der Tasks-Liste eines Nutzers PUSH Kommunikation von Task MS zu MS implementieren?
*  Po(Nutzer, Task) mit Task in Tasks kann bestimmt werden, da (Task, Action) Assoziation existiert --> Sum(Po(Nutzer, Task) | Task in Tasks) != Empty? --> Permission granted
*  Braucht View in der Assoziationen zwischen Tasks und Zugriffsrechten (Actions) hergestellt werden kann. Dabei bestehen Many-to-Many Beziehungen zwischen Tasks und Actions
*  View dafür in eigenem MS oder Tasks MS? --> leitet Assoziationen (task_id; action_id) an die jeweiligen MS weiter, die die Actions verwalten --> MS müssen eine ACL für Tasks implementieren

== Role-Task Model ==
Für die Implementierung eines Task-based Access Control (TBAC) müssen die Tasks den einzelnen Nutzern zugeordnet werden. Dabei ist aufgrund der Flexibilität des sozialen Systems von Ehrenamtlichen Dynamik vorzusehen.
*  Zwei Typen von Tasks: Wiederkehrende Tasks + Einmalige Tasks
*  Mehrere Tasks bilden eine Rolle
*  Tasks werden auf mehreren Ebenen definiert: Projekt, Crew, Organisation (z.B.: Ohrbooten Konzert (Projekt), in Crew Berlin (Crews), für Viva con Agua de St. Pauli (Organisation))
*  In jeder Crew bekommen ein (oder mehrere) Supporter den Task neue Tasks zu definieren und diesen die entsprechenden Actions zuzordnen; anschließend sollen sie Rollen in ihren Crews definieren, denen sie mehrere Aufgaben zuweisen
*  gleiches Vorgehen für Organisationen 
*  es werden typische / allgemeine Aufgaben / Rollen vorgeschlagen (gemeinsam mit BB oder über Workshops zu entwickeln)
*  auch für typische "Projekte" (z.B. Konzerte) werden typische Pakete von Aufgaben vorbereitet und den Nutzern bereitgestellt

=== Ver- und Aufteilung von Aufgaben ===
*  Nutzer können anderen Nutzern Aufgaben anbieten --> Entweder als Übergabe (neuen Nutzer assignen) oder als Beteiligung (zusätzlichen Assignee)
*  Nutzer können Aufgaben aufsplitten --> '''Todo: Was ist mit der Kontext-abhängigen Aufgabe, dass ein Finanzer mal eben einem Konzert-ASP erlauben will die Eintragung der Spendensumme für Konzert xy vorzunehmen?'''
*  Aufgaben direkt bei der Eingabe eines Protokolls erstellen und assoziieren

=== Ver- und Aufteilung von Rollen ===
*  Nutzer können anderen Nutzern Rollen anbieten --> Entweder als Übergabe (neuen Rolleninhaber; übergebendem Nutzer wird Rolle entzogen) oder als Beteiligung (zusätzlichen Rolleninhaber)
*  Nutzer (Rolleninhaber und alle Nutzer mit der Aufgabe die Rollen-Aufgaben-Zugriffsrechte zu bestimmen) können Rollen aufsplitten --> Es entstehen mehrere neue Rollen, mit je einem Subset an Aufgaben
*  Rollen können über gleiche Aufgaben verfügen
*  mehrere Nutzer können die gleiche Rolle haben

== Offene Herausforderungen ==
*  Hierarchien innerhalb der Aufgaben und Rollen? --> Was passiert wenn eine Rolle oder Aufgabe zwischen zwei Personen aufgeteilt werden soll?
*  Vorgabe bestimmter Rollen und Aufgaben? Ist das BB in der Lage jeder Crew Aufgaben und damit inherent auch Rollen vorzugeben? Wenn ja: Wie kann deren Verteilung realisiert werden, vor allem in Bezug auf der erste Frage der Aufteilung von Aufgaben und Rollen? Sind diese Rollen aus Sicht der Crews statisch?
*  Initiierung des Systems durch die Verteilung der Aufgabe "Aufgaben und Rollen definieren und verteilen" an einzelne Supporter innerhalb der Crew durch das BB
*  Mapping zwischen Aufgaben und Zugriffsrechten und der damit verbundenen Implementierung des neuen Systems? Woher weiß ich an einer Action, ob der aktuelle Nutzer Zugriff auf diese hat?

== Offene konzeptionelle Aufgaben ==

* Definition des Assignee-Prozesses
* Definition der notwendigen Awareness Systeme für das Task-Managment (Workspace- und Gruppen-Awareness)