# ProjectSpace – eigenständiges Projekt für SharePoint und Teams


## Bestehende Projekte und Berechtigungsänderungen

Der Mockup enthält einen fiktiven Bestand aus drei Projekten, unabhängig von noch nicht bereitgestellten Neuanträgen. Suche nach Name, Kennung oder Verantwortlichem sowie Status- und Partnerfilter grenzen die Liste ein. Je Projekt zeigt eine Tabelle Verantwortlichen, interne Mitglieder und externe Teilnehmer mit Ressource, Rechten, Teams-Zugriff und Zugriffsdauer. Diese Tabelle stellt das konfigurierte Demomodell dar und behauptet keine Abfrage effektiver Tenantrechte, geerbter Gruppenmitgliedschaften oder zusätzlicher Freigabelinks.

Bei aktiven Projekten können Verantwortlicher und interne Mitglieder über eine separate Mitarbeitersuche sowie Partner, einzelner Partnerordner, Lesen/Bearbeiten und befristeter/dauerhafter Zugriff angepasst werden. Eine Begründung ist erforderlich. Der Prüfdialog zeigt die Unterschiede zwischen bisherigem und gewünschtem Zustand. Ordnerwechsel und Abschalten des Partnerzugriffs nennen den Entzug der bisherigen Freigabe ausdrücklich. Erst „Im Mockup übernehmen“ verändert den lokalen Demobestand, erhöht den Revisionsstand und ergänzt den Änderungsverlauf. Diese Aktion simuliert ein genehmigtes Ergebnis und erteilt keine echte Genehmigung. Abbruch und unveränderte Eingaben verändern den Bestand nicht. Archivierte Projekte sind für Änderungen gesperrt; zwischenzeitlich geänderte Revisionen verhindern das Überschreiben. Änderungen bleiben nur bis zum Neuladen erhalten.

Für die produktive Umsetzung benötigt die API eine gesonderte, projektbezogene Änderungsberechtigung, aktuelle Identitäts- und Rollenprüfung sowie einen versionierten Änderungsantrag. Genehmigte Sollrechte und tatsächlich vorhandene Rechte getrennt erfassen. Entzug des alten Partnerordners muss beim Ordnerwechsel vor Vergabe des neuen Zugriffs erfolgen und geprüft werden; bei Teilfehlern keinen zusätzlichen zweiten Ordnerzugriff freigeben. Ablauf-/Widerrufsaufträge entsprechend aktualisieren. Direkte Rechte, Freigabelinks und anderweitige Gruppenmitgliedschaften müssen in der effektiven Rechteprüfung berücksichtigt werden. Der Demo-Verlauf ist kein manipulationssicheres Auditprotokoll.

Zusätzliche Tests prüfen Filter, exakte Partnerreichweite, Änderungsvorschau, Widerruf, Mitarbeiterübergabe, Abbruch, doppelte Übernahme, Begründung, Revisionenkonflikte, Archivsperre und unveränderte Ergebnis-Snapshots.

Konzeptentwurf, aktualisiert am 11. November 2026. Annahme: Microsoft 365 / SharePoint Online. Kein beschlossener Architekturstand und keine installierte Tenant-Lösung. Fachliche Rollen, Richtlinien und Lizenzen sind mit dem Auftraggeber festzulegen.

## Ziel und Umfang

Berechtigte interne Mitarbeiter beantragen einen Projektarbeitsraum aus einer versionierten Vorlage. Das System leitet Ordner, Teams-Kanäle, interne Rollen, externe Zugriffe und Freigabeschritte ab. Nach erforderlichen Genehmigungen stellt ein Dienst die Ressourcen bereit. Personen erhalten ausschließlich die für ihren Bereich vorgesehene Mitgliedschaft. Ablauf und Änderungen bleiben nachvollziehbar.

Dies ist ein eigenes Thema mit eigenem Lebenszyklus. Erkenntnisse aus OneStructure dürfen übernommen werden, insbesondere das lokale SPFx-/SharePoint-Muster und die Erfahrung mit Custom-Script-Sperren. Es besteht keine Laufzeit- oder Datenabhängigkeit zu OneStructure. Die bestehende Anwendung wurde nicht verändert. Im untersuchten Arbeitsordner wurde kein Git-Repository festgestellt; dies ist ein lokaler Entwurf.

