Als Drittapplikation welche z.B. Abos für ein Magazin verkauft
möchte ich Rollen in hitobito via API mutieren können,
um nach dem Kauf für die Person auf hitobito automatisch eine Rolle in der entsprechenden Abbonnenten-Gruppe anzulegen.

Neu soll es möglich sein, via API Rollen zu erstellen, mutieren und löschen.

Tech-Spec

• Umsetzung im Core
• Das hitobito-Berechtigungssystem soll natürlich auch in der API gleich gelten.
  • Es gibt aber eine Abweichung: Rollen erstellen via API kann man nur, wenn man in der Gruppe Schreibrechte hat UND auf der Person Schreibrechte hat. Ist dies gegeben, dann können nämlich für die API Zugriffsanfragen für die erste Implementation mal ignoriert werden. Im UI wirken wir dem blinden Hinzufügen entgegen, indem wir dort ein Suchfeld anbieten mit dem man nach Name etc. suchen kann. In der API ist es aber üblich, einfach nur die ID der Person zu kennen (oder zu enumierieren), und gleichzeitig haben wir in der API weniger Möglichkeiten, dem Client eine ausstehende Zugriffsanfrage zu kommunizieren.
• Somit kann ein ServiceToken automatisch genau dann Rollen schreiben, wenn es die people und groups Berechtigungen und Schreibrechte hat. Es braucht in dieser ersten Version kein eigenes Flag auf ServiceTokens, mit denen man pro Token nochmals einzeln steuern kann ob Rollen schreiben erlaubt oder verboten ist.
• Bisher gibts auch noch keinen lesenden Endpoint /roles, dieser wird gleich mit implementiert
• destroy führt natürlich ein soft delete durch, d.h. intern wird einfach deleted_at auf jetzt gesetzt
  • Es ist auch möglich, via PATCH eine Rolle zu löschen, indem deleted_at auf jetzt oder in der Vergangenheit gesetzt wird

ToDo

• JsonApi::RolesController erstellen anhand Beispiel JsonAPI::PeopleController
• In routes.rb :index, :show, :update, :create, :destroy für :roles exponieren
• In der TokenAbility für Rollen-Berechtigungs-Entscheidungen (wie das ähnlich schon bei People gemacht ist) an die Ability des token.dynamic_user delegieren
  • Abweichung: Fürs Erstellen von einer Rolle via API muss man gleichzeitig auf die Gruppe und auf die Person Schreibrechte haben. Also zusätzlich zur normalen Ability braucht man die Schreibrechte auf der Person.
• In RoleResource Schreiboperationen aktivieren
  • person_id, group_id, type, created_at, updated_at sollen weiterhin nicht mutierbar sein (aber natürlich on create durch die API-Anfrage oder automatisch befüllt werden)
• Sicherstellen, dass die neuen /roles Endpunkte in der OpenAPI Spec dokumentiert sind
• Sicherstellen, dass im Log der Person (und Gruppe) die API-Schreiboperationen auf eine verständliche Art aufgezeichnet werden
• OpenAPI schema.json im Core und in allen Wagons aktualisieren
• Bestehende Specs wo nötig anpassen
• Specs schreiben für TokenAbility, RolesController bzw. Endpunkte sowie für PeopleController um sicherzustellen dass weiterhin via /people Endpunkt keine Rollen geschrieben werden können
  • Integration Test Case: CRUD von Rollen
  • Integration Test Case: Mit einem Service Token auf dem Dachverband kann eine Rolle in einer Dachverbands-Gruppe für eine Person in einem Unter-Layer erstellt werden, wenn das Token layer_and_below_full hat, aber nicht wenn das Token nur layer_full oder nur layer_and_below_read hat.
  • Integration Test Case: Rollen können nur via /roles Endpunkt mutiert werden, nicht via /people sideload write. (Dazu muss sicher mal auf der PersonResource weiterhin has_many :roles, writable: false stehen)
  • Integration Test Case: Via /roles Endpunkt können nur Rollen mutiert werden, nicht auch z.B. Gruppen oder Personen via sideload write. (Möglicherweise muss dazu auf der RoleResource bei den Relations writable: false ergänzt werden)
• CHANGELOG-Eintrag unter "unreleased" unten hinzufügen