CampTypes, Organisationen und J+S

[carlobeltrame]

Anforderungen

eCamp soll von diversen Gruppen (Pfadi, Jubla, Cevi, Schulklassen ...) für verschiedene Arten von Lagern (J+S- und nicht-J+S-Lager, Kurse, Klassenlager, Musiklager, ...) nutzbar sein. Die Regeln für diese Kombinationen können sich laufend ändern, alte Lager sollen nach Regeländerungen weiterhin unverändert verfügbar bleiben, und jedes Lager bringt eigene Spezialfälle mit sich. Daher möchte ich die Neuentwicklung von eCamp dazu nutzen, eCamp v3 flexibler zu gestalten als eCamp v2.

Einige grobe strukturelle Punkte in denen sich Lager unterscheiden können sind:

• Zeitliche Lagerteile -> haben wir durch Perioden abgedeckt (diese dürfen sich jedoch bisher nicht überlappen)
• Örtliche Lagerteile -> haben wir durch zeitlich parallele Programmblöcke abgedeckt
• Betreuung -> Betreuungspersonen müssen auf eCamp im Lager hinzugefügt werden (ev. in Zukunft mit separaten Rollen), oder arbeiten nur mit exportiertierten PDFs
• Lagerform -> z.B. macht bei Unterwegs-Lagern eine einzige Lageradresse pro Periode kaum Sinn
• Altersgruppe der Teilnehmenden, und daraus folgend Sicherheitsanforderungen
• Partner-Organisationen (Dachverband, J+S NG3, andere J+S-Nutzergruppen, BSV, BAK, ...)
• Programm -> haben wir wohl mit dem Modell Kalender-mit-Detailprogrammen relativ gut abgedeckt
• Finanzierung / Budget / Subventionen / Sponsoring -> wird bisher nicht in eCamp gehandhabt

Diese Faktoren beeinflussen drei grobe Bereiche, und zwar jeweils für ein ganzes Lager wie auch für einen einzelnen Block:

• Speicherbare Daten - Lageradresse(n)? MZB im Block erlaubt ja/nein? Tages-Jobs? Ausbildungsziele? ...
• Kontrollen und Regeln - Anzahl LS-Stunden pro Tag? Block-SiKo, LA-Themenbereich oder Blockziele ausgefüllt? Dreiteiliger Block-Aufbau? ...
• Exporte - Grobprogramm, Kurs-Zielliste, Leihmaterial-Bestellformular, ...

Da die Lager auch z.B. innerhalb einer einzigen Organisation (PBS) stark variieren können, reicht es vermutlich nicht aus, für jede Organisation eine angepasste Instanz von eCamp v3 zu betreiben. Meiner Meinung nach sollte Konfiguration der Regeln und verfügbaren Features durch die Lagerleitung wo möglich über hart ausprogrammierte Regeln bevorzugt werden. Ausserdem sollte z.B. bei ändernder Formulierung eines PBS-Ausbildungsziels keinerlei Aufwand durch Programmierer nötig sein. Aus diesen Gründen erscheint mir der bisherige Approach mit CampTypes und ausprogrammierten Regeln à la if is_j_s then / if is_course then nicht besonders gut geeignet.

tl;dr beschlossene Massnahmen

• [ ] Doku: Entity DOM im Wiki aktualisieren
• [x] Backend: Camp-Teil (orange im UML) implementieren, dabei CampTypes vorerst entfernen
• [x] Backend: CampTemplate-Teil (grün im UML) implementieren
• [ ] Frontend: Translations ändern
• [ ] Frontend: ActivityContents bzw. Einstellungen in ActivityCategory pro Camp konfigurierbar machen

Ziel: Bis 23. Februar

Vision

Ich möchte der Lagerleitung in den angesprochenen Punkten möglichst grosse Flexibilität mit einfacher Benutzbarkeit bieten. Dazu schlage ich die Herangehensweise "alles erlauben und durch Vorlagen vereinfachen" sowie "intelligent sortierte, suchbare, globale Listen von Vorlagen und ContentTypes" vor (überspitzt formuliert).

Wenn ich eCamp von null auf neu bauen würde, würde ich es mir ungefähr wie folgt vorstellen (grosse Teile davon sind klar Post-MVP-Territorium):

Speicherbare Daten

