Commit Graph

4 Commits

Author SHA1 Message Date
Weapie
ae752322f0 Import nicht an der JSON-Ablage scheitern lassen
Im Container lief der Import bis zum Ende der Auswertung und brach dann
mit EACCES beim Schreiben der ersten JSON-Datei ab. Weil die Ablage vor
dem Datenbankschreiben stand, wurde keine einzige Erklärung importiert.

Reihenfolge umgedreht: Erst die Datenbank, danach die JSON-Dateien. Ein
Fehler dabei wird einmal gemeldet und beendet nur die Ablage, nicht den
Lauf. Neu ist --no-json, das sie ganz abschaltet.

Getestet: Normalfall schreibt 120 Dateien, simulierter Schreibfehler
meldet ihn und importiert vollständig weiter.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-08 10:02:32 +02:00
Weapie
88a3eb1dcc Erklärungen aus der DSE-Gesamtliste neu aufbauen
All checks were successful
Container-Image bauen und veröffentlichen / build-and-push (push) Successful in 1m54s
Führende Quelle ist jetzt der Excel-Export des Amtes statt der einzelnen
Merkblatt-PDFs: 120 Zeilen, davon 4 bisher nicht erfasste Sozialamts-
Leistungen. Zuordnung über den Bezeichner, nicht den Titel – die aus PDF
gelesenen Titel unterscheiden sich in neun Fällen nur in Leerzeichen um
Schrägstriche und hätten Dubletten erzeugt.

Zwei Angaben stehen nicht in der Liste und werden ergänzt: der in allen
Merkblättern enthaltene Empfängersatz zur Finanzbuchhaltung (ohne ihn
hätten 27 Erklärungen gar keine Empfängerangabe) und die Bezeichnung der
Verarbeitungstätigkeit aus den Organisationsspalten.

Die zehn Bausteine folgen durchgehend den zentralen Standardtexten;
gespeichert wird nur die eine echte Abweichung: die gemeinsame
Verantwortlichkeit mit dem ZIT SH beim Online-Wohngeldantrag.

Alle 121 Erklärungen bleiben unveröffentlicht – drei Standardtexte
(Widerspruchsrecht, Drittlandübermittlung, automatisierte Entscheidungen)
sind noch nicht gepflegt und ohne sie ist keine vollständig.

Die Quellliste selbst bleibt unversioniert: Sie führt Namen von
Beschäftigten, die nicht in die Erklärungen übernommen werden.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-08 09:12:26 +02:00
61c4998a79 Datenschutzerklärungen veröffentlichungsreif machen
All checks were successful
Container-Image bauen und veröffentlichen / build-and-push (push) Successful in 1m23s
Die öffentliche API gab bei ?admin=true alle Datensätze heraus, auch die
nicht veröffentlichten: von 117 Erklärungen waren 112 Entwürfe, die jeder
Besucher abrufen konnte. Der Parameter setzt jetzt eine Admin-Sitzung
voraus, sonst kommt die öffentliche Liste. Der Einzelabruf behandelt
Entwürfe wie nicht vorhanden, damit sich über die fortlaufende ID nicht
abklopfen lässt, welche Datensätze existieren.

Markdown wurde mit sanitize: false gerendert und per
dangerouslySetInnerHTML eingesetzt. Das Standard-Schema lässt jetzt
Überschriften, Listen, Tabellen und http(s)/mailto-Links durch und
entfernt Skripte, Event-Attribute, eingebettete Rahmen und
javascript:-Ziele. Der Titel in der Druckfassung war an drei Stellen
unmaskiert.

Standardtexte
- Zehn Bausteine, die für alle Erklärungen gelten, werden einmal zentral
  gepflegt. In der Erklärung steht nur eine Abweichung; ein leeres Feld
  bedeutet "folgt dem Standard". Ein Wechsel in der Amtsleitung wirkt
  damit sofort auf alle Erklärungen, die nicht bewusst abweichen.
- Die Migration übernimmt den häufigsten Bestandswert als Standard und
  setzt übereinstimmende Felder auf NULL. Von 117 Erklärungen folgen
  danach 116 dem Standard, eine weicht ab (Online-Verfahren mit ZIT-SH
  als zusätzlichem Verantwortlichen).

