Textreduktion

This commit is contained in:
2026-09-07 23:37:09 +02:00
parent 3ecc28ef73
commit 235b471ad9
39 changed files with 205 additions and 553 deletions
+2 -11
View File
@@ -1,15 +1,6 @@
\section{Ausgangssituation}
\label{sec:initial-situation}
Die Idee besteht seit November 2023: \emph{Nicole Kimmel} legte damals das Feature~484 „Dokumente" mit zwei Stichpunkten an — „Vertrag, Betriebshandbuch, Feinkonzepte an zentraler Stelle abgelegt" und „Rechnungen einsehbar". Diese Notiz blieb über zweieinhalb Jahre unverändert im Backlog, ohne einen konkreten Lösungsansatz zu beschreiben.
Die Idee besteht seit November 2023: \emph{Nicole Kimmel} legte damals das Feature~484 „Dokumente" mit zwei Stichpunkten an, ohne einen Lösungsansatz zu beschreiben.
Zum Projektbeginn im Sommer 2026 wurden Verträge, Berichte und ähnliche Unterlagen punktuell per E-Mail oder Dateiablage bereitgestellt. Daraus ergaben sich mehrere Probleme:
\begin{itemize}
\item \textbf{Fehlende Zentralisierung:} Dokumente lagen verteilt in E-Mails, Dateiablagen und lokalen Verzeichnissen ohne einheitlichen Zugangspunkt.
\item \textbf{Kein Self-Service für Kunden:} Kunden mussten Dokumente aktiv anfordern, anstatt sie eigenständig abrufen zu können.
\item \textbf{Kein strukturierter Überblick:} Eine Übersicht nach Dokumententypen oder zeitlichem Verlauf war nicht vorhanden.
\item \textbf{Kein sicherer, mandantengetrennter Zugriff:} Es existierte kein technischer Mechanismus, der sicherstellte, dass ein Kunde ausschließlich seine eigenen Dokumente einsehen konnte.
\end{itemize}
Auf technischer Seite war kein S3-Speicher provisioniert. Die Bereitstellung der notwendigen Infrastruktur — drei S3-Buckets (DEV, TEST, PROD) bei Advanced Unibyte auf Basis von NetApp StorageGRID — musste erst im Projektverlauf beantragt werden.
Zum Projektbeginn im Sommer 2026 wurden Verträge, Berichte und ähnliche Unterlagen punktuell per E-Mail oder Dateiablage bereitgestellt. Sie lagen ohne einheitlichen Zugangspunkt verteilt, mussten von Kunden aktiv angefordert werden und boten weder einen Überblick nach Dokumententyp noch einen technisch mandantengetrennten Zugriff. Zudem war kein S3-Speicher provisioniert; die Infrastruktur — drei Buckets (DEV, TEST, PROD) bei Advanced Unibyte auf Basis von NetApp StorageGRID — musste erst im Projektverlauf beantragt werden.
+2 -4
View File
@@ -3,11 +3,9 @@
Als \textbf{Praktikant und Entwickler} (\emph{Linus Nagel}) war ich für Anforderungsklärung, Konzeption, Implementierung aller Product Backlog Items, Akzeptanzkriterien und Dokumentation verantwortlich.
\emph{Sarah Hinzmann} übernahm die \textbf{betriebliche Betreuung}, koordinierte Abstimmungen und war an Code-Reviews der Abschlussphase beteiligt. \emph{Thomas Drewermann} fungierte als \textbf{Product Owner}: Er arbeitete das Feature~484 im Juni 2026 aus, definierte den Umfang und beantwortete Rückfragen.
\emph{Sarah Hinzmann} übernahm die \textbf{betriebliche Betreuung}, koordinierte Abstimmungen und war an Code-Reviews der Abschlussphase beteiligt. \emph{Thomas Drewermann} war \textbf{Product Owner}: Er arbeitete Feature~484 im Juni 2026 aus, definierte den Umfang und beantwortete Rückfragen.
Die \textbf{technische Qualitätssicherung} lag beim Team der Unicorn Development: \emph{Timo Walter} (Code-Reviews der frühen PRs, Architektur-Rückfragen), \emph{Robin Noack} (Reviews der Schlussphase), \emph{Hanna Ebner} (Reviews sowie Entscheidungen zur Oberfläche, Clickdummy der Typfilterung). \emph{Maria-Lena Andersz} führte die \textbf{Abnahmetests} durch.
Weitere Beteiligte: \emph{Stephan Janßen} (Schätzung, Backlog-Pflege), \emph{Christiana Sobik} (Backlog-Pflege), \emph{Bianco Veigel} (Sprint-Planung), \emph{Nicole Kimmel} (ursprüngliche Anforderung, 2023).
Die \textbf{technische Qualitätssicherung} lag beim Team der Unicorn Development: \emph{Timo Walter} (Code-Reviews der frühen PRs, Architektur-Rückfragen), \emph{Robin Noack} (Reviews der Schlussphase) und \emph{Hanna Ebner} (Reviews, Oberflächenentscheidungen, Clickdummy der Typfilterung). \emph{Maria-Lena Andersz} führte die \textbf{Abnahmetests} durch. Weitere Beteiligte: \emph{Stephan Janßen} (Schätzung, Backlog-Pflege), \emph{Christiana Sobik} (Backlog-Pflege), \emph{Bianco Veigel} (Sprint-Planung) und \emph{Nicole Kimmel} (ursprüngliche Anforderung, 2023).
\begin{table}[H]
\centering
+3 -3
View File
@@ -1,8 +1,8 @@
\section{Projektbeschreibung}
\label{sec:project-description}
Das Projekt \emph{Houston Dokumente} stellt Kunden im Kundenportal Houston einen zentralen Bereich bereit, in dem sie ihre Dokumente einsehen und herunterladen können. Die Dokumente werden in einem S3-Speicher abgelegt; Mitarbeiter pflegen sie über das interne Dateiverwaltungswerkzeug Filestash, Kunden rufen sie über eine neue Houston-Seite strukturiert ab.
Das Projekt \emph{Houston Dokumente} stellt Kunden im Kundenportal Houston einen zentralen Bereich bereit, in dem sie ihre Dokumente einsehen und herunterladen können. Die Dokumente liegen in einem S3-Speicher; Mitarbeiter pflegen sie über das interne Werkzeug Filestash, Kunden rufen sie über eine neue Houston-Seite strukturiert ab.
Der Dokumentenbereich unterscheidet sieben fachlich definierte Dokumententypen — darunter Service-Protokolle, SLA-Reports, Monitoring Reports und Vertragsunterlagen. Weitere Funktionen sind Suche, Typfilter, Paginierung, PDF-Viewer, Einzel- und ZIP-Download sowie URL-Dateien, mit denen beliebige Webadressen in der Dokumentenliste verknüpft werden können.
Der Dokumentenbereich unterscheidet sieben fachlich definierte Dokumententypen — darunter Service-Protokolle, SLA-Reports, Monitoring Reports und Vertragsunterlagen — und bietet Suche, Typfilter, Paginierung, PDF-Viewer, Einzel- und ZIP-Download sowie URL-Dateien (siehe Abschnitt~\ref{sec:target-situation}).
Technisch umfasst das Projekt die Anbindung an den S3-Speicher über das AWS SDK für .NET, ein rollenbasiertes Berechtigungskonzept über Microsoft Entra~ID sowie die automatische Anlage der Ordnerstruktur beim ersten Seitenaufruf. Schreibzugriffe durch Kunden sind nicht vorgesehen; dies bleibt Aufgabe der internen Mitarbeiter.
Technisch umfasst das Projekt die S3-Anbindung über das AWS SDK für .NET, ein rollenbasiertes Berechtigungskonzept über Microsoft Entra~ID sowie die automatische Ordneranlage beim ersten Seitenaufruf. Schreibzugriffe durch Kunden sind nicht vorgesehen.
+4 -4
View File
@@ -4,8 +4,8 @@
Folgende Punkte sind explizit \emph{nicht} Bestandteil des Projekts:
\begin{itemize}
\item \textbf{Kein Schreibzugriff für Kunden:} Kunden können Dokumente ausschließlich einsehen und herunterladen.
\item \textbf{Kein internes Upload-UI in Houston:} Die Dokumentenverwaltung durch Mitarbeiter erfolgt ausschließlich über Filestash.
\item \textbf{Keine freie Ordnerstruktur intern:} Nur die sieben definierten Typordner sind für Kunden sichtbar; weitere Ordner werden ignoriert.
\item \textbf{Keine Dashboard-Kacheln im PidI-Umfang:} Geplante Erweiterungen wie Dashboard-Kacheln für Tenant-Härtung aus Security-Assessment-Metadaten oder eine Anzeige zuletzt hinzugefügter Dokumente sind als Feature-Creep im Backlog erfasst, aber nicht Teil des PidI-Projekts.
\item \textbf{Kein Schreibzugriff für Kunden:} Kunden können Dokumente nur einsehen und herunterladen.
\item \textbf{Kein internes Upload-UI in Houston:} Die Pflege durch Mitarbeiter erfolgt ausschließlich über Filestash.
\item \textbf{Keine freie Ordnerstruktur intern:} Für Kunden sind nur die sieben Typordner sichtbar; weitere Ordner werden ignoriert.
\item \textbf{Keine Dashboard-Kacheln im PidI-Umfang:} Erweiterungen wie Dashboard-Kacheln für Tenant-Härtung oder eine Anzeige zuletzt hinzugefügter Dokumente sind als Feature-Creep im Backlog erfasst, aber nicht Teil des PidI-Projekts.
\end{itemize}
+5 -5
View File
@@ -10,12 +10,12 @@ Abbildung~\ref{fig:system-context} zeigt den Systemkontext des Dokumentenbereich
\label{fig:system-context}
\end{figure}
\textbf{Houston} ist das Kundenportal von WorkSimple, implementiert als ASP.NET-Core-Webanwendung mit Razor Pages. Es wurde im Rahmen dieses Projekts um den Dokumentenbereich erweitert.
\textbf{Houston} ist das Kundenportal von WorkSimple, eine ASP.NET-Core-Webanwendung mit Razor Pages, die um den Dokumentenbereich erweitert wurde.
\textbf{Efecte} ist das ITSM-Tool des Unternehmens und liefert die eindeutige Organisations-ID jedes Kunden (\texttt{efecte-org-id}), die als Autorisierungsmerkmal für den S3-Kundenordner dient.
\textbf{Efecte} ist das ITSM-Tool des Unternehmens und liefert die eindeutige Organisations-ID jedes Kunden (\texttt{efecte-org-id}) als Autorisierungsmerkmal für den S3-Kundenordner.
\textbf{Microsoft Entra~ID} (ehemals Azure~AD) übernimmt Authentifizierung und Autorisierung. Das Token enthält die Efecte-Organisations-ID und die Anwendungsrollen; die Rolle \texttt{Documents.Read} steuert den Zugriff auf den Dokumentenbereich.
\textbf{Microsoft Entra~ID} (ehemals Azure~AD) übernimmt Authentifizierung und Autorisierung; das Token enthält die Efecte-Organisations-ID und die Anwendungsrollen, wobei \texttt{Documents.Read} den Zugriff steuert.
\textbf{S3-Speicher (NetApp StorageGRID)} ist die von Advanced Unibyte betriebene, S3-kompatible Ablage für Kundendokumente. Houston greift über das AWS SDK für .NET darauf zu. Jeder Kunde erhält einen eigenen Ordner, identifiziert über ein S3-Metadatum (\texttt{efecte-org-id}).
\textbf{S3-Speicher (NetApp StorageGRID)} ist die von Advanced Unibyte betriebene, S3-kompatible Ablage für Kundendokumente, auf die Houston über das AWS SDK für .NET zugreift; jeder Kunde erhält einen eigenen, über \texttt{efecte-org-id} identifizierten Ordner.
\textbf{Filestash} ist ein webbasierter S3-Browser, den WorkSimple-Mitarbeiter intern zum Hochladen und Verwalten von Dokumenten nutzen.
\textbf{Filestash} ist ein webbasierter S3-Browser für die interne Dokumentenpflege.
+2 -14
View File
@@ -1,18 +1,6 @@
\section{Zielsituation}
\label{sec:target-situation}
Der Dokumentenbereich bietet folgende Funktionen:
Der Dokumentenbereich stellt auf \texttt{/documents} alle Dokumente des Kunden als Liste dar, gegliedert nach sieben Dokumententypen; leere Ordner erscheinen nicht. Er bietet Typfilter und serverseitige Titelsuche, Paginierung, Einzel- und ZIP-Download, eine PDF-Vorschau im modalen Viewer sowie zeitlich begrenzte Share-Link-Previews. \texttt{.url}-Dateien verlinken beliebige Webadressen — etwa Teams-Kanäle oder SharePoint-Seiten — in der Dokumentenliste.
\begin{itemize}
\item \textbf{Document Explorer:} Auf \texttt{/documents} werden alle Dokumente des Kunden als Liste dargestellt, gegliedert nach sieben Dokumententypen. Leere Ordner werden nicht angezeigt.
\item \textbf{Typfilter und Suche:} Filterung nach Typ und titelbasierte serverseitige Suche.
\item \textbf{Paginierung:} Seitenweise Darstellung großer Dokumentenmengen.
\item \textbf{Downloads:} Einzeldownload sowie ZIP-Download mehrerer ausgewählter Dokumente.
\item \textbf{PDF-Vorschau:} Anzeige von PDF-Dokumenten in einem modalen Viewer.
\item \textbf{Share-Link-Previews:} Erzeugung zeitlich begrenzter Freigabelinks.
\item \textbf{URL-Dateien:} Spezielle \texttt{.url}-Dateien ermöglichen die Verlinkung beliebiger Webadressen — z.\,B. Teams-Kanäle oder SharePoint-Seiten — in der Dokumentenliste.
\item \textbf{Mandantentrennung:} Jeder Kunde sieht ausschließlich die Dokumente in seinem eigenen S3-Ordner, der über die \texttt{efecte-org-id} aus dem Authentifizierungstoken identifiziert wird.
\item \textbf{Automatische Ordneranlage:} Beim ersten Aufruf der Dokumentenseite wird die vollständige Ordnerstruktur für den Kunden im S3 angelegt, sofern sie noch nicht existiert.
\end{itemize}
Kunden haben ausschließlich lesenden Zugriff; die Pflege erfolgt durch Mitarbeiter über Filestash.
Die Mandantentrennung stellt sicher, dass jeder Kunde nur die Dokumente seines eigenen S3-Ordners sieht, identifiziert über die \texttt{efecte-org-id} aus dem Authentifizierungstoken; die Ordnerstruktur wird beim ersten Aufruf automatisch angelegt, sofern sie fehlt. Kunden haben ausschließlich lesenden Zugriff; die Pflege erfolgt durch Mitarbeiter über Filestash.