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 mitiil-assist, dem Plattform-Mechanismus ausplatform:KONZ-platform-058. Der Importname bleibtassist_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 inrequirements.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
| Modul | Inhalt |
|---|---|
models |
Regelfreigabe (Regelwerk mit Zustandsmodell entwurf → eingereicht → freigegeben → abgelehnt), RegelAuditEintrag, MandantEinstellung, TenantAuditEintrag, Registries (Verfahren, Quellsystem, AdapterBindung, Feiertagskalender) |
tenancy |
TenantModel/TenantManager (fail-closed), tenant_context(), GUC app.tenant_id |
registry/adapters |
Validierung an der Grenze gegen die Registry-Tabelle; Adapter-Auflösung gegen eine Allowlist |
mandant |
Hauspraxis als Konfiguration — ohne gepflegte Einstellung wird nichts geraten, die Renderer liefern None |
regelkatalog |
einmaliger Import von Startbeständen. Keine Betriebsquelle — im Betrieb gilt allein die Tabelle |
engine |
die Termin-Engine — berechne_frist(), Regel-Resolver, serie() |
ports |
Schnittstellen zu Fachverfahren und DMS; dazu die Fähigkeitsmatrix DmsFaehigkeit/dms_faehigkeiten() (Vorgang suchen, Dokument ablegen, Inhalt lesen, Wiedervorlage) |
dms_einstellungen |
DMS-Einstellungen je Haus als Tabellen (DmsVerbindung, DmsDokumentart, DmsEigenschaft, DmsVorgangSuche), lesen/services, Kommandos seed_dms_einstellungen und pruefe_dms_bindung |
dvelop |
d.velop-documents-Adapter (native REST) für DokumentAblagePort, DmsVorgangPort, DmsPort — Extra [dvelop] |
geheimnis |
lies_geheimnis(name): Secret-Zeiger aus AdapterBindung.konfig_ref → Umgebung (DVELOP_API_KEY) oder ASSIST_SECRETS_DIR; der Wert erscheint nie in Meldung oder Log |
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 AdapterDvelopEinstellungFehltErrorvor dem ersten HTTP-Aufruf. - Anzeigenamen, nicht Ids. Das Haus pflegt Anzeigenamen, der Adapter löst sie je
Aufruf gegen
/objdefund/sourceauf: exakt oder als eindeutigesName (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_refnennt den Namen,assist_core.geheimnisliefert den Wert aus der Umgebung odersettings.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.
Erscheinungsbild
Alle Assists sehen gleich aus (iilgmbh/iil-assist-core#51). Der Kern liefert den Rahmen
assist_core/basis.html und drei Stylesheets unter static/assist_core/:
tokens.csswird aus dem design-hub-Profilmeiki-lraerzeugt. Nicht von Hand ändern, sondern neu erzeugen:python -m iil_klickdummy.gen_tokens --profile <design-hub>/profiles/meiki-lra.yaml --out assist_core/static/assist_core/tokens.css.semantic.cssordnet Rollen wie Link, Statusfläche und Fläche den Tokens zu.assist.cssgestaltet Kopf, Navigation, Tabellen, Formulare, Knöpfe, Meldungen und Status. Dort steht kein einziger Farbwert, das sicherttests/test_erscheinungsbild.py.
Eine App erweitert den Rahmen und füllt die Blöcke titel, marke, navigation, konto
und inhalt. Eigenes CSS hängt sie über kopf_zusatz an, Farben nur über var(--kd-…):
{% extends "assist_core/basis.html" %}
{% block marke %}<a class="marke" href="{% url 'start' %}">FristAssist</a>{% endblock %}
{% block navigation %}<nav aria-label="Hauptnavigation">…</nav>{% endblock %}
{% block konto %}<span class="konto">{{ user.get_username }} <form …><button>Abmelden</button></form></span>{% endblock %}
Eigenes App-CSS prüft die App mit derselben Regel wie der Kern, statt die Muster zu kopieren:
from pathlib import Path
from assist_core.erscheinungsbild import befunde_app_css
def test_should_build_app_css_on_tokens_only():
assert befunde_app_css(Path("apps/…/static/…/app.css").read_text()) == []
Voraussetzung im Host: assist_core steht in INSTALLED_APPS, außerdem APP_DIRS: True
und die Auslieferung statischer Dateien (WhiteNoise). Das Image muss collectstatic
ausführen. Ohne diesen Schritt liefert WhiteNoise bei DEBUG = False 404, und die Seiten
stehen ohne Erscheinungsbild da. Die Testsuite sieht das nicht, weil sie mit DEBUG läuft;
frist-hub prüft es deshalb im CI-Job image-static.
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.
Metadata
Release files for kommunalassist-core 0.16.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| kommunalassist_core-0.16.0.tar.gz | 156.5 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| kommunalassist_core-0.16.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 263.9 kB
Release files / kommunalassist_core-0.16.0.tar.gz
| Download URL | kommunalassist_core-0.16.0.tar.gz |
|---|---|
| Size | 156.5 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
dfc282c143aec00e9897bcc398297552bcffa7ddc657323fbc5999830d0d998e
|
|
BLAKE2b-256 checksum How to use checksums |
9702d4fb7845a198826520056df1daee29def0515a511b8aac22d8afd82b7ce3
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 6, 2026.
Transparency logRelease files / kommunalassist_core-0.16.0-py3-none-any.whl
| Download URL | kommunalassist_core-0.16.0-py3-none-any.whl |
|---|---|
| Size | 107.4 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
71c5c88b1e674b0efde0e13b7478e4673709734fe377b8d5079ce28fa392bb55
|
|
BLAKE2b-256 checksum How to use checksums |
6df8153228d4ed66e5049895a9a616a57252b0bc9aa9cd87a64c81e7528e8569
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 6, 2026.
Transparency log