Admin-Funktionen erweitern #6

Closed
opened 2026-08-11 09:41:52 +02:00 by admin · 6 comments
Owner

Im Admin, bereich benötige ich eine Funktion, Nutzer als Admin anschreiben zu können, dies soll den Kontakt mit mir vereinfachen und mir die möglichkeit geben, bei Verletzung der AGB´s oder des Datenschutzs rückfragen auf kurzen wege via chat zu starten.

Im Admin, bereich benötige ich eine Funktion, Nutzer als Admin anschreiben zu können, dies soll den Kontakt mit mir vereinfachen und mir die möglichkeit geben, bei Verletzung der AGB´s oder des Datenschutzs rückfragen auf kurzen wege via chat zu starten.
Author
Owner

Datenschutz - Download, falls ein Nutzer seine Recht auf Auskunft ausüben möchte, würde ich dies gerne mittels Nutzer-Auswahl im Admin Menü einfach starten können.
Menü - Suchfunktion Nutzer
Auswahl der Daten -> Alle gesammelten Daten -> Zip Kompremiert -> OneFile via E-Mail an den Nutzer, E-Mail Adresse aus Clerk beziehen. -> Template mit einem Rechtssicheren Text in unserem Design, im Anhang die Datei

PlanB: falls das mit der E-Mail zu kompliziert ist, daten bereitstellung mit ablaufendem Link.

Erst prüfen dann bauen.

Datenschutz - Download, falls ein Nutzer seine Recht auf Auskunft ausüben möchte, würde ich dies gerne mittels Nutzer-Auswahl im Admin Menü einfach starten können. Menü - Suchfunktion Nutzer Auswahl der Daten -> Alle gesammelten Daten -> Zip Kompremiert -> OneFile via E-Mail an den Nutzer, E-Mail Adresse aus Clerk beziehen. -> Template mit einem Rechtssicheren Text in unserem Design, im Anhang die Datei PlanB: falls das mit der E-Mail zu kompliziert ist, daten bereitstellung mit ablaufendem Link. Erst prüfen dann bauen.
Author
Owner

akutell werden, im Admin-Menü unter Users nur die user-id, anzahl der Tiere und deren Namen angezeigt, ist es möglich mehr informationen von clerk zu erhalten ?

akutell werden, im Admin-Menü unter Users nur die user-id, anzahl der Tiere und deren Namen angezeigt, ist es möglich mehr informationen von clerk zu erhalten ?
Author
Owner

Umgesetzt (Teile 1+2, Commit 328e54c, deployed):

  • Mehr Clerk-Daten im Admin-Panel: admin.listUsers holt jetzt per Batch-Call E-Mail und Name aus Clerk und zeigt sie in /p/[secret]/users an.
  • Admin→Nutzer-Chat: Neue Mutation admin.startTeamConversation legt beim ersten Gebrauch ein System-Pet "PawFeed Team" unter ADMIN_OWNER_ID an und nutzt dafür das bestehende Conversation/Message-Modell (Pet-zu-Pet-DMs) weiter — kein neues UI auf Nutzerseite nötig. In der Users-Liste gibt's jetzt einen Chat-Button pro Nutzer.
    • Bekannte Einschränkung: Aktuell kann nur der Account mit ADMIN_OWNER_ID als Team schreiben (Ownership-Check verlangt exakte Übereinstimmung). Für weitere Moderatoren braucht das eine separate Erweiterung.

Recherche (Teil 3 — DSGVO-Art.-15-Export), wie gewünscht nur geprüft, nicht gebaut:

Rechtlicher Rahmen: Antwortfrist 1 Monat (verlängerbar auf 3 bei Komplexität), erste Kopie kostenlos, maschinenlesbares Format bei elektronischer Anfrage (Art. 15 DSGVO).

Was rein müsste: Owner-Stammdaten, alle Pets, Posts+Bilder, aktive Stories, Kommentare/Reaktionen/Reposts, eigene Nachrichten, Follows/Blocks, Health-Daten, Notifications, Reports, Ban-Historie, Consent-Zeitstempel, Clerk-Profildaten.