## Oberfläche: ASPX für SharePoint und Teams

Empfehlung: eigenes SPFx-Webpart auf einer modernen SharePoint-Seite `SitePages/projekte.aspx`. Dasselbe Webpart als Teams-Tab oder persönliche Teams-App anbieten. `supportedHosts` entsprechend mit `SharePointWebPart`, `SharePointFullPage`, `TeamsTab` und optional `TeamsPersonalApp` konfigurieren. App-Catalog- und Teams-App-Freigaben gehören zur Installation.

Die ASPX-Adresse ist der SharePoint-Seitenhost. Beliebiger serverseitiger ASP.NET-Code lässt sich dort nicht hochladen und ausführen. Eine eigenständige ASPX-Datei mit eingebettetem JavaScript ist wegen Custom-Script-/Baseline-Richtlinien keine tragfähige Standardinstallation. Die Erweiterungslogik gehört in SPFx; privilegierte Bereitstellung in einen authentifizierten Dienst. Der vorliegende HTML-Mockup ist keine installierbare SharePoint-Seite und kein fertiges SPFx-Paket.

Quellen: [SPFx in Teams](https://learn.microsoft.com/en-us/sharepoint/dev/spfx/build-for-teams-expose-webparts-teams), [App-Seiten](https://learn.microsoft.com/en-us/sharepoint/dev/spfx/web-parts/single-part-app-pages), [Custom-Script-Regeln](https://learn.microsoft.com/en-us/sharepoint/allow-or-prevent-custom-script).

## Ablauf und automatische Entscheidungen

1. API prüft die Entra-Identität und die Rolle Projektinitiator. Projektkennung, Vorlage, Verantwortliche und Organisationsbereich werden serverseitig validiert.
2. Antrag enthält einen Snapshot der Vorlagenversion, gewünschten Mitglieder, Bereiche und Schutzklasse. Namen und Ziel-URLs werden normalisiert; Kollisionen werden geprüft.
3. Eine versionierte Richtlinie berechnet das Berechtigungs- und Genehmigungsmodell. Vorschlag für den Start: interne Projekte benötigen fachliche Freigabe; externe Zusammenarbeit zusätzlich die Freigabe eines autorisierten Externe-Freigebers. Vertrauliche Projekte erlauben zunächst keine Externen. Antragsteller dürfen den eigenen Antrag nicht genehmigen. Änderungen nach Freigabe erzeugen eine neue Version und erneute Prüfung.
4. Erst ein vollständig genehmigter Auftrag gelangt in die Warteschlange. Ein Dienst legt das interne private Team samt verbundener Site oder eine reine SharePoint-Projektsite an. Teams erstellt seine verbundene Site; keine zweite gleichnamige Site vorab erzeugen.
5. Es werden ausschließlich Standardkanäle angelegt; private und freigegebene Kanäle sind ausgeschlossen. Nach abgeschlossener asynchroner Bereitstellung werden Kanäle und die tatsächlichen Kanal-Dateiablagen aufgelöst. Ordner werden anhand ihrer vorgesehenen Zielbibliothek oder Kanalablage angelegt, nicht anhand angenommener URLs.
6. Der Dienst weist die ausgewählten internen Mitarbeiter anhand ihrer Entra-Objekt-IDs zu. Für Partner wird genau ein vorhandener Ordner in der Projektbibliothek einschließlich seiner Inhalte freigegeben; es entstehen keine zusätzlichen Sites oder Teams. Der Dienst prüft die konkreten Ordnerberechtigungen und verhindert breite Mitgliedschaften. Externe erhalten erst nach erfolgreicher Rechteprüfung Zugang. Einladungen und Benachrichtigungen sind explizite Produktionsfunktionen; der Mockup versendet nichts.
7. Ergebnis zeigt Links, angewendete Vorlage, Verantwortliche, Freigaben und Status. Bei Teilfehlern bleiben kontrollierte Wiederaufnahme und administrativer Klärungsbedarf sichtbar.

Optional später: Standardprojekte ohne externe Beteiligung automatisch genehmigen, wenn eine explizite Unternehmensrichtlinie dies gestattet. Automatische Regelermittlung und menschliche Genehmigung sind unterschiedliche Schritte.

## Rollen und Ausführungsberechtigung

| Rolle | Rechte |
|---|---|
| Projektinitiator | Eigene Anträge erstellen und lesen; keine Rechtevergabe oder Bereitstellung |
| Projektverantwortlicher | Eigene Projekte verwalten; fremde zugewiesene Anträge fachlich genehmigen |
| Externe-Freigeber | Externe Zugriffe im zugewiesenen Organisationsbereich genehmigen; keine Selbstgenehmigung |
| Vorlagenverwalter | Vorlagenentwürfe pflegen; Veröffentlichung mit separater Freigabe |
| Betriebsadministrator | Fehler diagnostizieren und genehmigte Aufträge erneut starten; keine verdeckte Umgehung der Fachfreigabe |
| Bereitstellungsdienst | Ausschließlich genehmigte, gültige Aufträge technisch ausführen |
| Projektmitglied | Im zugewiesenen internen Projektbereich bearbeiten |
| Partner | Ausschließlich ein ausgewählter SharePoint-Ordner einschließlich seiner Inhalte; Lesen oder Bearbeiten, befristet oder dauerhaft bis zum Widerruf |

Anwendungsrollen werden über Entra-App-Rollen und zugeordnete Sicherheitsgruppen vergeben. Die API prüft zusätzlich Projektzuordnung und Organisationsbereich. UI-Sichtbarkeit ist keine Autorisierung. Projektbesitzer können technisch zusätzliche Freigaben vornehmen; falls dies organisatorisch ausgeschlossen werden soll, muss das Eigentümer-/Sharing-Modell entsprechend eingeschränkt und überwacht werden. Eine Anwendung allein verhindert keine Änderungen durch privilegierte Tenantadministratoren.

## Interne Mitarbeiter suchen und auswählen

Verantwortliche und Projektmitglieder werden nach Name oder Abteilung im Mitarbeiterverzeichnis gesucht und ausdrücklich ausgewählt. Freie E-Mail-Eingaben werden für interne Mitarbeiter nicht akzeptiert. Die Oberfläche zeigt Namen und Abteilung sowie bei Bedarf ein geeignetes Unterscheidungsmerkmal für Namensgleichheit. Der Antrag speichert stabile Entra-Objekt-IDs statt Namen als Identität; Namensänderungen dürfen keine neue Person erzeugen. Suchtext ohne Auswahl wird nicht als Mitglied übernommen.

Im Produkt kommt die Suche aus einem authentifizierten, begrenzten Verzeichnisendpunkt auf Basis von Microsoft Graph oder einem geeigneten People Picker. Die API validiert ausgewählte Konten erneut bei Antrag und Ausführung: aktiv, organisatorisch als interner Mitarbeiter zulässig, keine Gast- oder technischen Konten. `userType=Member` allein ist kein ausreichender Mitarbeiterbeleg; die zulässigen Mitarbeitergruppen bzw. Attribute sind festzulegen. Suchergebnisse sind begrenzt, paginiert und bei Bedarf verzögert anzufragen. Keine vollständigen Mitarbeiterlisten an unberechtigte Nutzer ausliefern. Rechte anhand der tatsächlich angefragten Attribute bestimmen.

Der Mockup verwendet ein fiktives lokales Verzeichnis. Namens- und Abteilungssuche, Auswählen und Entfernen, Unterscheidung gleicher Namen sowie Ausschluss inaktiver und externer Beispielkonten sind enthalten. Die echte Entra-Anbindung ist noch nicht umgesetzt.

Quelle: [Benutzer über Microsoft Graph auflisten](https://learn.microsoft.com/en-us/graph/api/user-list?view=graph-rest-1.0).

## Interne und externe Zugriffe

Verbindlicher Entwurf nach Nutzerkorrektur: Partner erhalten ausschließlich genau einen ausgewählten Ordner der SharePoint-Projektbibliothek einschließlich dessen Unterordnern und Dateien. Keine Partnersite und kein Partnerteam. Teams verwendet ausschließlich Standardkanäle für die internen Mitarbeiter; keine privaten oder freigegebenen Kanäle.

| Ressource | Intern | Extern |
|---|---|---|
| Projektteam und Standardkanäle | Ausgewählte interne Mitglieder und Verantwortliche | Keine Mitgliedschaft |
| Projektbibliothek und übrige Ordner | Gemäß internen Projektrollen | Kein allgemeiner Zugriff |
| Genau ein Partnerordner | Bestehende interne Projektrollen bleiben wirksam | Explizit benannte Partner: Lesen oder Bearbeiten |
| Übergeordnete Site/Bibliothek | Gemäß internen Projektrollen | Nur technisch erforderlicher Limited Access für den freigegebenen Ordner |

Der Antrag speichert eine einzelne Ordnerreferenz, Zugriffsart und Zugriffsdauer. Im Mockup ist die Referenz ein Name innerhalb der aktuellen Vorlage; im Produkt müssen nach Bereitstellung Site-, Drive-/Listen- und Item-ID aufgelöst und gespeichert werden. Keine willkürlichen Zielpfade vom Browser übernehmen. Wird der gewählte Ordner durch einen Vorlagenwechsel entfernt, muss der Antragsteller erneut auswählen. Alle benannten Partner eines Antrags erhalten dieselbe Ordnerfreigabe; unterschiedlich berechtigte Partnergruppen wären eine spätere, gesonderte Erweiterung.

Der Dienst vergibt ausschließlich ordnerbezogene Rechte bzw. eine authentifizierte Freigabe für bestimmte Personen. Er darf Partner nicht zu Team-, Microsoft-365-Gruppen-, Site-Mitglieder- oder Site-Besuchergruppen hinzufügen. Bestehende interne Rechte erhalten; wenn zur Umsetzung eine eigene ACL erforderlich ist, nur am ausgewählten Ordner und unter Beibehaltung der notwendigen internen Berechtigungen. Unterelemente erben die vorgesehene Freigabe; bestehende individuelle Unterelementrechte müssen erkannt werden. Kein pauschales Zurücksetzen vorhandener ACLs. Kein anonymer Link und keine allgemeine Bibliotheksfreigabe.

SharePoint kann automatisch Limited Access auf übergeordneten Ressourcen vergeben. Dies ermöglicht den technischen Weg zum freigegebenen Ordner und gewährt keine Leserechte auf andere Projektinhalte. Effektiver Zugriff ist mit Partner-Testidentitäten auf Ordner, Geschwisterordner und direkte Datei-URLs zu prüfen. Vorhandene anderweitige Mitgliedschaften und Freigabelinks dürfen die Einschränkung nicht aushebeln; bei solchen Konflikten muss der Dienst den Antrag zur Klärung blockieren.

Quellen: [Berechtigungsstufen und Limited Access](https://learn.microsoft.com/en-us/sharepoint/understanding-permission-levels), [Freigabeoptionen für Dateien und Ordner](https://learn.microsoft.com/en-us/sharepoint/collaboration-options).

### Befristeter und dauerhafter Zugriff

- **Befristet:** Pflichtdatum in der Zukunft. Ein geplanter Dienst entzieht zum festgelegten Ablauf die konkrete Ordnerfreigabe und überprüft deren effektiven Entzug.
- **Dauerhaft:** Kein Ablaufdatum. Die Freigabe gilt bis zum ausdrücklichen Widerruf. Der Freigabeantrag und die Auftragsansicht nennen diese Option ausdrücklich; auch dauerhafter Zugriff braucht die vorgesehene externe Genehmigung.

Dauerhafte Freigabe bedeutet keinen Verzicht auf Widerruf oder regelmäßige Prüfung. Tenant-, Site-, Entra- und sonstige Sicherheitsrichtlinien bleiben maßgeblich; vorgeschriebene Gastabläufe oder erneute Authentifizierung werden nicht durch die Anwendung übersteuert. Gastkonten nicht pauschal löschen, weil sie andere Projekte nutzen können. Bei Änderung von dauerhaft auf befristet muss ein gültiges Ablaufdatum gesetzt werden; umgekehrt darf kein verstecktes altes Datum als aktiver Ablauf übernommen werden. Die genaue Zeitzone und Uhrzeit des automatischen Entzugs sind für die produktive Umsetzung festzulegen.

Tenant-, Site-, Gruppen- und Teams-Richtlinien müssen den jeweils vorgesehenen Zugriff erlauben. Zulässige Partnerdomänen, MFA/Conditional Access und Sensitivity Labels richten sich nach Unternehmensvorgabe. Der Ordnerlink ist der Einstieg für Partner; die interne Projektanwendung wird ihnen dadurch nicht zusätzlich freigegeben.

## Flexible Vorlagen

Vorlagen enthalten stabile ID, Version, Freigabestatus, Schutzklassen, erlaubte Zusammenarbeitsmodelle, Kanaldefinitionen, Zielbibliotheken, Ordnerbäume, Rollenbindungen und Genehmigungsregeln. Ordnerknoten referenzieren eine Bibliotheks- oder Kanal-ID; ihr Name ist kein Berechtigungsschlüssel. Der Mockup zeigt interne Bibliotheksordner und Kanäle separat; die endgültige Zuordnung ist eine Vorlagenentscheidung.

Standardprojekt: Organisation, Planung, Umsetzung, Dokumentation, Abschluss. Bau & Engineering: Projektsteuerung, Planung, Genehmigungen, Ausführung, Abnahmen, Bestandsunterlagen. IT & Digitalisierung: Anforderungen, Architektur, Entwicklung, Tests, Betrieb. Zusätzlich dürfen berechtigte Antragsteller einfache interne Ordner ergänzen. Partnerzugriff ist eine gezielte Ausnahme von der Ordnervererbung: genau ein ausgewählter Vorlagen- oder Zusatzordner darf extern freigegeben werden. Keine privaten oder freigegebenen Teams-Kanäle und keine zusätzlichen Partnerressourcen erzeugen. Nicht massenhaft Einzeldateirechte vergeben. Existierende Projekte übernehmen Vorlagenänderungen nur nach expliziter Migration und Prüfung, niemals automatisch rückwirkend.

## Technischer Entwurf

SPFx/TypeScript → geschützte API → Antrags-/Freigabespeicher → Warteschlange → Bereitstellungsdienst → Microsoft Graph und nötigenfalls SharePoint REST/PnP. Empfohlener erster Ansatz: Azure Function mit Entra-Authentifizierung und Managed Identity, Queue, dauerhafter Auftragsspeicher und Audit. Die genaue Azure-Auswahl bleibt offen. Power Automate ist eine Alternative für Genehmigungen, wenn Connectoren, Ausführungskonto, Lizenzen und Betriebsverantwortung passen. Dies ist noch keine Deploymententscheidung.

Der Browser darf Anträge abgeben und Status lesen; privilegierte Graph-Rechte bleiben im Dienst. Secrets weder im Webpart noch in Listen ablegen. Aufträge speichern Korrelations-ID, Idempotenzschlüssel, Ressourcen-IDs und jeden abgeschlossenen Schritt. Wiederholungen verwenden vorhandene Ressourcen. HTTP 429 nach Retry-After behandeln, temporäre Fehler mit begrenztem Backoff; Bereitstellung bis zum tatsächlichen Abschluss überwachen. Bei Teilfehlern Ressourcen nicht blind löschen. Freigaben, Antragssnapshot und ausgeführte Rechteänderungen sind getrennt zu protokollieren.

Vorgeschlagene Zustände: Entwurf → Eingereicht → Fachfreigabe → ggf. Externe-Freigabe → Genehmigt → Bereitstellung → Aktiv; zusätzlich Abgelehnt, Teilfehler, Wiederaufnahme, Abgelaufen und Archiviert. Keine Umgehung erforderlicher Freigaben durch Statusänderungen im Browser.

## Technische API-Rechte und Installation

Die endgültige Rechtefreigabe erfolgt nach Festlegung der tatsächlich verwendeten Endpunkte, nicht pauschal mit Global-Admin-Rechten. Vorläufige Kandidaten:

| Operation | Rechtekandidat / Einschränkung |
|---|---|
| Team anlegen | `Team.Create`; Erstellung liefert asynchronen Auftrag |
| Kanal anlegen | `Channel.Create.Group` mit Resource-Specific Consent für das konkrete Team; alternativ begründetes `Channel.Create` für zentralen Dienst |
| Interne Teammitgliedschaften | Endpunktspezifische TeamMember-Schreibrechte; getrennt von Erstellrechten prüfen. Keine externen Team- oder Kanalmitgliedschaften |
| Externe einladen | `User.Invite.All`, nur wenn Einladungen fachlich genehmigt und Tenant-Richtlinien sie erlauben |
| Dokumentablage | Möglichst `Sites.Selected` plus explizite Ressourcenzuweisung und geeignete Rolle |
| Projekt-Sites / Ressourcengrants | Gesonderter administrativer Bootstrap; `Sites.Selected` allein erstellt keine beliebigen neuen Sites und erteilt keine eigenen Grants. Partner erhalten lediglich Ordnerrechte |

RSC setzt App-Installation und Consent im Team voraus und ist deshalb kein automatischer Ersatz für tenantweite Berechtigungen. Bootstrap und laufenden Dienst möglichst trennen. SharePoint-REST-/PnP-Zugriffe benötigen die zum API-Audience passenden Berechtigungen und Tokens. Ausgewählte Site-Rechte verlangen sowohl Consent als auch explizite Ressourcenfreigabe. Der Rechteumfang für Site-Anlage und SharePoint-Berechtigungsverwaltung ist im technischen Pilot gesondert festzulegen; die Tabelle ist keine vollständige ausführbare App-Registrierung.

Quellen: [Team erstellen](https://learn.microsoft.com/en-us/graph/api/team-post?view=graph-rest-1.0), [Kanal erstellen](https://learn.microsoft.com/en-us/graph/api/channel-post?view=graph-rest-1.0), [Einladungen](https://learn.microsoft.com/en-us/graph/api/invitation-post?view=graph-rest-1.0), [Selected Permissions](https://learn.microsoft.com/en-us/graph/permissions-selected-overview).

## Pilot und Abnahmekriterien

Zunächst eine Vorlage und interne Projekte auf einem Testtenant umsetzen. Danach gezielte Freigabe genau eines Projektordners mit Lesen/Bearbeiten testen, sowohl befristet mit tatsächlichem Entzug als auch dauerhaft mit ausdrücklichem Widerruf. Teams ausschließlich mit Standardkanälen prüfen. Keine Partnerressourcen außerhalb des gewählten Ordners erstellen.

Abnahme: Nichtberechtigte erhalten 403 auch beim direkten API-Aufruf. Keine Selbstgenehmigung. Manipulierte oder veraltete Vorlagen werden abgewiesen. Externe sehen keine internen Dateien, auch nicht über direkte URLs. Lesen erlaubt kein Schreiben. Ein Ablauf entzieht tatsächlichen Zugang. Wiederholte Aufträge erzeugen keine Duplikate. Teilfehler und 429 sind wiederaufnehmbar. Prüfung mit echten Testidentitäten für jede Rolle in SharePoint und Teams; Freigabe erst nach protokolliertem Pilot.

Offen: Tenant und Zielsite, zulässige externe Domänen, Freigebergruppen, Vorlagenveröffentlichung, erforderliche Schutzklassen, Namenskonventionen, Aufbewahrung und Archivierung, Lizenzen, Datenregion, bevorzugter Ausführungsdienst und gewünschte Integration in bestehende Projektregister.

## Gelieferter Mockup

`index.html`, `style.css`, `app.js`: lokal im Browser öffnen. Die Anlage führt durch drei Schritte: Projektdetails und interne Mitglieder, Vorlage und zusätzliche Ordner, Zusammenarbeit und Freigabeweg. Die Live-Vorschau bleibt sichtbar. Ein abschließender Dialog zeigt Schutzbedarf, ausgewählte Mitarbeiter, den einzelnen Partnerordner, Standardkanäle, Zugriffsart und ausdrücklich entweder Ablaufdatum oder dauerhaften Zugriff bis zum Widerruf. Erst die Bestätigung erzeugt einen flüchtigen Demo-Antrag. Die Auftragsansicht zeigt ausstehende Freigaben und die nachgelagerte Bereitstellung. Gleiche Projektkennungen werden innerhalb der Sitzung abgewiesen; Abbruch erzeugt keinen Antrag. Alle Daten sind fiktiv; Neuladen entfernt Aufträge. Echte Anmeldung, Genehmigung, Persistenz, Microsoft-365-Aufrufe, SPFx-Verpackung und Tenantinstallation sind nicht enthalten. Clientprüfungen demonstrieren die Bedienung und sind keine Sicherheitsgrenze. Die interne Auswahl verwendet fiktive Verzeichniseinträge mit stabilen Demo-IDs; eine Prüfung gegen Entra ist noch nicht implementiert. Externe Teilnehmer werden weiterhin über E-Mail-Adressen erfasst.

`node flow.test.mjs` prüft 19 Ablaufszenarien mit einer kleinen DOM-Testumgebung. Die Tests decken Navigation, Validierung, Abbruch, einmaliges Vormerken, doppelte Kennungen, Vorlagenwechsel, Mitarbeiterwahl, exakt einen Partnerordner sowie befristeten und dauerhaften Zugriff ab. Sie ersetzen keine Browser-/Layoutprüfung oder Microsoft-365-Integrationstests. Die Browserprüfung des lokalen Dateipfads wurde durch die Browserrichtlinie blockiert.

### Ergebnisvorschau für Teams und SharePoint

Der Menüpunkt „Ergebnisvorschau“ zeigt den aktuellen Entwurf als vereinfachten zukünftigen Arbeitsraum. In der Auftragsansicht öffnet „Ergebnis als Mockup ansehen“ dagegen den gespeicherten Snapshot des jeweiligen Antrags. Spätere Formularänderungen verändern diesen Snapshot nicht. Die Simulation bewirkt weder eine Genehmigung noch eine Bereitstellung.

Teams zeigt Projektname, ausschließlich Standardkanäle und die interne Beteiligtenzahl. Kanäle, Beispielbeitrag, Datei-Leerzustand und Wechsel zur SharePoint-Projektseite sind anklickbar. Ohne Teams-Option erscheint kein Team. SharePoint zeigt eine Startseite mit Projektinformationen, ausgewählten internen Beteiligten und Verknüpfungen zur Dokumentbibliothek. Die Bibliotheksansicht zeigt die Ordner aus Vorlage und Ergänzungen, mit Detailansicht und Kennzeichnung der einzelnen Partnerfreigabe. Standardkanal-Dateiablagen werden als eigene, von Teams verwaltete Ablagen behandelt.

Ein Ansichtswechsel zu „Externer Partner“ simuliert ausschließlich den ausgewählten Ordner samt Zugriffsart und Dauer. Die interne Projektstartseite, andere Ordner und Teams werden in dieser Ansicht nicht angeboten. Dies veranschaulicht den beabsichtigten Zugriff und ersetzt keine echte Autorisierung. Ohne konfigurierte Partnerfreigabe erscheint ein entsprechender Leerzustand.

Die Darstellungen sind keine eingebetteten Microsoft-Anwendungen und kein pixelgetreues Abbild einer bestimmten Microsoft-365-Version. Es werden keine Dokumente oder Nachrichten erstellt. Die vier zusätzlichen Tests prüfen die Ergebnisnavigation, die eingeschränkte Partneransicht, Projekte ohne Teams/Partner sowie die unveränderte Antragskonfiguration.

Die Teams-Vorschau verwendet jetzt einen eigenen, leichtgewichtigen Rahmen nach der lokal geprüften CloudLights-Referenz: Fluent-Symbole mit MIT-Lizenzhinweis, App-Leiste, kanalbezogene Suche, Zurück/Vorwärts, Profilmenü mit Hell-/Dunkelmodus und vergrößerbare Ansicht. Die Projektseite wird als derselbe DOM-Knoten innerhalb des Teams-Tabs bzw. als persönliche Projektanwendung eingebunden; ein geöffneter Ordner bleibt beim Wechsel erhalten. Aktivität und Apps bieten projektbezogene Beispielansichten; Chat, Kalender und Anrufe sind klar gekennzeichnete Leerzustände. Der CloudLights-SPFx-Code wurde nicht als zusätzliche Laufzeitabhängigkeit übernommen. Zusätzliche Tests prüfen den Rahmen, Navigation, Einbettung, Suche und Designumschaltung.