gitmedia/presseportale
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 2

dev: Block 1a in der Roadmap als erledigt markiert, 1a.4-Entscheidung festgehalten

Browse source 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Kevin Adametz 2026-09-15 10:32:33 +00:00
parent 8dad652d67
commit 0f52e9fddc
1 changed files with 6 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

10
dev/2026-09-01/roadmap-2026.md
View file

@ -93,10 +93,10 @@ Der Kern. Wandelt vorhandenen Zulauf in Konten und Kunden, ohne neuen Traffic zu
| Nr. | Arbeitspaket | Aufwand | Abhängigkeit |
|---|---|---|---|
| 1a.1 | Trockenlauf-Bericht: wie viele Firmen fallen bei Zusammenführung über die Firmen-E-Mail zusammen, welche Adressen tragen mehrere Firmennamen | S | keine |
| 1a.2 | Sammeladressen-Erkennung: Adresse mit mehr als [Schwellwert] abweichenden Firmennamen wird markiert und von der automatischen Zusammenführung ausgenommen | S | 1a.1 |
| 1a.3 | Zusammenführung im Bestand mit gespeicherter Ursprungszuordnung, rückabwickelbar | M | 1a.2 |
| 1a.4 | Laufende Zuordnung neuer API-Meldungen zu bestehendem Newsroom über die Firmen-E-Mail | M | 1a.2 |
| ~~1a.1~~ | Trockenlauf-Bericht: wie viele Firmen fallen bei Zusammenführung über die Firmen-E-Mail zusammen, welche Adressen tragen mehrere Firmennamen — **live 11.09.2026** (`companies:merge-report`) | S | keine |
| ~~1a.2~~ | Sammeladressen-Erkennung: Adresse mit mehr als [Schwellwert] abweichenden Firmennamen wird markiert und von der automatischen Zusammenführung ausgenommen — **live 11.09.2026** (`companies:classify-addresses`, `company_email_groups`, E1 = 3) | S | 1a.1 |
| ~~1a.3~~ | Zusammenführung im Bestand mit gespeicherter Ursprungszuordnung, rückabwickelbar — **live 15.09.2026**: ~14 450 Adressen, ~18 100 Firmen aufgegangen, 13 236 Firmen `both`; 6 Slug-Kollisionen offen (`companies:merge`, `companies:unmerge`, `companies:merges`) | M | 1a.2 |
| ~~1a.4~~ | Laufende Zuordnung neuer API-Meldungen zu bestehendem Newsroom über die Firmen-E-Mail — **gebaut 15.09.2026** (`ApiNewsroomAssignment`), Wirkung nach Deploy über `companies:classify-addresses` messen | M | 1a.2 |
**Regelwerk Zusammenführung**
@ -110,6 +110,8 @@ Schlüssel ist die **Firmen-E-Mail**, nicht die Pressekontaktadresse. Der Presse
**Entschieden 15.09.2026 (1a.3):** Es bleibt die Firma mit den meisten jemals veröffentlichten Meldungen, bei Gleichstand die ältere; leere Stammdaten werden aufgefüllt. Meldungen, Kontakte und Verknüpfungen wandern per `company_id`, jede Bewegung protokolliert (`company_merges`/`company_merge_moves`), rückabwickelbar mit `companies:unmerge`. Die wegfallende Firma wird soft-deleted, ihr Slug führt per 301 weiter. Der Überlebende wird `both`, wenn die Hälften auf verschiedenen Portalen lagen — das ist bei 77 % der Gruppen der Fall (Altsystem: eine Firma je Portal). Slug-Kollisionen werden übersprungen, nicht umbenannt. Details in `umsetzung-protokoll.md` Teil 3.
**Entschieden 15.09.2026 (1a.4):** Die Zuordnung greift im Alt-Vertrag `POST /service/users/me/companies` — connektar bekommt bei gleicher Firmen-E-Mail und gleichem Namen (Namensregel der Klassifizierung) die ID der bestehenden Firma zurück, der Vertrag (201 + Location) bleibt. Abweichende Namen unter einer Adresse bekommen wie bisher eine neue Firma (Agentur, neuer Kunde); nie-veröffentlicht-Adressen werden nie zugeordnet; bei Firma auf dem anderen Portal wird sie `both`, bei fremd belegtem Slug bleibt es beim alten Verhalten. Der API-Nutzer wird `member` der Firma. Nebenbefund: `status = rejected` im Altbestand heißt „offline genommen", nicht „abgelehnt" (83 000 davon mit Aufrufen) — Auswertungen dürfen das nicht als Ablehnung lesen.
Für selbst angelegte Firmendaten trägt der Nutzer die Verantwortung. Für die rückwirkende Zusammenführung im Altbestand trägt sie das Portal, weil dort nicht angelegt, sondern verschmolzen wird. Deshalb 1a.1 vor 1a.3.
### 1b Newsroom als Produkt