From 8ef18a03b2bc1aa49cca9a8486d74c17a9dead83 Mon Sep 17 00:00:00 2001 From: 0qln <0qln@proton.me> Date: Tue, 1 Sep 2026 12:22:39 +0200 Subject: [PATCH] 4.3.3: Verhalten bei unbekannten Typ-Ordnern gegen Code praezisiert --- TOOD.md | 2 +- chapters/conception/document-types.tex | 8 ++++++-- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/TOOD.md b/TOOD.md index 277041c..945337b 100644 --- a/TOOD.md +++ b/TOOD.md @@ -20,7 +20,7 @@ screenshots habe ich in figures/screenshots gelegt. - "3.4.1 Entwicklungsprozess" sollte dahingehend auch aktualisiert werden, und nicht *Linus-speziefisch* sein. - [x] "3.4.2 Schnitt der Product Backlog Items": ein abbild aus dem devops oder eine tabelle mit den PBIs ergaenzen verweisen - [x] "Figure 3.3: Chronologie der Infrastrukturbeschaffung" sieht komisch aus, die pfeile gehen nach unten Chronologie geht aber nach rechts. sollte gefixed werden. -- [ ] "4.3.3 Verhalten bei unbekannten Ordnern" (todo fuer mich) ist das richtig? oder werden unbakannte typ-order einfach nicht angezeigt? bin mir da gerade nichtmal sicher +- [x] "4.3.3 Verhalten bei unbekannten Ordnern" (todo fuer mich) ist das richtig? oder werden unbakannte typ-order einfach nicht angezeigt? bin mir da gerade nichtmal sicher - [ ] "4.4.1 Zuarbeit über einen Clickdummy" bezieht sich rein ueber das UI der Typ-Filterung. alles andere stammt von mir. Hanna Ebner hat in Houston die fuehrende Entscheidungskraft, was das UI angeht, und aus dem Grund habe ich mich mit ihr abgestimmt wie das aussehen soll, und sie hat als Referenz den Clickdummy branch erstellt. Die implementierung liegt immer noch in meiner hand. (das ist wichtig fuer das PIDI, da die Arbeit eigentlich von mir kommen soll). - [ ] in "4.4.2 Flache Liste statt navigierbarer Hierarchie": "Die ursprüngliche Beschreibung sah Dokumentkacheln vor, wurde jedoch auf Zeilen-darstellung geändert" auch das ist eine Entscheidung von Hanna Ebner, die meine überwichtete. - [ ] "4.4.3 Aufbau der Seite": screenshots im anhang einfügen und verweisen diff --git a/chapters/conception/document-types.tex b/chapters/conception/document-types.tex index c6849a1..987033f 100644 --- a/chapters/conception/document-types.tex +++ b/chapters/conception/document-types.tex @@ -36,9 +36,13 @@ Der Preis: Das Hinzufügen eines Typs erfordert eine Codeänderung und ein Relea \subsection{Verhalten bei unbekannten Ordnern} -Aus der festen Kodierung ergibt sich die Frage, wie mit Unterordnern umzugehen ist, die nicht im Katalog stehen — etwa einem Ordner \texttt{Sonstiges} in Filestash. +Aus der festen Kodierung ergibt sich die Frage, wie mit Unterordnern umzugehen ist, die nicht im Katalog stehen — etwa einem in Filestash von Hand angelegten Ordner \texttt{Sonstiges}. -Dokumente in solchen Ordnern werden angezeigt und erhalten ein neutrales Standard-Icon; lediglich die Typzuordnung entfällt. Ausblenden wurde verworfen, weil es stilles Fehlverhalten erzeugen würde: Ein Dokument wäre unsichtbar, ohne dass der Betreuer dies bemerkt. +Dokumente in solchen Ordnern werden angezeigt: Die Typableitung liefert keinen Treffer, das Dokument gilt als typlos und erhält den Anzeigetext \emph{Sonstige Dokumente} sowie ein neutrales Standard-Icon. Ausblenden wurde verworfen, weil es stilles Fehlverhalten erzeugen würde: Ein Dokument wäre unsichtbar, ohne dass der Betreuer dies bemerkt. Dieselbe Behandlung greift für Dokumente, die unmittelbar im Kundenordner liegen. + +Praktisch bleibt der Fall die Ausnahme, da Houston die Ordnerstruktur selbst anlegt und pflegt (siehe Abschnitt~\ref{sec:folder-management}) und dabei ausschließlich Ordner des Katalogs erzeugt. + +Zu unterscheiden ist dieser Fall vom Umgang mit unbekannten Ordnern auf der \emph{obersten} Ebene, wo ein fehlendes Marker-Metadatum zum vollständigen Ausschluss führt (siehe Abschnitt~\ref{sec:s3-layout}). Der Unterschied ist beabsichtigt: Auf oberster Ebene entscheidet die Struktur über die Mandantentrennung; innerhalb eines Kundenordners ist die Zugehörigkeit bereits geklärt. Zu unterscheiden ist dieser Fall vom Umgang mit unbekannten Ordnern auf der \emph{obersten} Ebene, wo ein fehlendes Marker-Metadatum zum vollständigen Ausschluss führt (siehe Abschnitt~\ref{sec:s3-layout}). Der Unterschied ist beabsichtigt: Auf oberster Ebene entscheidet die Struktur über die Mandantentrennung; innerhalb eines Kundenordners ist die Zugehörigkeit bereits geklärt.