Courses

[manuelmeister]

Kursziele/Kursanforderungen

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

• richtet sich der Aktivitätsinhalt nach den Anforderungen?
• sind alle Anforderungen an ein Lager/Kurs durch das Programm abgedeckt?

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]

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]

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]

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

For the first implementation we need to name three entities:

• 'Checklist', which can be created (or imported) per camp
• 'ChecklistNode', tree structure within a 'Checklist'
• 'ChecklistContentNode', a derivative of ContentNode, defines which Checklist has been selected; and which ChecklistNodes are selected from it.

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

• Checklist
• Checklist-Item
• Checklist-Node

[pmattmann]

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

Backend

• Checklist Entity
• Checklist UnitTests
• ChecklistItem Entity
• ChecklistItem UnitTests
• ChecklistNode Entity
• ChecklistNode UnitTests

Frontend

...

[manuelmeister]

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.