sysops
9843275e9c
- dms/internal/retentionclient: HTTP-Client fuer Archive RET-05/RET-09 - dms/internal/retentiondestroy: RegisterOrRequeue (FDN-04-Requeue bei Fehlschlag, kein Absturz/stilles Verwerfen), DestroyCallbackHandler (physische Loeschung aller Datei-Revisionen ueber storage.Service, markiert Dokument als vernichtet, 2xx erst danach) - dms/cmd/app: mountet destroy-callback, registriert beim Start - dms/cmd/worker: verarbeitet Requeue-Jobs (Retry) - nur dms_document registriert (DOC-01/FDN-02 kennen keinen separaten Anhang-Typ, kein Umbau angrenzender Bereiche) - real getestet: registrierung gegen echten fake-RET-05-Server, echte Loeschung inkl. Storage-Byte-Nachweis, echter Requeue-Eintrag bei Fehlschlag, erfolgreicher Retry - live auf 131 gegen echten RET-09-Dienst (Port 8095) verifiziert, echter curl-Vernichtungs-Rueckruf mit real geloeschter Datei - reale Core-API-06-Deploy-Luecke dokumentiert (nicht verschwiegen): /internal/resync/usage auf 131 aktuell nicht gemountet Pruefungen siehe dms/docs/DOC-16-PRUEFPROTOKOLL.md
NEXARCH DMS
Dokumentenmanagement-Modul von NEXARCH. Vereint die Stärken von
paperless-ngx, Alfresco, Docspell und ecoDMS, vermeidet deren bekannte
Schwächen (siehe known-issues-archivdms.md im dms-kanban/-Ordner).
Identität, Rechte, Mandantenverwaltung, Authentifizierung, UI-Shell,
API-Grundgerüst und Benachrichtigungen kommen aus NEXARCH Core (siehe
../ bzw. ../../core-kanban/) — dieses Modul implementiert nur die
DMS-eigene Logik.
Setup
Voraussetzung: Go 1.22+.
cd dms
make install # baut App und Worker
make run # startet beide (Strg+C beendet beide)
App läuft danach auf :8090 (überschreibbar über
NEXARCH_DMS_APP_LISTEN_ADDR), GET /healthz liefert den Status.
Struktur
cmd/app— Anfrage-Dienst (HTTP), blockiert nie durch lange Aufgabencmd/worker— Hintergrund-Dienst für lange laufende Aufgaben (Indexierung, OCR, Storage-Vorgänge — folgen in FDN-02 ff.)internal/shared— von App und Worker gemeinsam genutzter Code
Prüfungen
make fmt # gofmt-Verstöße brechen ab
make lint # golangci-lint
make test # go test ./...
Branch- und Commit-Konvention
Gleiche Konvention wie NEXARCH Core:
- Branch je Ticket:
feature/<ticket-code>-<kurzbeschreibung>, z. B.feature/fdn-02-datenmodell-migrationen - Commit-Nachricht beginnt mit dem Ticket-Code, z. B.
FDN-02: datenmodell & migrationen - Ein Ticket = ein Branch. Schrittweise committen, Branch pushen, dann anhalten (kein Merge, kein Deploy durch die bearbeitende Person selbst).
- Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
- Keine Zugangsdaten/Schlüssel/Verbindungszeichenfolgen im Code — ausschließlich über Umgebungsvariablen.