• Ebene Block:
  • Grundsätzlich alle ContentTypes in jedem Block erlauben (was gewinnen wir wenn wir es verunmöglichen, in einem Essens-Block ein SiKo oder eine MZB hinzuzufügen?).
  • ActivityCategories, welche bisher fix die Struktur der Blöcke vorgegeben haben, als konfigurierbare Block-Vorlagen umfunktionieren. So sind sie Zusammenstellungen von ActivityContents, plus Metadaten wie Blockfarbe, Kürzel, etc.. Nachdem ich einen Block basierend auf einer Vorlage erstellt habe, ist der Block nicht mehr fix mit der Vorlage verknüpft, sondern ich kann alles nach meinen spezifischen Bedürfnissen anpassen. Jeder Benutzer kann neue Block-Vorlagen erstellen, die dann allen anderen Nutzern verfügbar sind.
  • Viele Use Cases können vermutlich durch ein allgemeines Tagging-System abgedeckt werden (z.B. Planungsfortschritt, LA-Themenbereich, Markierung als LS oder als LA, ...)
  • Beliebige Reihenfolge / Anordnung der ActivityContents ermöglichen (#627)
• Ebene Lager:
  • Die Lagerleitung sollte die für dieses Lager bevorzugten Block-Vorlagen definieren können.
  • Damit dies nicht in jedem Lager von neuem geschehen muss, könnte man CampTypes zu Lagereinstellungs-Vorlagen umfunktionieren. In einer solchen Lagereinstellungs-Vorlage sind Block-Vorlagen, Materiallisten, Kontrollen / Regeln, allfällige Feature Toggles etc. enthalten. Beim Eröffnen eines neuen Lagers sollte ich dann in allen Vorlagen suchen können, und relevantere Vorlagen sollten weiter oben auftauchen (z.B. Vorlagen von meinen vergangenen Lagern, oder von Personen mit denen ich schon ein Lager geleitet habe). So könnte die PBS Muster-Lager-Vorlagen erstellen, aber auch eine einzelne Abteilung oder ein Coach der spezielle Anforderungen hat. Nachdem ich eine Vorlage in mein Lager geladen habe, ist das Lager nicht mit der Vorlage verknüpft, sondern ich kann alles nach meinen spezifischen Bedürfnissen anpassen. Jeder Benutzer kann neue Lagereinstellungs-Vorlagen erstellen, die dann allen anderen Nutzern verfügbar sind.

Kontrollen und Regeln

• Ebene Block:
  • Noch unklar, möglicherweise erweiterte Validierung, von der Usability her ähnlich wie die CI Checks auf GitHub PRs?
  • Vielleicht kann ich als Blockautor aus einer Liste von Validierungen wählen, dass ich den aktuellen Block als LS validieren / markieren / zertifizieren möchte?
• Ebene Lager:
  • Ähnliche alternative Picasso-Ansichten wie die farbliche Fortschritts-Darstellung in eCamp2, aber statt Fortschritt werden z.B. Blöcke mit SiKo farbig markiert, oder Blöcke die bestimmte Tags drauf haben. Diese Ansichten könnten entweder programmiert oder vielleicht sogar durch die Lagerleitung definiert werden (mit einem zusammenklickbaren System -> liegt noch weit in der Zukunft).
  • Zusammenzüge über das ganze Lager ("habe ich alle J+S-Regeln beachtet?") könnten als Export realisiert werden, möglicherweise in einem separaten Webservice der auf die API zugreift.

Exporte

(alle Exporte könnten stattdessen auch als externe Services implementiert werden, die mit der API sprechen)

• Ebene Block:
  • Bisher sind mir hierzu noch keine weiteren Anforderungen bekannt, höchstens Export als iCal, aber Authentifizierung ist fraglich.
• Ebene Lager:
  • Zusätzlich zu den bisher angedachten PDF-Exporten werden weitere Exporte für Kurse, J+S-Administration, etc. gewünscht werden.

Vorschlag für MVP

Es ist klar, dass die oben beschriebene Vision grosse Änderungen am bestehenden Modell mit sich bringen würde. Der grösste Teil dieser Änderungen und Details kann auch noch Post-MVP genauer spezifiziert und umgesetzt werden. Fürs MVP schlage ich folgende Änderungen vor, um den Weg für zukünftige Erweiterungen in diese Richtung offen zu halten:

• ActivityCategories als Block-Vorlagen umfunktionieren. Ein Zeiger zur Vorlage ist immer noch nötig, da zum Beispiel die Farbe des Blocks weiterhin pro ActivityCategory bzw. Block-Vorlage geregelt ist.
• Die Lagerleitung sollte die für dieses Lager verfügbaren Block-Vorlagen definieren können (sie kann jetzt schon ActivityCategories erstellen, aber die enthaltenen ActivityContents müssten noch konfigurierbar gemacht werden). Die globale Block-Vorlagen-Liste können wir vorerst noch weglassen.
• CampTypes als Lagereinstellungs-Vorlagen umfunktionieren. Nachdem ich ein Lager basierend auf einer Vorlage erstellt habe, ist das Lager nicht mehr fix mit der Vorlage verknüpft, sondern ich kann Lager und Vorlage unabhängig voneinander nach meinen spezifischen Bedürfnissen anpassen.
• ActivityTypes entfernen, da sie nicht wirklich in das Vorlagen-System reinpassen (mir erscheinen ActivityTypes eher als Workaround bedingt durch relationale Datenbanken).

Nachteile dieser Herangehensweise

• Mehr initialer Denkaufwand beim Umdenken und Neu-Entwickeln der Features von eCamp2.
• User von eCamp2 könnten anfangs verwirrt sein. Das scheint mir aber kein guter Grund, um Limitierungen von eCamp2 in eCamp v3 nachzubauen.
• Abschaffen von veralteten ContentTypes wird schwieriger da es immer alte Lager geben kann die das noch verwenden könnten, aber das wird auch seltener nötig sein.
• Möglicherweise ist es für die Philosophie mit den langen suchbaren Listen dennoch wieder nötig, paginierte Collections zu implementieren, was wir bisher aufgrund der hohen Komplexität vermieden haben.
• Die gespeicherte Datenmenge in der Datenbank wird höher aufgrund der vielen änderbaren Kopien der Daten aus der Vorlagen.
• Weitere...?

Vergleich zum bisherigen Approach mit CampTypes (siehe auch https://github.com/ecamp/ecamp3/pull/691#issuecomment-741128463)

• CampTypes helfen, die verfügbaren ActivityTypes einzuschränken, die z.B. in J+S-Lagern anders sind als in Kursen. Im vorliegenden Vorschlag gibt es keine ActivityTypes, sondern Blöcke sind stattdessen frei zusammensetzbare Ansammlungen von ActivityContents, basierend auf Vorlagen aus einer durchsuchbaren, globalen, intelligent sortierten Liste. Ich spreche mich gegen ActivityTypes aus, weil diese im Grunde genommen ausprogrammierte Logik darstellen, welche stattdessen von den Usern gemanaged werden sollte. (Auch wenn die ActivityTypes in der Datenbank geführt werden und sogar von einem Organisations-Admin angepasst werden könnten, müssen sie bei Änderungen dennoch historisiert werden, damit alte Lager nicht kaputt gehen. Das ist es was für mich den "ausprogrammierten" Aspekt ausmacht.)
• CampTypes definieren, welche Standardkategorien (ActivityCategories) beim Eröffnen des Lagers erstellt werden. ActivityCategories werden im vorliegenden Vorschlag zu Block-Vorlagen umfunktioniert, so wie CampTypes zu Lagereinstellungs-Vorlagen umfunktioniert werden. Die Beziehung zwischen den beiden kann beibehalten werden.
• Am CampType hängen ActivityTypes und da dran hängen die ContentTypes die im Block erlaubt sind. Im vorliegenden Vorschlag wird es nicht mehr möglich sein, global einem Pfadilager einen ContentType der Cevi zu verbieten, da diese Lager gar nicht mehr klar unterschieden werden. Das müssen sie auch nicht. Als Beispiel gibt es auch katholische Pfadis die vielleicht von einem Gottesdienst-ContentType der Cevi profitieren können. Um einer Flut von verfügbaren ContentTypes entgegenzuwirken, muss natürlich die globale Liste mit verfügbaren ContentTypes sinnvoll sortiert sein, solange kein Suchbegriff eingegeben wird, und die ContentTypes müssen via Suche einfach auffindbar sein.

[pmattmann]

Ich kann mich mit dem Vorschlag gut anfreunden. Als Diskussionsgrundlage habe ich versucht ein entsprechendes UML zu erstellen.

• In grün, die Vorlage (Template).
• In orange, die daraus erstellten Lager-Objekte.
• In weiss, die erstellten Aktivitäten.

Meine Gedanken:

CampTemplate / Camp Options

Gemäss Skizze von @carlobeltrame sollten Features ein-/ausgeschalten werden. Hier bin ich unsicher, ob dies Spalten auf CampTemplate / Camp sind, oder ob es hier weitere Normalisierung bedarf.

ActivityCategory / ContentTypeConfig

Sobald das Lager erstellt ist - und die Initialen ActivityCategories und ContentTypeConfigs anhand deren Templates erstellt wurden, können diese beliebig verändert werden.

• Neue erstellen
• Verändern
• Löschen

ContentTypeConfig

Obwohl CantentTypeConfig Einstellungen wie 'Required' und 'Multiple' haben, könnte ich mir vorstellen, dass man diese innerhalb der Activity beliebig verletzen darf - so dass die Benutzer freie Hand haben. Zugleich könnten wir ausweisen, wo diese Einstellungen verletzt werden. Was einem Coach/Experten einen Quercheck erlaubt.

z.B. ActivityCategory "LS" muss ContentType "Block-Ziel" enthalten (Required ContentType) Kontrolle würde fehlende ContentTypes ausweisen.

Anhand von 'Required' könnten wir neue Activities mit einem initialen ContentType-Set erstellen.

ActivityContent

Es dürfen auch ActivityContents mit ContentTypes erstellt werden, welche innerhalb von ContentTypeConfig nicht vorhanden sind. Diese gemäss dem Vorschlag von @carlobeltrame "... weiter Inhalte".

Weitere Ideen:

Zeiger auf Template

• [Camp] -> [CampTemplate]
• [ActivityCategory] -> [ActivityCategoryTemplate]
• [ContentTypeConfig] -> [ContentTypeConfigTemplate]

Jeweils zur Dokumentation welches Template verwendet wurde. Zeigt auf, welche Templates wie oft verwendet werden. Zeiger sind 'nullable' und ohne Logik.

CampTemplate

Für MVP denk ich, stellen wir eine Liste von CampTemplates zur Verfügung. Post-MVP kann ich mir vorstellen, dass man eigne CampTemplates erstellen kann. Dazu gibt es dann wieder bissel was zu diskutieren:

• Wie kann die beliebig grosse Menge übersichtlich behalten werden?
• Owner?
• Visibility: Private / Public?

Camp aus Camp erstellen

Theoretisch könnte man aus einem Camp eine Vorlage erstellen - und diese so wiederverwenden. Damit die Menge an Vorlagen nicht explodiert, könnten wir Post-MVP auch die Funktion "Camp aus Camp" erstellen. Hierbei würden die Orangen Entitäten kopiert - jedoch nicht die weissen.

[manuelmeister]

Meeting Discussion

Nachteile:

• Mehr Denkaufwand ist vertretbar
• Abschaffung von ContentType wird schwieriger durch Templates => Markierung als Deprecated & mögliche Migration (lieber als Versionierung)
• Paginierte Collections ist nur aufwändig aber kein Blocker
• Mehr Daten ist kein Problem
• FYI: Die Vorlagen des Blocks sind hier noch nicht gelöst Es gibt zwei Diskussionen Vorlagen mit vollständigem Inhalt und Vorlagen ohne Inhalt (zB nur Titel der ActivityContents)

Anpassungen an der Spec

• DefaultInstances auf ContentTypeConfig setzen
• Orphan removal im Entity DOM anzeigen
• Feature Toggles noch nicht einbauen

Abgrenzungen

• Zeiger auf Template schliessen wir ein (In DB ohne Constraint)
• Ausschliessen:
  • CampTemplate
  • Camp aus Camp erstellen

Todos bis Core Meeting am 23. Februar

• Entity DOM im Wiki anpassen
• Template Teil (orange) implementieren
• Camp,… Teil (grün) implementieren

[carlobeltrame]

The decided MVP points from this issue have been implemented, resulting in the camp templates and the flexible activity layouts we have today. In the domains of rules + checks as well as exports for different types of camps, we can work on those after the go-live.