docs: Arbeitskarten Portal-Betrieb 131 #425
@@ -71,9 +71,11 @@ Offene PRs, die auf Merge warten, stehen unter C-01. Merge-Reihenfolge: erst DB-
|
||||
|
||||
## D. Portal-Betrieb (Stand 2026-10-28)
|
||||
- D-01 Portal-UI (PR #409) und account-api-Start (PR #410): gemergt.
|
||||
- D-02 Portal auf 131: gebaut, Unit und nginx/nft offen, siehe `docs/BETRIEB-PORTAL.md`.
|
||||
- D-03 account-api auf 131: DB-Passwort `nexarch_core` abgleichen (Betreiber), Unit aus Vorlage erneuern.
|
||||
- D-02 Portal auf 131: eingerichtet mit `deploy/131-portal-einrichten.sh` (#424): Unit `nexarch-web-portal`, Port 8450, CORS am Core, Audience `portal`. Offen: Anmeldung im Browser testen.
|
||||
- D-03 account-api auf 131: erledigt, Passwort der Rolle `nexarch_core` abgeglichen (2026-10-29). Offen: `NEXARCH_ACCOUNT_REGISTRY_DSN` fehlt (Sperr-Ereignisse nicht im zentralen Audit-Log).
|
||||
- D-04 204: localhost-Adressen in connect/connect-datev/rbac-admin behoben; Port 3113 offen.
|
||||
- D-05 Frontends auf Bearer: workflow-approvals, workflow-tasks, workflow-cases, routing-rules, Portal-BFF (PR #412, #413), mail-search (#416), connect-setup, connect-status, datev-export, dms2-import mit `connect-app`-Prüfung (#419); gemeinsamer Helfer `createBearerClient` in `@nexarch/shl` (#417). Offen: Ende-zu-Ende-Test mit Anmeldung auf 204; CORS für `Authorization` an der Connect-API auf 131; `connect` in `NEXARCH_ACCOUNT_MODULE_AUDIENCES`; `NEXARCH_CONNECT_APP_JWKS_URL` und `_TENANT_SLUG` setzen; danach `NEXARCH_WORKFLOW_APP_ALLOW_HEADER_AUTH` und `NEXARCH_CONNECT_APP_ALLOW_HEADER_AUTH` entfernen.
|
||||
- D-06 Workflow-Demo auf 204 läuft (siehe `docs/BETRIEB-PORTAL.md`).
|
||||
- D-07 Issue #369 (RBAC in ai-search, workflow-tasks, connect-setup): gemergt (#418, #420). Rolle kommt als `X-User-Role` aus dem Token; `connect.setup.write` nur `tenant_admin`. Dienste starten ohne `NEXARCH_{AI,WORKFLOW,CONNECT}_APP_POLICY_URL` nicht (Übergang: `…_POLICY_DISABLED=1`). Offen: Migration 0029 auf allen Mandanten-DBs einspielen, bevor die Binaries ausgerollt werden; `statusapi` fragt weiter mit fester Rolle `user`; `bearerauth` liegt doppelt (workflow, connect) und gehört nach `common/`; `datevapi` ist in `connect-app` nicht registriert.
|
||||
- D-08 Login und Portal (#422, #423): nach der Anmeldung direkt ins Portal (`NEXT_PUBLIC_PORTAL_URL`, ohne Rücksprung-URL wegen Open-Redirect); Betriebszustand an den Kacheln, nur für `core.tenant.admin` sichtbar, braucht `PORTAL_STATUS_API_URL`. Offen: Statusdienst-Demo auf 204.
|
||||
- D-09 Archive-Jobs auf 131 (2026-10-29): `backup-full` scheiterte mit falschem Passwort der Rolle `nexarch_backup`, `backup-incremental` als Folge; `reconcile` und `scrub` zeigten auf die Test-DB `dms_tenant_test` und liefen auf `file_revisions`-Fehler. Behoben: Passwort abgeglichen, DSN und Storage-Pfad auf die DB von `dms-app` (`tenant_rollout_test`), `scrub_state` angelegt. Offen: eigene Leserolle statt `dms_app`; klären, ob `tenant_rollout_test` die endgültige Mandanten-DB ist; Dauer des Backup-Ausfalls unbekannt (Fehlstarts seit mindestens 22.10.).
|
||||
Reference in new issue
Block a user