-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Courses #4936
Comments
Core Meeting DecisionWe choose Variant 3. 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 |
I'm afraid we'll have to discuss the naming again. For the first implementation we need to name three entities:
My suggestion
|
FYI: Backend
Frontend... |
Currently while prototyping the frontend (#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? |
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?) |
Core Meeting Decision
|
ChecklistItem text length is changed to 256 in 233b47d |
@pmattmann what happens/should happen when we delete a checklist that is referenced in a contentnode? |
Core Meeting Decision@simfeld can you gather all PBS checklists? @pmattmann can you sketch requirement A2? How do we manage this? |
Copy ChecklistCopy Checklist ist im Backend teilweise implementiert. Feature A2Als 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. Pro:
Cons:
Variante 2:Im Backend wird pro Vorlage ein JSON-File abgelegt (auf Disk). 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: {
"_links": { "self": { } },
"totalItems": 3,
"_embedded": {
"items": [
{
"_links": { "self": { } },
"id": "a1b2c3d4",
"name": "Basiskurs Pfadistufe",
},
]
}
} Pro:
Cons:
|
Core Meeting DecisionWe want variant 1
Frontend:
|
Open requirements
|
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
Die Anforderungsbäume haben eine maximale Tiefe (aktuell 3)
In Zukunft werden diese Bäume (und sehr wahrscheinlich auch Lagervorlagen) wohl noch zusätzliche Metadaten benötigen (Sprache, Organisation, User Access,…)
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
In Zukunft könnten wir dem User ermöglichen, zu verbieten den Knoten auszuwählen
Category
) hinzufügen.C) Reporting
The text was updated successfully, but these errors were encountered: