kommunalassist-core

Der gemeinsame Kern der Kommunalassist-Familie: Mandant, Termin-Engine (Regelwerk mit Freigabe-Workflow) und die Ports zu Fachverfahren und DMS.

Namenswechsel 2026-09-10. Das Paket hiess bis 0.4.0 iil-assist-core. Der Verteilname trug den Namen des Anbieters, obwohl das Produkt in einer Kommunalverwaltung laeuft — und er kollidierte mit iil-assist, dem Plattform-Mechanismus aus platform:KONZ-platform-058. Der Importname bleibt assist_core, ebenso App-Label und Tabellennamen: dort steht kein Anbietername, eine Umbenennung haette nur Migrationen gekostet und nichts geloest. Aendern muss ein Adopter genau eine Zeile in requirements.txt.

Grundlage: meiki:ADR-044 (Paket-Topologie) · meiki:ADR-022 v1.1 (die Termin-Engine gehört in den Kern) · meiki:ADR-025 (Mandantenfähigkeit).

Warum es dieses Paket gibt

Die Termin-Engine hat zwei Konsumenten: FristAssist führt Wiedervorlagen, StatistikAssist führt Meldetermine. Ein Meldetermin ist eine Frist mit Stichtag — dieselbe Rechnung, zwei Zwecke. Läge die Engine hinter FristAssist, bräuchte StatistikAssist FristAssist. Genau das schließt der Produktschnitt aus.

Was drin ist

Engine

assist_core.engine ist die eine Rechenstelle für Termine (meiki:ADR-022 v1.1) — zwei Konsumenten (FristAssist, StatistikAssist), eine Implementierung. berechne_frist() rechnet Fristen nach § 187/188/193 BGB. Fiktionstage, Feiertagskalender und Zeitzone sind Pflichtparameter ohne Vorgabewert — sie kommen aus der Regel bzw. aus der Einstellung des Hauses (feiertage_fuer(), zeitzone_fuer()); fehlen sie, bricht die Rechnung mit FristKonfigurationFehlt ab. Den Ereignistag bestimmt die Engine in der Zeitzone des Hauses, nicht in UTC; Zeitpunkte ohne tzinfo lehnt sie ab. serie() leitet daraus wiederkehrende Meldetermine (monatlich/quartalsweise/jährlich) für StatistikAssist ab. Die bayerischen Feiertage (feiertage_bayern(), inkl. Mariä Himmelfahrt) sind seit 0.4.0 Startbestand statt Konstante: Mariä Himmelfahrt gilt nur in Gemeinden mit katholischer Mehrheit, das Augsburger Friedensfest nur in Augsburg. Der Kalender ist deshalb ein Profil je Kennung (Feiertagskalender, Import über seed_feiertage), das ein Haus kopieren und abweichend pflegen kann (KONZ-meiki-009 § 3.2). Der Regel-Resolver liest Fristwerte aus der Governance-Tabelle Regelfreigabe, mit Code-Katalog-Fallback, solange keine Regel gepflegt ist.

Mandant

Jede mandantengebundene Tabelle erbt von assist_core.tenancy.TenantModel (tenant_id als BigIntegerField, platform:ADR-109). Der Manager ist fail-closed — ohne aktiven Mandanten none(), nicht ungefiltert:

with transaction.atomic(), tenant_context(4711):
    Verfahren.objects.all()  # Manager + Policy filtern beide
# Einziger Cross-Tenant-Pfad, schreibt TenantAuditEintrag:
Verfahren.objects.all_tenants(grund="Statistik")

RLS

manage.py assist_rls --apply [--app-rolle assist_app] legt je Tabelle mit Mandanten-Spalte eine Policy an — USING (tenant_id = NULLIF(current_setting( 'app.tenant_id', true), '')::bigint), ohne OR-Ausweich-Zweige. Kein Mandant heißt keine Zeile; nur Regelfreigabe öffnet über tenant_scope_id IS NULL die globalen Regeln, nie fremde Mandanten. Der GUC ist transaktionslokal, Aufrufer brauchen also transaction.atomic(). --app-rolle setzt NOBYPASSRLS und entzieht UPDATE/DELETE auf den Audit-Tabellen; --check endet mit Exit ≠ 0, wenn eine Policy fehlt oder einen aufmachenden Zweig trägt.

Bürgerverzeichnis

assist_core.buergerverzeichnis hat drei Adapter für einen Port (BuergerVerzeichnisPort, core:ADR-002/ADR-003): DbBuergerVerzeichnis (die Tabelle — läuft im Dienst buerger-hub des Hauses), HttpBuergerVerzeichnis (ein Assist-Host spricht mit diesem Dienst) und InMemoryBuergerVerzeichnis (Tests). Für alle drei gilt: suchen liefert höchstens SUCHEN_LIMIT_MAX (10) Treffer und sucht nie ohne Namen; anlegen mit gleichem anlass liefert denselben Datensatz.

Einen Host an den Dienst binden — drei Stellen, kein Code:

# settings.py des Hosts
ASSIST_ADAPTER_ALLOWLIST = [
    "assist_core.buergerverzeichnis.HttpBuergerVerzeichnis",
]
BUERGER_DIENST_URL = env("BUERGER_DIENST_URL")  # Wurzel, z. B. https://buerger.<haus>.example
BUERGER_DIENST_TOKEN = env("BUERGER_DIENST_TOKEN")  # Wert aus dem Secret-Fundort, nie im Repo

# eine Zeile je Haus (Daten, nicht Code)
AdapterBindung.objects.create(
    tenant_id=4711,
    port="BuergerVerzeichnisPort",
    implementierung="assist_core.buergerverzeichnis.HttpBuergerVerzeichnis",
    konfig_ref="BUERGER_DIENST_TOKEN",  # Zeiger auf den Fundort, nie der Wert
)

resolve(tenant_id, "BuergerVerzeichnisPort")() liefert dann den Adapter; er schickt den Mandanten aus tenant_context als X-Mandant. Der Vertrag ist docs/contracts/buergerverzeichnis-http-v0.1.md. Fehler kommen als BuergerUnbekannt (404), PermissionError (401/403), UngueltigeAngabe (422, mit Feldname), IdempotenzKonflikt (409) und VerzeichnisNichtErreichbar (Netz, Timeout 5 s, 5xx) — die letzte fängt der Host gezielt: der Fall bleibt offen, es gibt keinen lokalen Ersatzbestand (ADR-003, Regel „Ausfall").

DMS-Anbindung (d.velop)

Seit iilgmbh/iil-assist-core#45 Phase A (meiki:ADR-047 Stufe 2) liegt der d.velop-Adapter im Kern statt dreimal in den Hosts. Er verhält sich nach der strengsten Host-Variante:

• Nichts aus dem Code. Verbindung, Kategorie je Dokumentart, Eigenschaften und Vorgangssuche kommen aus assist_core.dms_einstellungen — Zeilen je Haus, keine Vorgabewerte. Fehlt eine gebrauchte Zuordnung, wirft der Adapter DvelopEinstellungFehltError vor dem ersten HTTP-Aufruf.
• Anzeigenamen, nicht Ids. Das Haus pflegt Anzeigenamen, der Adapter löst sie je Aufruf gegen /objdef und /source auf: exakt oder als eindeutiges Name (Zusatz), nie per Präfix.
• Rücklesen und Einhängen belegen. Nach dem Anlegen werden die Eigenschaften zurückgelesen (Datum auf den Kalendertag normalisiert); verlorene Werte sind ein Fehler mit dms_ref. Ist ein Eltern-Vorgang bekannt, muss das Objekt unter ihm auftauchen (index_frist_s, Standard 30 s).
• Secret als Zeiger. AdapterBindung.konfig_ref nennt den Namen, assist_core.geheimnis liefert den Wert aus der Umgebung oder settings.ASSIST_SECRETS_DIR.

Einrichten und prüfen:

pip install 'kommunalassist-core[dvelop]'
manage.py seed_dms_einstellungen --tenant 1 --basis-url https://<haus>.d-velop.cloud \
    --repository-id <repo> --dokumentart antrag="<Kategorie>" \
    --eigenschaft dokument_id="<Eigenschaft>" --vorgang-suche "<Kategorie>|<Aktenzeichen>|<Vorgang>"
manage.py pruefe_dms_bindung --tenant 1 --port DokumentAblagePort --port DmsPort --mit-dms

pruefe_dms_bindung ist das Gate vor dem Start: aktive Bindung, kein In-Memory-Pfad, Allowlist, erklärte Fähigkeit — und mit --mit-dms jede gepflegte Einstellung gegen das DMS aufgelöst (falscher Kategoriename ⇒ Exit ≠ 0).

Der Vertragstest (tests/test_dvelop_adapter.py) läuft gegen aufgezeichnete, anonymisierte Antworten des Cloud-Testmandanten (tests/fixtures/dvelop/); die Form ist echt, die Werte sind Platzhalter.

Die App trägt das Label assist_core_dms (Tabellen assist_core_dms_*). Hosts mit eigener dms_einstellungen-App ziehen in Phase B/C per Rename-Migration um.

Was nicht drin ist

Kein Hausinhalt. Keine Regelwerke, keine Vorlagen, keine Mandantenwerte, keine Team- oder Fachbereichsbezeichnungen. Nach meiki:ADR-044 ist alles, was sich je Haus unterscheidet, eine Zeile in Postgres — nicht Code, nicht YAML.

Prüfbar: ein zweites Haus geht durch Konfiguration und Uploads in Betrieb, nicht durch einen Commit.

App-Label und Tabellennamen

assist_core, also assist_core_*. Kein db_table auf die Namen des Herkunfts-Repos — siehe docs/adr/ADR-001.

Entschieden am 2026-09-09 zugunsten eines echten Renames statt einer Zustands-Migration, weil es noch keinen produktiven Datenbestand gibt. Für das Repo, das die Tabellen heute hält (meiki-lra/frist-hub), bedeutet das beim Umstellen eine Umbenennungs-Migration — beim jetzigen Stand risikoarm, mit produktiven Daten wäre sie es nicht. Das Zeitfenster ist begrenzt.

CI

Jeder PR und jeder Push auf main läuft gegen Postgres 16: ruff check, ruff format --check, pytest und makemigrations --check (siehe .github/workflows/ci.yml).

Stand

0.4.0 — Tenancy-Basis, RLS-Erzeuger, Registries (KONZ-meiki-009 U3). Noch von keinem Repo als Abhängigkeit gebunden. tenant_id bleibt BigIntegerField; der Vorschlag, in der ganzen Familie auf UUID zu wechseln (KONZ-meiki-009 § 4.1, D-2), ist offen und hier nicht vorweggenommen.