Harter Gap bei beiden vorgeschlagenen Wegen: Es gibt aktuell keine E-Mail-Versand-Infrastruktur im Projekt (kein Resend/SendGrid/Postmark/Nodemailer) und kein ZIP-Tooling — beides müsste neu eingeführt werden.

  • Plan A (E-Mail-Anhang): ZIP serverseitig bauen (Prisma-Daten + Clerk-Profil + Supabase-Storage-Downloads) und per Mail versenden. Risiko: bei vielen Posts/Videos dauert das Zusammenstellen zu lange für eine synchrone Anfrage; Video-Rohdaten liegen bei Mux und sind nicht ohne Weiteres exportierbar (müsste geprüft werden, ob die mp4_support-Rendition dafür nutzbar ist).
  • Plan B (ablaufender Link): Gleiche Datenaggregation, aber als zeitlich befristeter Download bereitgestellt — kann das bestehende Muster von /health-card/[token] wiederverwenden (tokenisierte, öffentliche Route ohne Auth, bereits produktiv im Code). Geringeres Architekturrisiko. Braucht trotzdem E-Mail, um den Link zuzustellen.

Einschätzung: Plan B auf Basis des Health-Card-Patterns ist der pragmatischere nächste Schritt, sobald eine E-Mail-Versand-Entscheidung getroffen ist (Anbieter, möglichst EU-Standort). Würde ich als eigenes, separates Issue vorschlagen statt in #6 mitzuführen.

**Umgesetzt (Teile 1+2, Commit `328e54c`, deployed):** - **Mehr Clerk-Daten im Admin-Panel:** `admin.listUsers` holt jetzt per Batch-Call E-Mail und Name aus Clerk und zeigt sie in `/p/[secret]/users` an. - **Admin→Nutzer-Chat:** Neue Mutation `admin.startTeamConversation` legt beim ersten Gebrauch ein System-Pet "PawFeed Team" unter `ADMIN_OWNER_ID` an und nutzt dafür das bestehende Conversation/Message-Modell (Pet-zu-Pet-DMs) weiter — kein neues UI auf Nutzerseite nötig. In der Users-Liste gibt's jetzt einen Chat-Button pro Nutzer. - **Bekannte Einschränkung:** Aktuell kann nur der Account mit `ADMIN_OWNER_ID` als Team schreiben (Ownership-Check verlangt exakte Übereinstimmung). Für weitere Moderatoren braucht das eine separate Erweiterung. **Recherche (Teil 3 — DSGVO-Art.-15-Export), wie gewünscht nur geprüft, nicht gebaut:** Rechtlicher Rahmen: Antwortfrist 1 Monat (verlängerbar auf 3 bei Komplexität), erste Kopie kostenlos, maschinenlesbares Format bei elektronischer Anfrage (Art. 15 DSGVO). Was rein müsste: Owner-Stammdaten, alle Pets, Posts+Bilder, aktive Stories, Kommentare/Reaktionen/Reposts, eigene Nachrichten, Follows/Blocks, Health-Daten, Notifications, Reports, Ban-Historie, Consent-Zeitstempel, Clerk-Profildaten. **Harter Gap bei beiden vorgeschlagenen Wegen:** Es gibt aktuell **keine E-Mail-Versand-Infrastruktur** im Projekt (kein Resend/SendGrid/Postmark/Nodemailer) und **kein ZIP-Tooling** — beides müsste neu eingeführt werden. - **Plan A (E-Mail-Anhang):** ZIP serverseitig bauen (Prisma-Daten + Clerk-Profil + Supabase-Storage-Downloads) und per Mail versenden. Risiko: bei vielen Posts/Videos dauert das Zusammenstellen zu lange für eine synchrone Anfrage; Video-Rohdaten liegen bei Mux und sind nicht ohne Weiteres exportierbar (müsste geprüft werden, ob die `mp4_support`-Rendition dafür nutzbar ist). - **Plan B (ablaufender Link):** Gleiche Datenaggregation, aber als zeitlich befristeter Download bereitgestellt — kann das bestehende Muster von `/health-card/[token]` wiederverwenden (tokenisierte, öffentliche Route ohne Auth, bereits produktiv im Code). Geringeres Architekturrisiko. Braucht trotzdem E-Mail, um den Link zuzustellen. **Einschätzung:** Plan B auf Basis des Health-Card-Patterns ist der pragmatischere nächste Schritt, sobald eine E-Mail-Versand-Entscheidung getroffen ist (Anbieter, möglichst EU-Standort). Würde ich als eigenes, separates Issue vorschlagen statt in #6 mitzuführen.
Author
Owner

