schalli
67b50240d6
Aufgabe 3 — TDD zuerst (7 weitere Faelle in dashboard.service.spec.ts, 20 vorher/27 nach dieser Aufgabe), dann die Umstellung: - getSearchProviders/addSearchProvider/removeSearchProvider laufen ueber forTenant(); removeSearchProvider fuehrt Besitzpruefung UND Schreibzugriff ueber DENSELBEN gebundenen Klienten. Die drei Vorgabe-Suchmaschinen aus der Konstante bleiben unveraendert vorangestellt. - Der eine Katalogzugriff (this.prisma.module in getWidgets) bleibt begruendet ungebunden: Messung und Bedingung getrennt (Tabelle traegt heute keinen Zeilenschutz, wirkungslos statt katastrophal — katastrophal erst, wenn Etappe 3 eine Regel gibt), unter Berufung auf die bestehende Werkzeugpruefung module-tabelle-traegt-keinen-zeilenschutz statt einer neuen Behauptung. Ein Wachhund-Testfall haelt den Katalogzugriff aus dem Bindungsprotokoll heraus (und beweist zuerst, dass der Katalogpfad tatsaechlich durchlaufen wird, nicht nur theoretisch geprueft ist). - docs/mandantentrennung-zugriffsklassifikation.md an allen fuenf handgepflegten Stellen nachgezogen: vier Bestandsaufnahme-Zeilen (inkl. eigenstaendiger Nachpruefung der widerlegten SearchProvider-Praemisse), Uebersichtszeile (13/0 -> 1/12), Summenzeile (95/147), Klassen-Verteilung (unveraendert 63 Paare, ausdruecklich vermerkt), Hintergrunddienst- Abschnitt (dashboard hat keinen sechsten Fall, mit Messanweisung), "Was diese Etappe NICHT entscheidet" (dienst-interner forTenant()-Weg wie alle sieben Bereiche vor ihm). - .planning/WINDOWS.md traegt Eintrag #25 (offen, Tabelle + JSON): die beweisvernichtende Schleife (leeres Dashboard -> Neuaufbau -> automatisches Zurueckschreiben -> ueberschriebene Anordnung, Widget- Dubletten) samt der Vorabpruefung fuer Etappe 4 und dem Verweis auf #22 fuer die verwandte Eindeutigkeitsfrage. Zwei weitere Falsifizierungsnachweise durchgefuehrt: (1) den Katalogzugriff probeweise gebunden (tenantPrisma.module.findMany) — acht Tests werden rot mit "TypeError: Cannot read properties of undefined (reading 'findMany')", weil `module` bewusst nicht in der Testdouble-Bindungsliste steht; Rueckbau zurueckgenommen, 27/27 wieder gruen. (2) den Stand von dashboardLayout in der Klassifikationsdatei probeweise auf "ungebunden" gesetzt — rls-access-inventory.spec.ts wird rot mit "Abweichender Stand (Dokument vs. Quelltext): ... dokumentiert=ungebunden, gemessen=gebunden"; Ruecknahme, Testlauf wieder gruen (10/10). Baseline gehalten: 858 Tests / 56 Dateien gruen, Typpruefung sauber, Wegwerf-Werkzeug 87/87. Schalter bleibt aus.
Tessera — Anleitungen
Tessera ist eine Plattform, auf der verschiedene Arbeitswerkzeuge — genannt Module — an einer Stelle zusammenlaufen. Statt zwischen mehreren Anwendungen zu wechseln, meldet man sich einmal an und findet alles in derselben Oberfläche: ein einstellbares Dashboard, eine Seitenleiste mit den freigeschalteten Modulen und einen Marktplatz, über den weitere hinzukommen.
Diese Sammlung richtet sich an vier verschiedene Leserkreise. Suchen Sie sich den passenden heraus — die Anleitungen überschneiden sich bewusst kaum.
| Anleitung | Für wen | Worum es geht |
|---|---|---|
| Für Anwender | alle, die mit Tessera arbeiten | Anmelden, Dashboard einrichten, Module benutzen |
| Für Administratoren | wer Tessera einrichtet | Benutzer, Gruppen, AD-Anbindung, Freigaben, SMTP |
| Für den Betrieb | wer die Server betreut | Installieren, neue Fassungen einspielen, Sicherungen, Fehlersuche |
| Für Entwickler | wer an Tessera mitbaut | Aufbau, Modulsystem, Berechtigungen, Konventionen |
Daneben liegt das CI/CD-Runbook, das die Einrichtung der Bau-Pipeline in Gitea beschreibt. Es richtet sich an dieselben Leute wie die Betriebsanleitung, deckt aber nur den Weg vom Quelltext zum fertigen Abbild ab.
Ebenfalls dabei: Mandantentrennung auf Datenbankebene, das sich an dieselben Leute wie die Betriebsanleitung richtet und ausschliesslich die Datenbankrolle behandelt, mit der Tessera verbindet (WINDOWS #18).
Die drei Dinge, die am häufigsten Zeit kosten
Wenn Sie nur wenig lesen wollen — diese drei Punkte haben in der Praxis am meisten Verwirrung gestiftet:
1. Die Anmeldung läuft über den Benutzernamen, nicht über die E-Mail-Adresse. Das Feld heißt „Benutzername". Wer stattdessen seine E-Mail-Adresse einträgt, kommt nicht hinein — ohne dass eine hilfreiche Meldung erscheint. Es sieht aus wie ein kaputter Login, ist aber nur das falsche Feld.
2. „Aktiviert" und „freigegeben" sind zwei verschiedene Dinge. Ein Modul wird zuerst für das Unternehmen aktiviert und danach einzelnen Gruppen oder Personen freigegeben. Sehen Sie ein Modul im Marktplatz, aber nicht in Ihrer Seitenleiste, fehlt die zweite Stufe — wenden Sie sich an Ihre Administration. Details in der Administrationsanleitung.
3. Beim Ausrollen genügt docker compose up -d nicht.
Ohne --force-recreate laufen die alten Container weiter, obwohl ein neues
Abbild heruntergeladen wurde — ohne jede Fehlermeldung. Das Einspielen wirkt
erfolgreich, ist es aber nicht. Der genaue Ablauf samt Kontrollbefehl steht in
der Betriebsanleitung.
Zum Stand dieser Anleitungen
Sie wurden gegen den tatsächlichen Quelltext geschrieben, nicht aus der Planung abgeleitet. Beschriftungen von Schaltflächen und Feldern sind wörtlich aus den Sprachdateien der Oberfläche übernommen, damit sie zu dem passen, was auf dem Bildschirm steht.
Zwei Einschränkungen, die Sie kennen sollten:
- Wo eine Aussage sich nicht aus dem Quelltext belegen ließ — etwa eine Einstellung, die von Hand auf dem Server ergänzt wurde — steht ein Hinweis im Text statt einer Vermutung.
- Tessera wird derzeit ausschließlich intern eingesetzt. Die Trennung mehrerer Mandanten ist in der Architektur angelegt, aber nicht Gegenstand dieser Anleitungen.