Zum Inhalt springen
Procur Logo
Anmelden

Schema procur_fit für Projekte, Nachweise und Analysen

Status: als Referenzdateien umgesetzt am 30.09.2026. Auf der gehosteten Dev-Datenbank erst nach Freigabe durch den Nutzer angewendet.

Kontext

Der Agent-Arbeitsplatz (Spec, Abschnitt 4) braucht Organisationstypen, Projekte, Kriterien, Nachweise und gespeicherte Analysen in der Datenbank. Bisher lagen Projekte und Arbeitsstand der VergabeFit-Module im localStorage des Browsers. Vergabestellen und Unternehmen arbeiten auf derselben Plattform, dürfen aber die Daten der jeweils anderen Seite nicht sehen.

Entscheidung

  • Eigenes Schema procur_fit mit sieben Tabellen: projects, project_documents, watched_notices, requirement_sets, profiles, profile_facts, analysis_runs. Die Referenzdateien liegen in database/fit/, die Policies in database/security/rls.sql, weil sie die Mitgliedschafts-Helfer aus regx/functions.sql brauchen.
  • Vergabestellen sind Organisationen in procur_regx.companies mit org_kind = 'authority' (company, authority, both). Mitgliedschaften, Einladungen, Claims und der Org-Wechsler gelten unverändert. Das öffentliche Firmenverzeichnis (list_public_companies, get_public_company) blendet Vergabestellen aus.
  • Ausschreibungen werden über notice_id text ohne Fremdschlüssel referenziert. complete_notice ersetzt die Lose bei jeder Neuverarbeitung. Anzeigedaten stehen als notice_snapshot im Projekt bzw. in der Merkliste.
  • Der Marktpool ist synthetisch. Pool-Profile haben company_id is null und is_synthetic = true (Check-Constraint). Alle freigeschalteten Nutzer lesen sie, nur Plattform-Admins schreiben sie.
  • Rechte pro Organisation der Zeile: Mitglieder lesen, OWNER/EDITOR schreiben. Einzige Ausnahme ist watched_notices, dort schreiben alle Mitglieder. Analysen sind eine reine Historie ohne Update. Eine bestätigte Kriterienrevision ist per Trigger unveränderlich, Korrekturen werden eine neue Revision.
  • Organisationsdokumente sind procur_docs.user_documents mit gesetzter company_id und doc_kind. Sie gehören der Organisation: Mitglieder lesen, nur OWNER/EDITOR legen an, ändern und löschen, auch wenn sie das Dokument erstellt haben. Ein VIEWER kann keine Organisationsdokumente anlegen, ein ausgeschiedenes Mitglied verliert den Zugriff. Dateien liegen im Bucket user-documents unter org/<company_id>/….

Folgen

  • Ein neues Schema muss in acht Freigabelisten stehen (Spec 4.4): 00_schema.sql, config.sql, REFERENCES in scripts/sync_database.py, verify_schema.sql, supabase/config.toml, selfhosted_bootstrap.sql, deploy/.env.example samt Frontend-Konfiguration sowie diese Dokumentation. Fehlt eine, scheitert der Zugriff erst zur Laufzeit.
  • Beim gehosteten Projekt muss procur_fit in der Supabase-Oberfläche unter „Exposed schemas“ stehen, sonst antwortet PostgREST mit PGRST106.
  • config.sql vergibt SELECT auf künftige Tabellen der procur-Schemas automatisch. RLS ist deshalb die einzige echte Sperre, und verify_schema.sql verlangt RLS für jede Tabelle in procur_fit.
  • Die Startdaten (database/fit/seed_demo.sql) werden von Hand eingespielt. Die E-Mail-Adresse des Demo-Kontos wird nur beim Aufruf als psql-Variable übergeben.
  • Geprüft wird in pglite (database/tests/fit.test.mjs mit fit_rls.sql): Vertraulichkeit zwischen Organisationen, VIEWER-Rechte, unveränderliche Kriterien, Storage-Pfade, Verzeichnis ohne Vergabestellen und die Idempotenz von Replay und Seed.