Zusammenfassung — alle drei Teile abgeschlossen und live verifiziert

1. Mehr Clerk-Daten im Admin-Panel

admin.listUsers holt jetzt per Batch-Call E-Mail und Name aus Clerk und zeigt sie in /p/[secret]/users an, statt nur der nackten User-ID.

2. Admin→Nutzer-Chat ("PawFeed Team")

Neue Mutation admin.startTeamConversation legt bei Bedarf ein System-Pet "PawFeed Team" unter ADMIN_OWNER_ID an und nutzt das bestehende Conversation/Message-Modell weiter — kein neues UI auf Nutzerseite nötig. Chat-Button pro Nutzer in der Users-Liste.

  • Bekannte Grenze: aktuell kann nur der ADMIN_OWNER_ID-Account als Team schreiben (Ownership-Check verlangt exakte Übereinstimmung). Für weitere Moderatoren wäre eine separate Erweiterung nötig.

3. DSGVO-Art.-15-Datenexport (Plan B)

Admin klickt "Export" bei einem Nutzer → Backend sammelt alle Daten (Pets, Posts, Stories, Kommentare, Reaktionen, Reposts, Follows/Blocks, Health-Daten, Nachrichten, Notifications, Reports, Ban-/Consent-Historie, Clerk-Profil) in ein JSON-Bundle → Upload in einen privaten Supabase-Storage-Bucket (getrennt vom öffentlichen Media-Bucket) → 7 Tage gültiger Signed-Link per E-Mail an die Clerk-Adresse. Protokolliert im ModerationLog.

  • Bewusst nicht enthalten (im Export selbst vermerkt): Werbeanzeigen-Interaktionen, ausgegebene Einladungscodes.
  • Bekannte Grenze: läuft synchron, kein automatisches Cleanup alter Export-Dateien im Storage.

Nebenbei aufgetreten: Mail-Versand komplett kaputt (nicht nur für den Export)

Beim ersten Testversand kam ein DMARC-Bounce zurück. Root-Cause-Analyse ergab: pawfeed.org hatte seit der Nameserver-Migration von Strato zu Cloudflare keinen SPF-Record und keine DKIM-Records mehr, obwohl eine strikte DMARC-Policy (p=reject) aktiv war — jede Mail von @pawfeed.org wurde dadurch von jedem DMARC-prüfenden Empfänger hart abgelehnt, nicht nur die Export-Mails. Behoben durch:

  • SPF-TXT-Record (v=spf1 redirect=_spf.strato.com) in Cloudflare ergänzt
  • Zwei DKIM-CNAME-Records (strato-dkim-0002/-0003._domainkey) ergänzt
  • Ein hängender Cloudflare-Edge-Cache-Zustand (TXT-Record am selben Namen wie ein bereits bestehender proxied Root-CNAME) musste per Löschen+Neuanlegen aufgelöst werden

Nach dem Fix: Testmail zugestellt und bestätigt angekommen.

End-to-End-Verifikation (heute durchgeführt)

  1. Export für einen echten Account gebaut (3 Pets, alle Kategorien korrekt befüllt)
  2. In privaten Bucket hochgeladen, Signed-URL erzeugt
  3. Mail mit Link verschickt und Zustellung bestätigt
  4. Link selbst abgerufen: HTTP 200, valides vollständiges JSON (16 KB)

