diff --git a/dev/archive/betrieb/deploy-v1.12.0.md b/dev/archive/betrieb/deploy-v1.12.0.md index c95c0c3b..61852b99 100644 --- a/dev/archive/betrieb/deploy-v1.12.0.md +++ b/dev/archive/betrieb/deploy-v1.12.0.md @@ -5,11 +5,12 @@ **Inhalt** (Roadmap [6.17](../../roadmap.md)): - **Veröffentlichungsmail an Empfänger ohne Konto** (API-Meldungen an Pressekontakt oder Firmen-E-Mail): Kasten „Etwas ändern oder die Aufrufe sehen?“ mit der Adresse der Mail und dem Knopf „Anmeldelink anfordern“. Der bisherige Text „in Ihrem Konto … mit Passwort oder Magic-Link“ entfällt. -- **Ablehnungsmail an Empfänger ohne Konto:** Meldung und Ablehnungsgrund lassen sich so ansehen. Die überarbeitete Fassung geht „auf demselben Weg“ ein (siehe Roadmap 6.18). +- **Ablehnungsmail an Empfänger ohne Konto:** „Sie können die Meldung selbst überarbeiten und kostenlos erneut einreichen“, mit Anmeldelink (Entscheidung 14.10.2026, Roadmap 6.18). +- **Behoben:** Die Ergebnismail nach einer Wiedereinreichung durch den Pressekontakt wäre an das Konto des Einlieferers gegangen (connektar). Jetzt gilt eine Meldung als API-Meldung, sobald sie einmal über die API eingereicht wurde, und die Mail geht an den Kontakt. - **Kunden mit eigenem Konto:** Knopf „Im pressekonto öffnen“ bzw. wie bisher „Pressemitteilung bearbeiten“. - **Neue Seite `pressekonto.com/zugang`:** nur über den signierten Link aus der Mail (30 Tage gültig, die Adresse steht verschlüsselt im Link). Ein Klick schickt den Anmeldelink an genau diese Adresse, höchstens 3 pro Stunde. Die Anmeldung landet auf der Meldung. Gemessen wird in den Trichterstufen 2 und 3. -**Umfang:** keine Migration, keine neuen `.env`-Werte, kein Asset-Diff, Scheduler unverändert. Suite 2.554 grün, einer übersprungen; Larastan ohne Meldung. +**Umfang:** keine Migration, keine neuen `.env`-Werte, kein Asset-Diff, Scheduler unverändert. Suite 2.555 grün, einer übersprungen; Larastan ohne Meldung. ## Deploy diff --git a/dev/roadmap.md b/dev/roadmap.md index d200db62..57659b99 100644 --- a/dev/roadmap.md +++ b/dev/roadmap.md @@ -183,7 +183,7 @@ aber nirgends belegt. | 6.15 | Partnervorlage (Gutscheine, Kontingent gegen Naturalleistung, Provision mit Codes, Interessenkonflikt-Kennzeichnung, Pilot 6 Monate mit Nullmessung) für künftige Partner bereithalten — kein Code, bis ein Partner konkret wird. | [Decision-Update Spitze ohne Partner §6](partner/decision-update_spitze-ohne-partner.md) | [EXTERN] | | ~~6.16~~ | ~~Messung und Seite „Wachstum“~~ — **live mit v1.10.0 (13.10.2026):** (a) „Magic Link eingelöst“ trägt Firma und Meldung aus dem Token; (b) neue Stufen „Verwaltungsseite geöffnet“ und „Anmeldelink angefordert“ (Leiter mit 7 Stufen); (c) Erstbuchung mit der Herkunft des letzten eingelösten Links; (d) Admin ▸ Reports ▸ Wachstum und `growth:report` mit den Bedingungen aus 6.1; Umami nur lesend über `UMAMI_API_*`, Befehl `umami:report`. Deploy-Notiz: [`archive/betrieb/deploy-v1.10.0.md`](archive/betrieb/deploy-v1.10.0.md). | Abgleich 13.10.2026 | — | | ~~6.17~~ | ~~Klarheit des Verwaltungszugangs~~ — **erledigt mit v1.11.0/v1.12.0:** Newsroom-Seite mit Kasten statt grauer Zeile; Firmenseiten „Firma & Newsroom“ mit Link zum öffentlichen Newsroom (Backend sagt weiter „Firma“); Veröffentlichungs- und Ablehnungsmail an Empfänger ohne Konto mit Kasten „Etwas ändern oder die Aufrufe sehen?“ und Knopf „Anmeldelink anfordern“ (signierter Link auf `/zugang`, Anmeldelink an genau die Adresse der Mail, Landung auf der Meldung). E4 (15.09.: Verwaltungshinweis nur am Mailende) damit bewusst geändert: Der Kasten ist kein Angebot, sondern der Weg zur eigenen Meldung. Wirkung über die Stufen 2–4 beobachten (`conversion:funnel`, Herkunft Veröffentlichungs-/Ablehnungsmail). Noch gleich gebaut wie vorher: die Mail „ein Mensch prüft“ (`PressReleaseHeldForReview`) an API-Empfänger. | Betreiber 13.10.2026 | — | -| 6.18 | **Wiedereinreichung abgelehnter API-Meldungen durch Pressekontakte.** Ein Kontakt mit Firmenzugang darf eine abgelehnte API-Meldung heute überarbeiten und neu einreichen (`PressReleasePolicy::submitForReview`, Autor ODER Firmenmitglied); geprüft werden aber Buchung und Kontingent des **Einlieferers** (`PressReleaseService::submitForReview` → `$pressRelease->user`, z. B. connektar). Die Ablehnungsmail bietet das seit v1.12.0 nicht mehr an, der Weg im Kundenbereich besteht weiter. Entscheiden: sperren (nur der Einlieferer reicht API-Meldungen neu ein) oder auf eigenes Kontingent des Kontakts umstellen. | Code-Prüfung 13.10.2026 | S | +| ~~6.18~~ | ~~Wiedereinreichung abgelehnter API-Meldungen durch Pressekontakte~~ — **entschieden 14.10.2026, umgesetzt mit v1.12.0:** Der Pressekontakt überarbeitet eine abgelehnte API-Meldung über den Anmeldelink selbst und reicht sie kostenlos erneut ein (kein Slot, solange nichts veröffentlicht ist; die Buchungsprüfung läuft weiter gegen den Einlieferer). Die Ablehnungsmail sagt das. Dabei behoben: Das Mail-Routing las die Herkunft aus dem letzten Review-Übergang — nach einer Wiedereinreichung im Kundenbereich wäre das Ergebnis an das Konto des Einlieferers gegangen statt an den Kontakt. | Code-Prüfung 13./14.10.2026 | — | | 6.19 | **Änderungsregel und Datenschutz.** Heute: kostenlose Korrektur bis 5 % Abweichung je Feld, einmal pro Woche (`legal.correction_max_distance_percent`, `legal.corrections_per_week`); bezahlte Änderung 10 € bis 50 %, einmal je Meldung. Eine Ausnahme für personenbezogene Daten gibt es im Code **nicht** — das Entfernen einer Telefonnummer oder eines Namens zählt wie jede andere Änderung, obwohl DSE/AGB und `handover_loesch-anfragen.md` „Kontaktdaten entfernen ist jederzeit kostenlos“ zusagen; den Weg über `/melden` → Admin (`AnonymizationService`) gibt es. Prüfen: Selbstbedienung „Kontaktdaten entfernen“ ohne Prozentgrenze und Wochenlimit (Telefonnummern, E-Mail, Namen natürlicher Personen), Abgleich mit der Anwaltsantwort zu Frage 12. Wiederkehrendes Problem laut Betreiber. | Betreiber 13.10.2026, [Kontext Löschanfragen](rechtliches/handover_loesch-anfragen.md) | M | ---