Anlegen, Editieren und Löschen von Bommeln via API

[d135-1r43]

User Story

Als Benutzer und Entwickler möchte ich eine REST API zur Verwaltung von „Bommeln“ verwenden, um grundlegende CRUD-Operationen (Erstellen, Lesen, Bearbeiten, Löschen) an Bommeln durchzuführen und diese in der hierarchischen Struktur eines Vereins zu verwalten.

Ein Bommel ist ein Knotenpunkt innerhalb der Organisationsstruktur eines Vereins. Ein Bommel kann verschiedene Typen repräsentieren, wie z. B. Abteilungen, Teams, Projekte, Konten oder Kassen. Die Bommelstruktur ist baumartig organisiert, was bedeutet, dass jeder Bommel Verbindungen zu einem übergeordneten Bommel haben kann und so die Hierarchie innerhalb des Vereins widerspiegelt.

Akzeptanzkriterien

• Die REST API muss folgende Funktionen bieten:

  • Erstellen eines neuen Bommels
  • Bearbeiten eines bestehenden Bommels
  • Löschen eines Bommels
  • Verschieben eines Bommels innerhalb der Struktur (Ändern des übergeordneten Knotens)

• Attribute eines Bommels:

  • Name: Ein String, der den Namen des Bommels beschreibt
  • Icon: Ein Emoji, das den Bommel visuell repräsentiert
  • Bommelwart: Ein zugewiesener Benutzer (User), der für diesen Bommel verantwortlich ist

• OpenFGA ist integriert, jedoch ohne ein spezifisches Schema. Es dient als Grundlage für zukünftige Rechte- und Rollenmanagement-Implementierungen.

• Fehlerbehandlung:

  • Versuche, Bommeln zu verschieben oder zu löschen, dürfen die Baumstruktur nicht inkonsistent machen (z. B. keine Zyklen erlauben oder Bäume abtrennen).

• Extrem hohe, nahezu 100%ige Testabdeckung. Diese Datenstruktur wird der Kern von Hopps, wird oft refakturiert und erweitert werden und sollte daher extrem stabil und getestet sein.

• Performance:

  • Das Laden der gesamten Bommelstruktur muss performant sein, auch bei vielen Knotenpunkten.

[schitcrafter]

Ich würde gerne an dem Issue arbeiten.

Dürfen postgres-exklusive features (z.B. ltree) genutzt werden?

[manuelhummler]

@schitcrafter von meiner Seite aus wäre das in Ordnung. Ich denke mit Postgres fahren wir auf jeden Fall mit einer stabilen Datenbank, die alle Features die wir in Zukunft benötigen mitbringt. Gerne aber noch das Feedback von @d135-1r43 abwarten, was er meint.

[schitcrafter]

Ich habe noch ein paar weitere Fragen:

• Nutzen wir unicode emojis oder strings (wie z.B. :tada: :tada:), um emojis zu repräsentieren?
• Gibt es für das frontend, sowie andere Systeme die auf die Bommel API zugreifen wollen, einen bevorzugten Weg, diese Daten zu strukturieren (z.B. hat ein Bommel eine Parent ID, oder einen Path vom Root zu ihm)?
• Soll das ganze in app.hopps.org stattfinden oder in einem anderen microservice?

[d135-1r43]

• Postgres-exklusive Features sind okay, es sollte aber gut mit Panache handhabbar sein.
• Ja, direkt der Unicode-String. Es muss auch mehr als ein Charakter möglich sein, weil Gender, Hautfarbe usw. oft zwei Emojis sind.
• Ja, das Frontend weiß, welcher Verein gerade aktiv ist. Es muss möglich sein, mit dem Verein an den Root-Bommel zu kommen.
• Ja, in app.hopps.org

[schitcrafter]

Noch ein paar Fragen zu OpenFGA/Auth:

Soll die Implementierung (zu z.B. welche relation für jede Operation geprüft wird) sehr generisch/konfigurierbar gemacht werden, oder ändern wir den code sobald wir das Schema entwickelt haben?

Woher wissen wir welcher User eine Anfrage gestellt hat (z.B. JWT Bearer)?

[d135-1r43]

Soll die Implementierung (zu z.B. welche relation für jede Operation geprüft wird) sehr generisch/konfigurierbar gemacht werden, oder ändern wir den code sobald wir das Schema entwickelt haben?

Definiere mal eine generische, z. Bsp. read und write. Wenn sich das ändern sollte, refakturieren wir einfach.

Woher wissen wir welcher User eine Anfrage gestellt hat (z.B. JWT Bearer)?

Wenn ich es recht in Erinnerung habe, kannst du dir den SecurityContext injecten. Dort bekommst dann irgendwie den Principal raus.