Commits

  • 328e54c — Clerk-Daten + Team-Chat
  • 86ac5f4 — SMTP-Modul
  • f12dec0 — GDPR-Export-Feature

Alle Teile sind deployed und live auf pawfeed.org.

## Zusammenfassung — alle drei Teile abgeschlossen und live verifiziert ### 1. Mehr Clerk-Daten im Admin-Panel `admin.listUsers` holt jetzt per Batch-Call E-Mail und Name aus Clerk und zeigt sie in `/p/[secret]/users` an, statt nur der nackten User-ID. ### 2. Admin→Nutzer-Chat ("PawFeed Team") Neue Mutation `admin.startTeamConversation` legt bei Bedarf ein System-Pet "PawFeed Team" unter `ADMIN_OWNER_ID` an und nutzt das bestehende Conversation/Message-Modell weiter — kein neues UI auf Nutzerseite nötig. Chat-Button pro Nutzer in der Users-Liste. - **Bekannte Grenze:** aktuell kann nur der `ADMIN_OWNER_ID`-Account als Team schreiben (Ownership-Check verlangt exakte Übereinstimmung). Für weitere Moderatoren wäre eine separate Erweiterung nötig. ### 3. DSGVO-Art.-15-Datenexport (Plan B) Admin klickt "Export" bei einem Nutzer → Backend sammelt alle Daten (Pets, Posts, Stories, Kommentare, Reaktionen, Reposts, Follows/Blocks, Health-Daten, Nachrichten, Notifications, Reports, Ban-/Consent-Historie, Clerk-Profil) in ein JSON-Bundle → Upload in einen **privaten** Supabase-Storage-Bucket (getrennt vom öffentlichen Media-Bucket) → **7 Tage gültiger** Signed-Link per E-Mail an die Clerk-Adresse. Protokolliert im ModerationLog. - **Bewusst nicht enthalten** (im Export selbst vermerkt): Werbeanzeigen-Interaktionen, ausgegebene Einladungscodes. - **Bekannte Grenze:** läuft synchron, kein automatisches Cleanup alter Export-Dateien im Storage. ### Nebenbei aufgetreten: Mail-Versand komplett kaputt (nicht nur für den Export) Beim ersten Testversand kam ein DMARC-Bounce zurück. Root-Cause-Analyse ergab: `pawfeed.org` hatte seit der Nameserver-Migration von Strato zu Cloudflare **keinen SPF-Record und keine DKIM-Records** mehr, obwohl eine strikte DMARC-Policy (`p=reject`) aktiv war — jede Mail von `@pawfeed.org` wurde dadurch von jedem DMARC-prüfenden Empfänger hart abgelehnt, nicht nur die Export-Mails. Behoben durch: - SPF-TXT-Record (`v=spf1 redirect=_spf.strato.com`) in Cloudflare ergänzt - Zwei DKIM-CNAME-Records (`strato-dkim-0002`/`-0003._domainkey`) ergänzt - Ein hängender Cloudflare-Edge-Cache-Zustand (TXT-Record am selben Namen wie ein bereits bestehender proxied Root-CNAME) musste per Löschen+Neuanlegen aufgelöst werden Nach dem Fix: Testmail zugestellt und bestätigt angekommen. ### End-to-End-Verifikation (heute durchgeführt) 1. Export für einen echten Account gebaut (3 Pets, alle Kategorien korrekt befüllt) 2. In privaten Bucket hochgeladen, Signed-URL erzeugt 3. Mail mit Link verschickt und Zustellung bestätigt 4. Link selbst abgerufen: HTTP 200, valides vollständiges JSON (16 KB) ### Commits - `328e54c` — Clerk-Daten + Team-Chat - `86ac5f4` — SMTP-Modul - `f12dec0` — GDPR-Export-Feature Alle Teile sind deployed und live auf pawfeed.org.
admin closed this issue 2026-08-11 12:33:04 +02:00
Author
Owner

