schalli
a0c5e470c3
- 16-05-SUMMARY.md documents the two-task plan (sync-report wiring, grants-matrix internal-name fallback). - PERM-02 marked complete in REQUIREMENTS.md: all five Phase-16 success criteria are code-complete across plans 16-01..16-03; this plan delivered the last missing visibility layer (D-05/D-06) and the third D-04 display site. - WINDOWS.md #6: this plan's own manual browser walkthrough (sync report three-line render, amber default-marker line, grants-matrix two-name search) not executed — no browser tool in this session.
134 lines
10 KiB
Markdown
134 lines
10 KiB
Markdown
# Requirements — Milestone v1.1: Ausschreibungs-Radar + v1.2: Plattform-Berechtigungen
|
||
|
||
**Module:** Ausschreibungs-Radar — durchsucht deutsche Vergabeportale nach Ausschreibungen, filtert nach Kriterien, zeigt Treffer im Portal an und versendet optional per E-Mail.
|
||
**Basis-Research:** `.planning/research/SUMMARY.md`, `.planning/research/ausschreibungs-portale-feasibility.md`
|
||
**Defined:** 2026-07-17
|
||
|
||
> v1.0-Requirements sind ausgeliefert und in PROJECT.md (Validated) nachgehalten. Diese Datei enthält nur die v1.1-Requirements. REQ-IDs setzen neue, modul-lokale Kategorien.
|
||
|
||
## v1.1 Requirements
|
||
|
||
### INGEST — Datenquellen
|
||
|
||
- [x] **INGEST-01**: Das System ruft Ausschreibungen zeitgesteuert über die DÖE OpenData-API (oeffentlichevergabe.de, eForms/OCDS, auth-frei) ab.
|
||
- [x] **INGEST-02**: Das System importiert Ausschreibungen von Administration-Intelligence-NetServer-Portalen (lhs-vpbw, tender24, vergabe.landbw) über einen konfigurierbaren Adapter.
|
||
- [x] **INGEST-03**: Das System importiert Ausschreibungen vom cosinex-Vergabemarktplatz (DTVP) über einen Adapter.
|
||
- [x] **INGEST-04**: Das System importiert Ausschreibungen aus RSS-Feeds (subreport-elvis, service.bund.de).
|
||
- [x] **INGEST-05**: Das System liest Portal-Benachrichtigungs-E-Mails aus einem konfigurierten Postfach ein (nutzt bestehende DKV-Inbox-Infrastruktur) und extrahiert daraus Ausschreibungen.
|
||
- [x] **INGEST-06**: Jede Quelle wird einmal zentral pro Zeitplan abgefragt (poll-once-fan-out-many), Intervall pro Quelle im Admin-Bereich konfigurierbar; das Ergebnis wird an alle passenden Mandanten-Suchprofile verteilt.
|
||
- [x] **INGEST-07**: vergabe24 und aumass sind als harte Denylist hinterlegt und können nicht als automatische Scraping-Quelle registriert werden (AGB-Verbot).
|
||
|
||
### SCHEMA — Normalisierung & Deduplizierung
|
||
|
||
- [x] **SCHEMA-01**: Alle Quellen werden in ein einheitliches, OCDS-orientiertes Ausschreibungs-Schema normalisiert (Titel, Auftraggeber, CPV-Codes, Region/PLZ, Frist, geschätzter Wert, Verfahrensart, Quell-URL, Rohdaten). Ausschreibungsdaten sind plattform-global, nicht mandantengebunden.
|
||
- [x] **SCHEMA-02**: Das System erkennt Änderungen an bereits importierten Ausschreibungen (Fristverlängerung, Aufhebung) über einen Content-Hash und aktualisiert den Datensatz.
|
||
- [x] **SCHEMA-03**: Dieselbe Ausschreibung aus mehreren Quellen wird zu einem Eintrag mit mehreren Quell-Links dedupliziert (Schlüssel: OCID → Quelle:NoticeId → Fuzzy-Fingerprint aus Auftraggeber+Titel+CPV+Frist+Wert). Dedup greift erst ab der zweiten aktiven Quelle.
|
||
|
||
### FILTER — Suche & Profile
|
||
|
||
- [x] **FILTER-01**: Nutzer kann per Volltext-Stichwort (Titel/Beschreibung) suchen.
|
||
- [x] **FILTER-02**: Nutzer kann nach Region / PLZ / Bundesland filtern.
|
||
- [x] **FILTER-03**: Nutzer kann nach CPV-Code / Branche filtern (hierarchische Auswahl mit Autocomplete).
|
||
- [x] **FILTER-04**: Nutzer kann nach Abgabefrist filtern, inkl. Option „nur noch offene".
|
||
- [x] **FILTER-05**: Nutzer kann nach geschätztem Auftragswert (min/max) filtern; Ausschreibungen ohne Wertangabe werden korrekt behandelt.
|
||
- [x] **FILTER-06**: Nutzer kann Suchprofile (Kombination aus Filterkriterien) speichern, bearbeiten und löschen — pro Nutzer, mandantenbewusst.
|
||
|
||
### UI — Anzeige & Triage
|
||
|
||
- [x] **UI-01**: Nutzer sieht eine durchsuchbare, sortierbare Trefferliste (Sortierung nach Frist, Wert, Veröffentlichungsdatum).
|
||
- [x] **UI-02**: Nutzer öffnet eine Detailansicht einer Ausschreibung mit Link zur Quelle und ggf. Dokument-URLs (keine lokale Spiegelung der Vergabeunterlagen).
|
||
- [x] **UI-03**: Nutzer kann Treffer als gelesen/ungelesen markieren (pro Nutzer).
|
||
- [x] **UI-04**: Nutzer kann Treffer als Favorit/Merkliste markieren und eine Merklisten-Ansicht filtern (pro Nutzer).
|
||
- [x] **UI-05**: Die UI weist die Abdeckung transparent aus (Oberschwelle vs. Unterschwelle), damit „keine Treffer" nicht als Fehler missverstanden wird.
|
||
- [x] **UI-06**: Ausgeschlossene Portale (vergabe24, aumass) werden als „manuell zu überwachen" mit Direktlink angezeigt.
|
||
|
||
### NOTIFY — Benachrichtigung
|
||
|
||
- [x] **NOTIFY-01**: Nutzer erhält einen periodischen E-Mail-Digest passender Treffer; Intervall im Webinterface konfigurierbar.
|
||
- [x] **NOTIFY-02**: Nutzer erhält optional eine Sofort-E-Mail bei einem neuen Treffer eines aktiven Suchprofils; im Webinterface aktivierbar.
|
||
- [x] **NOTIFY-03**: Das System unterscheidet „getroffen" von „benachrichtigt" (kein Doppelversand Digest+Sofort; kein Rückstau-Massenversand beim Anlegen eines Suchprofils).
|
||
- [x] **NOTIFY-04**: Der E-Mail-Versand nutzt die mandantenspezifische SMTP-Konfiguration (bestehendes DKV-Mail-Muster).
|
||
|
||
### CONFIG — Modul & Verwaltung
|
||
|
||
- [x] **CONFIG-01**: Das Modul ist im Marketplace registriert und pro Mandant aktivierbar (wie DKV-Fleet- und Cert-Manager-Modul).
|
||
- [x] **CONFIG-02**: Admin verwaltet Quellen-Poll-Konfiguration sowie das E-Mail-Ingestion-Postfach pro Mandant (Zugangsdaten verschlüsselt gespeichert).
|
||
- [x] **CONFIG-03**: Die gesamte Modul-UI ist mehrsprachig (Deutsch + Englisch, i18n).
|
||
|
||
## v1.2 Requirements
|
||
|
||
**Milestone:** v1.2 Plattform-Berechtigungen — Modulzugriff nicht mehr nur pro Mandant, sondern zusätzlich pro Gruppe und pro Benutzer.
|
||
**Defined:** 2026-08-04
|
||
**Kontext:** `.planning/phases/15-modul-berechtigungen-gruppen-user-grants/15-CONTEXT.md` (D-01 bis D-23)
|
||
|
||
### PERM — Modul-Berechtigungen
|
||
|
||
- [x] **PERM-01**: Admin verwaltet Gruppen pro Mandant (anlegen, umbenennen, löschen) und weist Benutzer manuell zu oder entfernt sie. Beim Löschen einer belegten Gruppe warnt ein Dialog mit Mitglieder- und Freigabenanzahl, bevor Mitgliedschaften und Freigaben mitgelöscht werden.
|
||
- [x] **PERM-02**: Ein Admin wählt im LDAP-Bereich einzelne AD-Gruppen aus und importiert sie; je ausgewählter Gruppe entsteht eine Tessera-Gruppe mit AD-Bindung, nicht ausgewählte werden nicht angelegt. Der bestehende Benutzer-Sync führt sie danach nach: Umbenennung im AD zieht in den Gruppennamen nach, Verschwinden aus dem AD löscht die Tessera-Gruppe samt Mitgliedschaften und Modulfreigaben, und `memberOf` pflegt die Mitgliedschaften — verlässt ein Benutzer die AD-Gruppe, fällt nur seine LDAP-Mitgliedschaft weg, manuell gesetzte bleiben bestehen. Lokal angelegte Gruppen ohne AD-Bindung bleiben vom Gruppen-Sync unberührt und können nicht nachträglich gebunden werden. *(Neu gefasst 2026-08-06 nach Phase-16-Entscheidungen D-01/D-05/D-07 — die frühere Fassung „lokale Gruppe an AD-DN binden" ist verworfen.)*
|
||
- [x] **PERM-03**: Admin gibt ein mandantenweit aktives Modul gezielt für Gruppen und für einzelne Benutzer frei und entzieht Freigaben wieder. Gruppenfreigaben werden in einer Matrix Module × Gruppen gepflegt, Einzelfreigaben im Benutzer-Detail samt Anzeige der über Gruppen geerbten Rechte.
|
||
- [x] **PERM-04**: Ohne Freigabe hat ein USER keinen Zugriff: das Modul fehlt in der Sidebar, die Modulseite antwortet mit einer 403-Seite samt Hinweis, und die Modul-API antwortet mit 403. Sidebar, Modulseite und API nutzen dieselbe Zugriffsauflösung.
|
||
- [x] **PERM-05**: ADMIN und SUPER_ADMIN sehen und nutzen innerhalb ihres Mandanten alle aktiven Module ohne Freigabe.
|
||
- [x] **PERM-06**: Die Migration überführt den Bestand ohne Zugriffsverlust: pro Mandant entsteht eine als Standardgruppe markierte Gruppe mit allen bestehenden Benutzern und Freigaben für alle zum Migrationszeitpunkt aktiven Module. Neue Benutzer — manuell angelegt wie per LDAP importiert — treten der markierten Standardgruppe automatisch bei.
|
||
- [x] **PERM-07**: Ein Dashboard-Widget, dessen Modul dem Benutzer nicht freigegeben ist, erscheint nicht auf seinem Dashboard.
|
||
|
||
## Future Requirements (deferred)
|
||
|
||
- [ ] TED API v3 (EU-weite Redundanz) — für DE-only weitgehend redundant zu DÖE.
|
||
- [ ] Relevanz-/Ranking-Score innerhalb eines Suchprofils.
|
||
- [ ] Dashboard-Widget „Ausschreibungen mit naher Frist" (nutzt Phase-8-Widget-Framework).
|
||
- [ ] CSV/Excel-Export gefilterter Ergebnisse.
|
||
- [ ] Team-/Kollaborationsfunktionen (Zuweisung, interne Notizen).
|
||
|
||
## Out of Scope (explizit ausgeschlossen)
|
||
|
||
- Direktes Scraping von vergabe24 & aumass — AGB-Verbot automatisierter Zugriffe; Oberschwellen-Daten kommen ohnehin über DÖE.
|
||
- Generisches „beliebiges Portal scrapen"-Framework — zu fragil über inkompatible Portal-Familien, dauerhafter Wartungsaufwand.
|
||
- Sub-stündliches Polling — Ausschreibungs-Lebenszyklen laufen über Tage/Wochen; erhöht nur Last/ToS-Risiko.
|
||
- Vollständiges Bid-Management/CRM (Angebotserstellung, Einreichung, Win/Loss) — anderes Produktsegment.
|
||
- KI-Zusammenfassungen / Bid-Fit-Scoring — verfrüht, eigener AI-SPEC-Phase vorbehalten.
|
||
- Lokale Spiegelung/Hosting der Vergabeunterlagen — rechtlich unklar; nur Verlinkung zur Quelle.
|
||
|
||
## Traceability
|
||
|
||
| Requirement | Phase | Status |
|
||
|-------------|-------|--------|
|
||
| CONFIG-01 | Phase 10 | Complete |
|
||
| INGEST-01 | Phase 10 | Complete |
|
||
| INGEST-06 | Phase 10 | Complete |
|
||
| SCHEMA-01 | Phase 10 | Complete |
|
||
| SCHEMA-02 | Phase 10 | Complete |
|
||
| FILTER-01 | Phase 11 | Complete |
|
||
| FILTER-02 | Phase 11 | Complete |
|
||
| FILTER-03 | Phase 11 | Complete |
|
||
| FILTER-04 | Phase 11 | Complete |
|
||
| FILTER-05 | Phase 11 | Complete |
|
||
| FILTER-06 | Phase 11 | Complete |
|
||
| UI-01 | Phase 11 | Complete |
|
||
| UI-02 | Phase 11 | Complete |
|
||
| UI-03 | Phase 11 | Complete |
|
||
| UI-04 | Phase 11 | Complete |
|
||
| UI-05 | Phase 11 | Complete |
|
||
| NOTIFY-01 | Phase 12 | Complete |
|
||
| NOTIFY-02 | Phase 12 | Complete |
|
||
| NOTIFY-03 | Phase 12 | Complete |
|
||
| NOTIFY-04 | Phase 12 | Complete |
|
||
| INGEST-02 | Phase 13 | Complete |
|
||
| INGEST-03 | Phase 13 | Complete |
|
||
| INGEST-07 | Phase 13 | Complete |
|
||
| SCHEMA-03 | Phase 13 | Complete |
|
||
| INGEST-04 | Phase 14 | Complete |
|
||
| INGEST-05 | Phase 14 | Complete |
|
||
| CONFIG-02 | Phase 14 | Complete |
|
||
| CONFIG-03 | Phase 14 | Complete |
|
||
| UI-06 | Phase 14 | Complete |
|
||
|
||
| PERM-01 | Phase 15 | Complete |
|
||
| PERM-02 | Phase 16 | Complete |
|
||
| PERM-03 | Phase 15 | Complete |
|
||
| PERM-04 | Phase 15 | Complete |
|
||
| PERM-05 | Phase 15 | Pending |
|
||
| PERM-06 | Phase 15 | Pending |
|
||
| PERM-07 | Phase 15 | Complete |
|
||
|
||
**Coverage:** 29/29 v1.1 requirements mapped — no orphans. 7/7 v1.2 requirements mapped: PERM-01/03/04/05/06/07 auf Phase 15, PERM-02 auf Phase 16 (umgehängt 2026-08-06).
|