50 lines
4.3 KiB
TeX
50 lines
4.3 KiB
TeX
\section{Dokumententypen und Icons}
|
|
\label{sec:document-types}
|
|
|
|
\subsection{Der Typenkatalog}
|
|
|
|
Die sieben Dokumententypen wurden fachlich in der Feature-Beschreibung festgelegt und im Projektverlauf nicht verändert. Sie bilden die Kategorien ab, in denen WorkSimple gegenüber Kunden regelmäßig Unterlagen bereitstellt. 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 und ob im Betrieb weitere Typen hinzukommen können. Die Entscheidung fiel auf eine feste Kodierung in Houston. Dafür sprechen mehrere Überlegungen.
|
|
|
|
Der Typenkatalog ist fachlich stabil. Er leitet sich aus den Leistungen ab, die WorkSimple erbringt, und ändert sich allenfalls im Rhythmus von Jahren. Eine Konfigurierbarkeit würde für diesen Änderungsrhythmus eine Verwaltungsoberfläche, ein Speicherformat und eine Migrationsstrategie erfordern — ein Aufwand, der in keinem Verhältnis zum Nutzen steht.
|
|
|
|
Hinzu kommt, dass die Typen nicht nur als Beschriftung auftreten. Jeder Typ benötigt ein Icon und eine Übersetzung, und beide müssten bei einem frei konfigurierbaren Katalog ebenfalls hinterlegbar sein. Ein neuer Typ ohne Icon fiele in der Oberfläche unangenehm auf. Die feste Kodierung stellt sicher, dass Ordnername, Anzeigetext und Icon stets gemeinsam gepflegt werden.
|
|
|
|
Der Preis dieser Entscheidung ist, dass das Hinzufügen eines Typs eine Codeänderung und ein Release erfordert. Angesichts der erwarteten Änderungshäufigkeit ist das vertretbar.
|
|
|
|
\subsection{Verhalten bei unbekannten Ordnern}
|
|
|
|
Aus der festen Kodierung ergibt sich unmittelbar die Frage, wie mit Unterordnern umzugehen ist, die nicht im Katalog stehen. Ein Kundenbetreuer könnte in Filestash versehentlich einen Ordner \texttt{Sonstiges} anlegen oder sich beim Namen vertippen.
|
|
|
|
Das Konzept sieht vor, dass Dokumente in solchen Ordnern nicht verschwinden. Sie werden angezeigt und erhalten ein neutrales Standard-Icon; lediglich die Typzuordnung entfällt. Die Alternative — solche Dokumente auszublenden — wurde verworfen, weil sie ein stilles Fehlverhalten erzeugen würde: Ein hochgeladenes Dokument wäre für den Kunden unsichtbar, ohne dass dies für den Betreuer erkennbar wäre.
|
|
|
|
Zu unterscheiden ist dieser Fall vom Umgang mit unbekannten Ordnern auf der \emph{obersten} Ebene. Dort führt ein fehlendes Marker-Metadatum zum vollständigen Ausschluss (siehe Abschnitt~\ref{sec:s3-layout}). Der Unterschied ist beabsichtigt: Auf oberster Ebene entscheidet die Struktur über die Mandantentrennung, hier gilt im Zweifel Ausschluss. Innerhalb eines Kundenordners ist die Zugehörigkeit dagegen bereits geklärt, und ein unbekannter Unterordner ist lediglich ein Darstellungsproblem.
|
|
|
|
\subsection{Übersetzung der Anzeigenamen}
|
|
|
|
Die Ordnernamen im Speicher dienen zwei verschiedenen Zielgruppen. Für die Kundenbetreuer, die in Filestash arbeiten, müssen sie lesbar und eindeutig sein. Für den Kunden in Houston sollen sie sich in die Oberfläche einfügen.
|
|
|
|
Aus diesem Grund wird der Ordnername nicht unverändert angezeigt, sondern über eine Ressourcendatei auf einen Anzeigetext abgebildet. Dieses Vorgehen entspricht dem in Houston bereits etablierten Muster zur Lokalisierung und erlaubt es, den Anzeigetext zu ändern, ohne die Struktur im Speicher anzufassen — eine Umbenennung dort würde bedeuten, sämtliche betroffenen Objekte umzukopieren.
|