Pflichtangaben nach Art. 13/14 DSGVO
- Neue Felder für Drittlandübermittlung (Art. 13 Abs. 1 lit. f),
  automatisierte Entscheidungsfindung (Art. 13 Abs. 2 lit. f),
  Datenkategorien (Art. 14 Abs. 1 lit. d) und berechtigte Interessen
  (Art. 13 Abs. 1 lit. d). Auf die ersten beiden muss auch dann
  hingewiesen werden, wenn es sie nicht gibt, deshalb sind sie
  Standardtexte mit ausdrücklichem "findet nicht statt".
- Der Hinweis auf das Widerspruchsrecht steht nach Art. 21 Abs. 4 in
  einem eigenen, abgesetzten Kasten vor allen Abschnitten, nicht als
  Zeile im Fließtext der Betroffenenrechte.
- Zweck, Rechtsgrundlage und Speicherdauer sind Pflicht. Geprüft wird
  beim Veröffentlichen, nicht beim Speichern: Ein Entwurf darf
  unvollständig sein, eine öffentlich sichtbare Erklärung nicht. So
  bleiben Bestandsdaten bearbeitbar, ohne dass die Anwendung Angaben
  erfindet, die nur die Fachabteilung kennt. Die Admin-Übersicht
  markiert unvollständige Erklärungen und nennt die fehlenden Angaben.

Öffentliche Seiten
- Jede Erklärung hat eine dauerhafte Adresse /erklaerung/<bezeichner>,
  serverseitig gerendert, zum Verlinken aus Antragsformularen. Der
  Bezeichner wird aus dem Titel abgeleitet und bleibt beim Bearbeiten
  erhalten, solange der Titel gleich bleibt. Entwürfe liefern 404.
- Impressum, Datenschutzerklärung des Portals und Erklärung zur
  Barrierefreiheit werden im Admin als Markdown gepflegt und in der
  Fußzeile verlinkt. Die Fußzeile rendert serverseitig, weil das
  Impressum ohne JavaScript erreichbar sein muss. Ein leerer Text nimmt
  die Seite vom Netz, statt eine leere Seite auszuliefern.
- Die Übersicht nutzt echte Links statt Klick-Handler und wird
  serverseitig vorbefüllt.

APP_COMPANY_NAME ersetzt den Namen der Anwendung in Kopf- und Fußzeile,
Seitentiteln, Anmeldeseite, Druckfassung und Startmeldung des
Containers. Der Wert wird zur Laufzeit gelesen, ein Neubau des Images
ist zum Umbenennen nicht nötig.

Getestet gegen die 117 Bestandsdatensätze: Migrationen angewendet, der
angezeigte Text blieb bei allen 117 x 7 Baustein-Feldern identisch. Alle
117 Bezeichner sind eindeutig und stimmen mit lib/slug.ts überein
(SQLites LOWER() kennt nur ASCII, Großumlaute werden deshalb vorher
ersetzt). ?admin=true liefert ohne Anmeldung 5 statt 117 Datensätze,
Entwürfe 404. Über die API mit Anmeldung geprüft: unvollständig als
Entwurf wird angelegt, dieselben Angaben mit isPublic abgelehnt, ebenso
fehlende Datenkategorien bei angegebener Herkunft. Ohne
APP_COMPANY_NAME erscheint "Syncova Policies", mit gesetztem Wert kein
einziges Vorkommen mehr.

Die Änderungen liegen in einem Commit, weil Schema, API-Routen und
Formulare von allen Teilen berührt werden und eine thematische Aufteilung
nicht lauffähige Zwischenstände ergäbe.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-07 20:35:05 +02:00
Weapie
328f042307 Syncova Policies: Portal für DSGVO-Datenschutzerklärungen
Next.js 15 App Router mit öffentlicher Übersicht und geschütztem
Admin-Bereich zur Pflege von Datenschutzerklärungen nach Art. 12ff. DSGVO.

- Oberfläche auf Basis von shadcn/ui, Inter lokal eingebunden
- Prisma/SQLite, Auth.js mit Credentials-Provider und Rollen
- Massenimport der Merkblätter des Amtes Leezen aus PDF
- Docker-Image (standalone) und Gitea-Workflow zur Veröffentlichung

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-07 16:23:51 +02:00