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

• [x] Checklist Entity
• [x] Checklist UnitTests
• [x] ChecklistItem Entity
• [x] ChecklistItem UnitTests
• [x] ChecklistNode Entity
• [x] 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.

[manuelmeister]

Currently while prototyping the frontend (https://github.com/ecamp/ecamp3/pull/5460), I thought to myself, that we probably need an (optional) numbering system for the checklist items, similar to the schedule entries? What do you think?

[manuelmeister]

How many characters [for the checklist item text] should be supported? – @pmattmann

I don't know. Who gathered the different checklists (PBS, J+S, Jubla, Cevi, …)? Maybe we should decide based on actual data, or find out what people want (maybe even a short and long reference to a checklist item?)

[manuelmeister]

Core Meeting Decision

• We try out 256 chars for the checklist item title. If @carlobeltrame doesn't find more outliers that would need more chars.
• The numbering system needs to be more stable. For every parent (including null) the position should be ordered. We might consider per checklist different numbering styles in the future. The parent numbering concatination should be done by the frontend (e.g. 1.3.2).

[pmattmann]

Core Meeting Decision

• We try out 256 chars for the checklist item title. If @carlobeltrame doesn't find more outliers that would need more chars.
• The numbering system needs to be more stable. For every parent (including null) the position should be ordered. We might consider per checklist different numbering styles in the future. The parent numbering concatination should be done by the frontend (e.g. 1.3.2).

ChecklistItem text length is changed to 256 in https://github.com/ecamp/ecamp3/pull/5408/commits/233b47d1d7763def2b77700770e2ea6d2bf56a41 Improve numbering system is done in https://github.com/ecamp/ecamp3/pull/5408/commits/d080c5f86c713855783cd7a6686a08d3c19f0b7d

[manuelmeister]

@pmattmann what happens/should happen when we delete a checklist that is referenced in a contentnode?

[manuelmeister]

Core Meeting Decision

@simfeld can you gather all PBS checklists?

@pmattmann can you sketch requirement A2? How do we manage this?

[pmattmann]

Copy Checklist

Copy Checklist ist im Backend teilweise implementiert. Siehe hier, hier und hier

Feature A2

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.

Variante 1:

Checkliste-Vorlagen werden an ein Camp-Prototype gehängt. GUI loopt über alle Camp-Prototypes und sucht alle Checklisten zusammen. Alle Checklisten, welche gefunden werden, als Vorlage (Prototype) angeboten. Beim erstellen einer neuen Checkliste kann optional eine Vorlage ausgewählt werden. Checkliste-Vorlagen werden per SQL (Migration) eingefügt.

Pro:

• Kann schnell implementiert werden

Cons:

• Wer Zugriff auf ein Camp-Prototype hat, kann Checklist-Vorlagen erstellen -> enge Kopplung

Variante 2:

Im Backend wird pro Vorlage ein JSON-File abgelegt (auf Disk). Ein eigener Endpunkt für Checkliste-Vorlagen liest die Files von der Disk und bietet diese als Entitäten an.

File-Content:

{
  "id": "a1b2c3d4",
  "name": "Basiskurs Pfadistufe",
  "sprache": "de",
  "items": [
    {
      "text": "First-Level-Eintrag",
      "items": [
        { "text": "Second-Level-Eintrag", "items": [] },
        {
          "text": "Second-Level-Eintrag 2",
          "items": [
            { ... }
          ]
        }
      ]
    }
  ]
}

Endpunkt: /api/checklist_prototypes{?sprache=de}

{
  "_links": { "self": { } },
  "totalItems": 3,
  "_embedded": {
    "items": [
      {
        "_links": { "self": { } },
        "id": "a1b2c3d4",
        "name": "Basiskurs Pfadistufe",        
      },
    ]
  }
}

Pro:

• JSON-File ist einfach genug, dass man diese extern geben kann.

Cons:

• Zusätzlicher Mechanismus

[manuelmeister]

Core Meeting Decision

We want variant 1

• Checklist add prototype-flag
• ref. auf Camp nullable
• api auth anpassen, so dass prototype-checklist readable ist.
• api auth anpassen, so dass prototype-checklist von admin writeable

Frontend:

• Admin-GUI zur Bearbeitung von Prototype-Checklists
• Checklist-Create-Dialog Auswahl von Prototype-Checklist ergänzen

[simfeld]

source for checklists (PBS)

• DE https://pfadi.swiss/de/publikationen-downloads/downloads/?search=checkliste&c=36
• FR https://pfadi.swiss/fr/publications-telechargements/downloads/?search=check-list&c=36
• IT https://pfadi.swiss/it/pubblicazioni-downloads/downloads/?search=check-list&c=36

[pmattmann]

Open requirements

• [x] Delete Checklist on Camp Check, if any ChecklistItem is used in any ChecklistNode - if it is, disallow deleting @manuelmeister