Den GDPR-Export optimieren,
aktuell wird der Link zum Export auf supabase übergeschrieben, können wir einen zwischenschritt hinzufügen. damit die leute die ihre auskunft holen diese von pawfeed.org erhalten statt von supabase

auf anfrage, pullt der server die daten legt die datei ab, erstellt einen token für das abholen der daten auf dem server (pawfeed.org)

prüfen ob das möglich ist ?

Den GDPR-Export optimieren, aktuell wird der Link zum Export auf supabase übergeschrieben, können wir einen zwischenschritt hinzufügen. damit die leute die ihre auskunft holen diese von pawfeed.org erhalten statt von supabase auf anfrage, pullt der server die daten legt die datei ab, erstellt einen token für das abholen der daten auf dem server (pawfeed.org) prüfen ob das möglich ist ?
admin reopened this issue 2026-08-11 13:31:51 +02:00
Author
Owner

Follow-up umgesetzt: DSGVO-Export-Link läuft jetzt über pawfeed.org statt Supabase

Wie gewünscht (Variante 2 — eigenes DB-gestütztes Token-Modell statt Supabase-Signed-URL):

  • Neues DataExportToken-Modell (Prisma) mit token/storageKey/expiresAt
  • Neue öffentliche Route /api/gdpr-export/[token] (gleiches Muster wie /health-card/[token]) — validiert den Token, lädt die Datei serverseitig via Service-Role-Key von Supabase und streamt sie durch. Die Supabase-URL taucht nie im Browser/E-Mail-Link auf.
  • admin.exportUserData erzeugt jetzt einen DataExportToken statt einer Supabase-Signed-URL und mailt https://pawfeed.org/api/gdpr-export/{token}

Beim Live-Test direkt nach dem Deploy gefunden + gefixt: Die neue Route wurde zunächst von der Clerk-Middleware (src/proxy.ts) abgefangen und auf /sign-in umgeleitet, weil sie nicht im öffentlichen Route-Matcher stand — analog zu /health-card/(.*) ergänzt (Commit 8351382).

End-to-End verifiziert: echten Export über den Admin-Account gebaut, Mail mit dem neuen Link erhalten, Link direkt abgerufen (HTTP 200, valides JSON mit korrektem Content-Disposition: attachment-Header).

Commits: 5e2a11e (Feature), 8351382 (Proxy-Fix). Beide deployed und live auf pawfeed.org.

**Follow-up umgesetzt: DSGVO-Export-Link läuft jetzt über pawfeed.org statt Supabase** Wie gewünscht (Variante 2 — eigenes DB-gestütztes Token-Modell statt Supabase-Signed-URL): - Neues `DataExportToken`-Modell (Prisma) mit `token`/`storageKey`/`expiresAt` - Neue öffentliche Route `/api/gdpr-export/[token]` (gleiches Muster wie `/health-card/[token]`) — validiert den Token, lädt die Datei serverseitig via Service-Role-Key von Supabase und streamt sie durch. Die Supabase-URL taucht nie im Browser/E-Mail-Link auf. - `admin.exportUserData` erzeugt jetzt einen `DataExportToken` statt einer Supabase-Signed-URL und mailt `https://pawfeed.org/api/gdpr-export/{token}` **Beim Live-Test direkt nach dem Deploy gefunden + gefixt:** Die neue Route wurde zunächst von der Clerk-Middleware (`src/proxy.ts`) abgefangen und auf `/sign-in` umgeleitet, weil sie nicht im öffentlichen Route-Matcher stand — analog zu `/health-card/(.*)` ergänzt (Commit `8351382`). **End-to-End verifiziert:** echten Export über den Admin-Account gebaut, Mail mit dem neuen Link erhalten, Link direkt abgerufen (HTTP 200, valides JSON mit korrektem `Content-Disposition: attachment`-Header). Commits: `5e2a11e` (Feature), `8351382` (Proxy-Fix). Beide deployed und live auf pawfeed.org.
admin closed this issue 2026-08-11 14:35:56 +02:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: admin/petfeed#6