54 lines
4.2 KiB
TeX
54 lines
4.2 KiB
TeX
\section{Dokumententypen und Icons}
|
|
\label{sec:document-types}
|
|
|
|
\subsection{Der Typenkatalog}
|
|
|
|
Die sieben Dokumententypen wurden in der Feature-Beschreibung festgelegt und im Projektverlauf nicht verändert. Tabelle~\ref{tab:document-types} zeigt den Katalog mit dem jeweiligen Ordnernamen im Speicher.
|
|
|
|
\begin{table}[H]
|
|
\centering
|
|
\begin{tabularx}{\textwidth}{@{} l X @{}}
|
|
\toprule
|
|
\textbf{Ordnername im S3} & \textbf{Fachliche Bedeutung} \\
|
|
\midrule
|
|
\texttt{Service-Protokoll} & Protokolle erbrachter Serviceleistungen \\
|
|
\texttt{Abnahme Dokumente} & Abnahmeprotokolle abgeschlossener Projekte \\
|
|
\texttt{SLA-Reports Ticketbearbeitung} & Auswertungen zur Einhaltung vereinbarter Reaktionszeiten \\
|
|
\texttt{Monitoring Reports} & Periodische Auswertungen aus der Systemüberwachung \\
|
|
\texttt{Security Assessments} & Ergebnisse von Sicherheitsbewertungen \\
|
|
\texttt{Abrechnungsdaten} & Abrechnungsunterlagen, gegliedert nach Monat, Jahr und Service \\
|
|
\texttt{Vertragsunterlagen} & Verträge, Leistungsscheine und zugehörige Dokumente \\
|
|
\bottomrule
|
|
\end{tabularx}
|
|
\caption{Katalog der Dokumententypen}
|
|
\label{tab:document-types}
|
|
\end{table}
|
|
|
|
\subsection{Feste Kodierung statt Konfiguration}
|
|
|
|
Im Approval-Termin stellte \emph{Timo Walter} die Frage, ob die Kategorien konfigurierbar sein sollen. Die Entscheidung fiel auf eine feste Kodierung in Houston.
|
|
|
|
Der Typenkatalog ist fachlich stabil und ändert sich allenfalls im Rhythmus von Jahren. Konfigurierbarkeit würde Verwaltungsoberfläche, Speicherformat und Migrationsstrategie erfordern — ein unverhältnismäßiger Aufwand.
|
|
|
|
Hinzu kommt, dass jeder Typ ein Icon und eine Übersetzung benötigt, die bei einem frei konfigurierbaren Katalog ebenfalls hinterlegbar sein müssten. Die feste Kodierung stellt sicher, dass Ordnername, Anzeigetext und Icon gemeinsam gepflegt werden.
|
|
|
|
Der Preis: Das Hinzufügen eines Typs erfordert eine Codeänderung und ein Release. Angesichts der erwarteten Änderungshäufigkeit ist das vertretbar.
|
|
|
|
\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 in Filestash von Hand angelegten Ordner \texttt{Sonstiges}.
|
|
|
|
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.
|
|
|
|
\subsection{Übersetzung der Anzeigenamen}
|
|
|
|
Die Ordnernamen im Speicher dienen zwei Zielgruppen: Für die Kundenbetreuer in Filestash müssen sie lesbar und eindeutig sein, für den Kunden in Houston sollen sie sich in die Oberfläche einfügen.
|
|
|
|
Der Ordnername wird nicht unverändert angezeigt, sondern über eine Ressourcendatei auf einen Anzeigetext abgebildet. Dies entspricht dem in Houston etablierten Lokalisierungsmuster und erlaubt Änderungen am Anzeigetext, ohne die Speicherstruktur anzufassen — eine Umbenennung dort würde das Umkopieren sämtlicher betroffenen Objekte erfordern.
|