search

ecamp / ecamp3

eCamp v3 is a web-based app for camp and course planning. The application is specialized for camps and courses of youth associations and for Y+S offers in the sport of camp sports/trekking.
https://ecamp3.ch
GNU Affero General Public License v3.0
110 stars 48 forks source link

Courses #4936

Open manuelmeister opened 2 months ago

manuelmeister commented 2 months ago

Kursziele/Kursanforderungen

Strukturierte Anforderungen/Ziele/Kompetenzen von einer Instanz (Schule, Verband, Bundesamt & eigenen Erwartungen) welche man Aktivitäten zuordnen kann. Die Use Cases sind:

A) Administration

  1. Als User möchte ich einen/mehrere Anforderungsbaum (zB PBS, SLRG und J+S) erfassen können. Die Anforderungsbäume haben eine maximale Tiefe (aktuell 3)
  2. Als Kursleitende Person möchte ich Anforderungsbäume aus einer Templatebibliothek importieren können, spätere Änderungen am Template haben keine Auswirkung auf bereits importierte Anforderungsbäume.
  3. Als Poweruser (zB Verbandsleitung/Sekretariat) kann ich die Template-Anforderungsbäume erstellen/ergänzen/verändern/löschen. In Zukunft werden diese Bäume (und sehr wahrscheinlich auch Lagervorlagen) wohl noch zusätzliche Metadaten benötigen (Sprache, Organisation, User Access,…)
  4. Als Kursleitende Person möchte ich einzelne Anforderungsbäume aus existierenden Lager/Kursen importieren können.
  5. Als Kursleitende Person möchte ich beim erstellen eines Lagers von einer Vorlage sämtliche Anforderungsbäume mit kopieren. Auf den globalen Lagervorlagen möchte das eCamp Core Team aktuell keine Anforderungsbäume erfassen, weil sonst die Anzahl benötigte Lagervorlagen explodieren würde (würde separate Vorlagen pro Kursart, Verband und Sprache nötig machen, anstatt nur pro Sprache)

B) Activity Ebene

  1. Als User möchte ich in der Aktivität beliebig viele Anforderungen/Ziele aus den Anforderungsbäumen auswählen. In Zukunft könnten wir dem User ermöglichen, zu verbieten den Knoten auszuwählen
  2. Als User kann ich einen ContentType "Anforderungen/Ziele" einer Aktivität/Aktivitätsvorlage (Category) hinzufügen.
  3. In Zukunft kann im ContentNode die Baumauswahl beschränkt werden.

C) Reporting

  1. Anforderungsorientiert: Als User kann ich für jede Anforderung sehen durch welche ScheduleEntries diese Anforderung abgedeckt ist.
  2. ScheduleEntry orientiert: Für Felder die pro ScheduleEntry ausgewertet werden soll, wird ein eigener ContentType erstellt. Aktuell sind das Anforderungsbaum, Blockziele & Blockinhalte. PDF, fix, ein Knopf.
pmattmann commented 2 months ago
Variante 1 Variante 2 Variante 3
Variante 1 Variante 2 Variante 3 
>> Variante 3 <<

[ContentNode]
[ColumnLayout|data]
[ChecklistNode;#selectedChecklist]
[Checklist|Name;Organisation;Language]
[ChecklistItem|Text]

[ContentNode]^[ChecklistNode]
[ContentNode]^[ColumnLayout]

[Camp]<>-*>[Checklist]
[Checklist]<>-*>[ChecklistItem]
[ChecklistItem]<*children-<>[ChecklistItem]

[Camp]<>-*>[Activity]
[Activity]rootContentNode-1>[ColumnLayout]
[ContentNode]<* children-<>[ContentNode]
[ColumnLayout]<>       des-*>[ContentNode]

[Checklist]-.-option[ChecklistNode]
[ChecklistNode]<*-*>[ChecklistItem]
manuelmeister commented 4 weeks ago

Core Meeting Decision

We choose Variant 3. Relation Checklist -> Camp can be nullable.

In the future we can still elevate the n:m relation to its own entity and a theoretical future camp checklist will just be a TodoList.

pmattmann commented 3 weeks ago

I'm afraid we'll have to discuss the naming again.

For the first implementation we need to name three entities:

My suggestion (see UML 'Variante 3') As identical as possible to material lists:

pmattmann commented 3 weeks ago

FYI: I started to work on the backend: https://github.com/pmattmann/ecamp3/tree/feature/checklist

CI (mandatory checks)

Backend

Frontend

...

manuelmeister commented 2 weeks ago

Core Meeting Decision

We go with the version 3:

In the future we may want to rename our contentnodes to reflect that they are Nodes or Layouts. This should be first sketched in a issue before renaming all the things.