Add activity push notifications and registration patches
This commit is contained in:
@@ -4,4 +4,6 @@ Die Android-App ist ein Capacitor-Wrapper der Web-App. Die Package ID bleibt dau
|
||||
|
||||
Versionen im Repository: Capacitor 6.2.1, Push Notifications 6.0.5, Android Gradle Plugin 8.2.1, Gradle 8.2.1 und Firebase Messaging 23.3.1. Der übliche Ablauf ist `npm install`, `npm run sync` und `npm run build` im Verzeichnis `android`. Das Android-Projekt kann unter `android/android` in Android Studio geöffnet werden.
|
||||
|
||||
Die lokale `google-services.json` ist für den Firebase-Build erforderlich, wird aber ignoriert und nie eingecheckt. FCM-Registrierung, Berechtigungsdialog, Session-Bindung und Debug-Token-Anzeige sind implementiert. Ein serverseitiger Versand von Push-Nachrichten ist noch nicht implementiert.
|
||||
Die lokale `google-services.json` ist für den Firebase-Build erforderlich, wird aber ignoriert und nie eingecheckt. FCM-Registrierung, Berechtigungsdialog, Session-Bindung und Debug-Token-Anzeige sind implementiert. Automatischer Backend-Versand ist nach [Firebase-Einrichtung](Firebase.md) aktivierbar. Die per WebView geladene JavaScript-Datei verarbeitet Antippen und Vordergrundhinweise; für diese Erweiterung ist keine neue native APK nötig.
|
||||
|
||||
Ein Release-APK muss vor Installation signiert werden. `assembleRelease` erzeugt ohne Signing-Konfiguration eine **nicht installierbare** `app-release-unsigned.apk`. Für einen Test kann der lokale Debug-Keystore signieren; dies ist keine Produktionssignatur. Mit `apksigner verify` prüfen, nie Schlüssel ins Repository übernehmen.
|
||||
|
||||
@@ -8,9 +8,11 @@ flowchart TD
|
||||
FastAPI --> Uploads[Docker Volumes: Uploads]
|
||||
FastAPI --> External[Nominatim / externe Dienste]
|
||||
FastAPI --> Gitea[Gitea REST API]
|
||||
FastAPI --> Worker[Push-Worker / DB-Warteschlange]
|
||||
Worker --> FCM
|
||||
Android --> FCM[Firebase Cloud Messaging]
|
||||
```
|
||||
|
||||
Das Backend in `app/main.py` rendert Jinja2-Templates und liefert CSS und JavaScript aus `app/static`. Authentifizierung basiert auf serverseitigen Sessions; der Browser bzw. die Android-WebView spricht ausschließlich mit MetalCircle. PostgreSQL enthält Benutzer, Veranstaltungen, Venues, Community-Daten, Diary, Patches und Push-Geräte.
|
||||
|
||||
Dateien werden in den Compose-Volumes `concert_uploads` und `private_uploads` gehalten. Die Android-App ist ein Capacitor-Wrapper derselben Webanwendung. Firebase wird derzeit für Android-FCM-Registrierung genutzt; ein serverseitiger Push-Versand ist noch nicht aktiviert. Der Bugreporter ist die einzige Backend-Komponente mit Gitea-Zugriff.
|
||||
Dateien werden in den Compose-Volumes `concert_uploads` und `private_uploads` gehalten. Die Android-App ist ein Capacitor-Wrapper derselben Webanwendung. Ein optionaler Worker im FastAPI-Prozess sendet FCM-Nachrichten aus einer PostgreSQL-Warteschlange. Bis zur Zugangseinrichtung ist er standardmäßig deaktiviert. Der Bugreporter ist die einzige Backend-Komponente mit Gitea-Zugriff.
|
||||
|
||||
@@ -10,6 +10,20 @@ Attendance-Patches werden als Upgrade-System vergeben:
|
||||
| 50 | 50 Gigs |
|
||||
| 100 | 100 Gigs |
|
||||
|
||||
Im Profil wird nur der höchste erreichte Attendance-Patch sichtbar; der höhere ersetzt die niedrigeren Stufen. Weitere definierte Patches sind Gründer/Capt’n, Pit Wächter, Capt’n’s Mate, Border Breaker, Globe Banger und Alpha Tester. Zusätzlich existieren venue- und ereignisbezogene Auszeichnungen im Code.
|
||||
Im Profil wird nur der höchste erreichte Attendance-Patch sichtbar; der höhere ersetzt die niedrigeren Stufen. Weitere definierte Patches sind Gründer, Admin, Captns Mate, Border Breaker und Globe Banger. Zusätzlich existieren venue- und ereignisbezogene Auszeichnungen im Code.
|
||||
|
||||
## Exklusive Registrierungs-Patches
|
||||
|
||||
| Rang | Registrierungsdatum (Europe/Berlin) | Patch |
|
||||
|---:|---|---|
|
||||
| 1 | bis einschließlich 31.10.2026 | Alpha Tester |
|
||||
| 2 | 01.11.2026 bis einschließlich 31.12.2026 | Beta Tester |
|
||||
| 3 | ab 01.01.2027 | Early Bird |
|
||||
|
||||
Entscheidend ist das ursprüngliche Registrierungsdatum. Alpha-Mitglieder bekommen keinen Beta- oder Early-Bird-Patch hinzu. Bereits vergebene Beta-Patches früher Mitglieder werden beim Start rückwirkend zu Alpha korrigiert. Ein Datenbankindex verhindert gleichzeitige Registrierungsstufen.
|
||||
|
||||
`ALPHA_TESTER_UNTIL` und `BETA_TESTER_UNTIL` konfigurieren die inklusive letzte Tagesgrenze. Early Bird beginnt am Folgetag der Beta-Grenze und hat aktuell kein Enddatum. Änderungen werden beim nächsten App-Start und bei der Profilberechnung abgeglichen. Historische zeitzonenlose `users.created_at`-Werte werden aus der PostgreSQL-Sitzungszeitzone (lokal UTC) nach Europe/Berlin umgerechnet. Eine spätere Änderung der DB-Zeitzone muss die Interpretation historischer Werte berücksichtigen. Implementierung: `app/community_badges.py`; Migration 22 ergänzt den exklusiven Index.
|
||||
|
||||
Alpha erhält einen goldenen Schild mit Krone und den höchsten visuellen Rang. Beta verwendet den bestehenden Patch mit silbernem Rahmen; Early Bird erhält einen bronzenen Vogel-Schild. Standardgrafiken liegen als SVG unter `app/static/images`; Admin-Uploads haben Vorrang.
|
||||
|
||||
Die Vergabe wird aus Konzertbesuchen und den jeweiligen Triggern berechnet. Patch-Bilder können Administratoren verwalten und liegen als Uploads. Neue Vergabelogik muss zuerst in den Definitionen und Tests nachvollziehbar ergänzt werden.
|
||||
|
||||
@@ -13,5 +13,11 @@
|
||||
| `GITEA_TOKEN` | Token des `metalcircle-bot` | erforderlich, geheim |
|
||||
| `GITEA_OWNER` | Repository-Owner, aktuell `kai` | erforderlich |
|
||||
| `GITEA_REPO` | Repository, aktuell `pingu-concerts` | erforderlich |
|
||||
| `PUSH_ENABLED` | Hintergrundversand und neue Versandaufträge aktivieren | optional, Standard `false` |
|
||||
| `FIREBASE_PROJECT_ID` | tatsächliche Firebase-Projekt-ID | bei aktiviertem Versand erforderlich |
|
||||
| `FIREBASE_SERVICE_ACCOUNT_FILE` | absoluter Host-Pfad zur privaten Service-Account-Datei | für `compose.push.yml` erforderlich |
|
||||
| `GOOGLE_APPLICATION_CREDENTIALS` | Containerpfad zur Service-Account-Datei | durch `compose.push.yml` gesetzt |
|
||||
| `ALPHA_TESTER_UNTIL` | inklusive Alpha-Registrierungsgrenze | Standard `2026-10-31` |
|
||||
| `BETA_TESTER_UNTIL` | inklusive Beta-Registrierungsgrenze, nach Alpha | Standard `2026-12-31` |
|
||||
|
||||
`.env.example` enthält nur Platzhalter. `.env` wird nie committed. `google-services.json` liegt ausschließlich lokal im Android-App-Modul und wird durch `.gitignore` ausgeschlossen.
|
||||
|
||||
@@ -11,5 +11,8 @@ Wichtige Beziehungen:
|
||||
- `user_badges` enthält Badges und optionale auslösende Konzerte.
|
||||
- `push_devices` bindet Android-FCM-Tokens an Benutzer und die aktuelle Session.
|
||||
- `bug_report_submissions` enthält ausschließlich kurzlebige Status-/Nonce-Metadaten zur Duplicate-Vermeidung, keine vollständigen Issues.
|
||||
- `notification_preferences` enthält DE/EN und individuelle Push-Kategorien (Migration 21).
|
||||
- `push_notifications` enthält transaktionale Aufträge je Gerät/Session, ohne Klartext-Token oder Nachrichteninhalt (Migration 21). Logout löscht sie per Fremdschlüssel; Aufbewahrung siehe [Push Notifications](Push-Notifications.md).
|
||||
- Migration 22 erlaubt per partiellem Unique-Index nur einen Alpha-/Beta-/Early-Bird-Patch je Nutzer. Die datumsabhängige Rückbefüllung erfolgt konfigurierbar beim App-Start.
|
||||
|
||||
Primäre Indizes unterstützen Konzertdatum, Venue-Suche, Kommentare, Fotos, Attendance, Nachrichten und Einladungen. Backups und Wiederherstellung der PostgreSQL-Daten sind umgebungsabhängig und werden nicht durch diese Repository-Migrationen automatisiert.
|
||||
|
||||
@@ -8,7 +8,7 @@ Docker/Compose, Git sowie für Android Node.js/npm, JDK 17, Android SDK und ein
|
||||
|
||||
```bash
|
||||
cp .env.example .env
|
||||
docker compose up --build
|
||||
COOKIE_SECURE=false docker compose up --build
|
||||
docker compose logs -f web
|
||||
docker compose down
|
||||
```
|
||||
@@ -19,10 +19,12 @@ Die Web-App läuft auf Port 8080, PostgreSQL im Compose-Netzwerk. Die Datenbank
|
||||
|
||||
```bash
|
||||
docker compose run --rm --no-deps -e METALCIRCLE_TEST_DATABASE=1 \
|
||||
-v "$PWD/app:/app" -v "$PWD/db/migrations:/test-migrations:ro" \
|
||||
-v "$PWD/app:/app" -v "$PWD/db/migrations:/test-migrations:ro" -v "$PWD/db/init:/test-init:ro" \
|
||||
web python -m unittest discover -s tests -v
|
||||
```
|
||||
|
||||
Nur gegen die lokale Testdatenbank ausführen: Die Tests erstellen und entfernen isolierte Schemas. Firebase wird simuliert, Service-Account-Dateien sind dafür nicht nötig. Frontend-Prüfung: `node --test app/tests/native_push.test.cjs`.
|
||||
|
||||
## Android lokal
|
||||
|
||||
```bash
|
||||
|
||||
@@ -0,0 +1,55 @@
|
||||
# ChatGPT-Prompt: Firebase-Zugang für MetalCircle
|
||||
|
||||
Den folgenden Prompt in einen neuen Chat kopieren. Keine Secret-Dateien mitgeben.
|
||||
|
||||
```text
|
||||
Hilf mir Schritt für Schritt, den serverseitigen Firebase-Zugang für MetalCircle
|
||||
im Entwicklungs-/Testbetrieb einzurichten. Verwende aktuelle offizielle
|
||||
Firebase-/Google-Cloud-Dokumentation und erkläre mir die Console-Bedienung.
|
||||
|
||||
Ausgangslage:
|
||||
- Privates Projekt MetalCircle, Repository historisch kai/pingu-concerts.
|
||||
- Android: Capacitor 6, Package ID dauerhaft de.pinguholic.concerts.
|
||||
- Firebase-Anzeigename MetalCircle; die tatsächliche Projekt-ID muss ich prüfen.
|
||||
- Android-google-services.json ist vorhanden. Tokenregistrierung und manuelle
|
||||
Firebase-Testnachrichten/Kampagnen funktionieren bereits.
|
||||
- Backend: FastAPI, PostgreSQL, Docker Compose, firebase-admin Python 7.1.0.
|
||||
- Pushs für Freundschaftsanfragen, Direktnachrichten und Einladungen sind implementiert.
|
||||
Kategorien und DE/EN werden pro Empfänger beachtet; Nachrichteninhalt bleibt privat.
|
||||
- Versand ist standardmäßig deaktiviert und wurde mit simuliertem Firebase getestet.
|
||||
|
||||
Bitte begleite mich bei:
|
||||
1. Auswahl des Projekts und Ermittlung der tatsächlichen Projekt-ID.
|
||||
2. Prüfung/Aktivierung der Firebase Cloud Messaging API HTTP v1.
|
||||
3. Einem eigenen Test-Service-Account, z. B. metalcircle-push-test, mit den für FCM
|
||||
nötigen Rechten. Prüfe roles/firebasecloudmessaging.admin bzw.
|
||||
cloudmessaging.messages.create. Kein persönliches Admin-Konto verwenden.
|
||||
4. Erstellung und sicherer Ablage der Service-Account-JSON außerhalb von Repository
|
||||
und Docker-Buildkontext. Nur der Betreiber soll die Datei lesen können.
|
||||
5. Lokaler .env-Konfiguration:
|
||||
PUSH_ENABLED=true
|
||||
FIREBASE_PROJECT_ID=<echte Projekt-ID>
|
||||
FIREBASE_SERVICE_ACCOUNT_FILE=<absoluter Pfad zur Secret-Datei>
|
||||
6. Start mit compose.yml plus compose.push.yml. Dieses Override mountet die Datei
|
||||
read-only unter /run/secrets/firebase-service-account.json und setzt im Backend
|
||||
GOOGLE_APPLICATION_CREDENTIALS auf diesen Pfad.
|
||||
Lokal HTTP: COOKIE_SECURE=false docker compose -f compose.yml -f compose.push.yml up -d --build web
|
||||
Auf einem HTTPS-Testserver bleibt COOKIE_SECURE=true.
|
||||
7. End-to-End-Test mit zwei Testkonten: Anfrage, Nachricht, Veranstaltungseinladung,
|
||||
DE/EN, Kategorien, Antippen, Logout und Benutzerwechsel.
|
||||
|
||||
Grenzen:
|
||||
- Niemals Schlüssel, Tokens, vollständige .env oder JSON-Inhalte im Chat anfordern.
|
||||
- google-services.json ist Client-Konfiguration, kein Backend-Service-Account.
|
||||
- Keine Legacy-Server-Keys und keine Admin-Credentials in der Android-App.
|
||||
- kai = persönlicher Gitea-Account; codex-bot = Git; metalcircle-bot = Issue-API.
|
||||
Keinen dieser Zugänge für Firebase verwenden.
|
||||
- PinguCore ist lokal. Cloud-Staging betreue ich separat. Kein automatischer
|
||||
Cloud-/Produktionszugriff oder Produktionsdeployment.
|
||||
- Test und Produktion bekommen getrennte Credentials.
|
||||
- Verbietet eine Organisationsrichtlinie JSON-Schlüssel, umgehe sie nicht.
|
||||
Erkläre die vorgesehenen Alternativen und welche Code-Anpassung nötig wäre.
|
||||
|
||||
Frage zuerst nur nach der Ziel-Testumgebung und gehe dann schrittweise vor.
|
||||
Prüfe Ergebnisse anhand ungefährlicher Statusangaben, niemals Secret-Inhalte.
|
||||
```
|
||||
+36
-2
@@ -1,5 +1,39 @@
|
||||
# Firebase
|
||||
|
||||
Das Firebase-Projekt heißt **MetalCircle**. Firebase wird aktuell für Android-Firebase Cloud Messaging verwendet: Die App fragt die Benachrichtigungsberechtigung an, erhält einen FCM-Token und registriert ihn beim MetalCircle-Backend. Das Backend speichert Geräte-/Session-Zuordnungen, versendet aber in dieser Phase keine Nachrichten.
|
||||
Das Firebase-Projekt heißt **MetalCircle**. Android ist dauerhaft als `de.pinguholic.concerts` registriert. Manuelle Testnachrichten funktionieren bereits. Automatischer Versand für Freundschaftsanfragen, Direktnachrichten und Veranstaltungseinladungen ist implementiert und benötigt einen separaten serverseitigen Zugang sowie `PUSH_ENABLED=true`.
|
||||
|
||||
`android/android/app/google-services.json` ist eine lokale Konfigurationsdatei und durch `.gitignore` ausgeschlossen. Firebase-Client-Konfiguration ist kein Ersatz für Server-Secrets; Service-Accounts, Admin-Schlüssel und Tokens gehören weder ins Repository noch in Issues oder Logs.
|
||||
## Unterschiedliche Konfigurationsdateien
|
||||
|
||||
- `android/android/app/google-services.json`: lokale, Git-ignorierte Android-Client-Konfiguration. Projekt-/App-Kennungen und der Client-API-Key werden vom Build in die APK übernommen; sie sind kein Backend-Privatschlüssel.
|
||||
- **Service-Account-JSON**: privater Schlüssel für das Backend. Niemals in Git, APK, Docker-Image, Webassets, Chat, Wiki oder Logs aufnehmen. Die Android-Datei ersetzt diesen Zugang nicht.
|
||||
|
||||
## Entwicklung/Test einrichten
|
||||
|
||||
1. In Firebase **MetalCircle** auswählen und die tatsächliche **Projekt-ID** notieren; sie kann vom Anzeigenamen abweichen.
|
||||
2. In der zugehörigen Google Cloud Console die **Firebase Cloud Messaging API (HTTP v1)** prüfen/aktivieren.
|
||||
3. Einen eigenen Test-Service-Account anlegen, z. B. `metalcircle-push-test`. Für Versand ist `cloudmessaging.messages.create` nötig, enthalten in **Firebase Cloud Messaging API Admin** (`roles/firebasecloudmessaging.admin`). Keine persönlichen oder Gitea-Zugänge verwenden. Siehe [Firebase IAM](https://firebase.google.com/docs/projects/iam/permissions) und [FCM-Rollen](https://docs.cloud.google.com/iam/docs/roles-permissions/firebasecloudmessaging).
|
||||
4. Für diesen Account einen JSON-Schlüssel erstellen und geschützt **außerhalb des Repositories und Docker-Buildkontexts** speichern. Der Betreiber verwaltet den Schlüssel. [Firebase Admin Setup](https://firebase.google.com/docs/admin/setup) beschreibt Service-Account-Dateien.
|
||||
5. Dateirechte einschränken, beispielsweise `chmod 600 /absoluter/pfad/firebase-service-account.json`. Keine Inhalte ausgeben.
|
||||
6. In der lokalen `.env` die folgenden Werte selbst eintragen:
|
||||
|
||||
```dotenv
|
||||
PUSH_ENABLED=true
|
||||
FIREBASE_PROJECT_ID=<tatsaechliche-test-projekt-id>
|
||||
FIREBASE_SERVICE_ACCOUNT_FILE=/absoluter/pfad/firebase-service-account.json
|
||||
```
|
||||
|
||||
7. In der eigenen lokalen HTTP-Testumgebung starten:
|
||||
|
||||
```bash
|
||||
COOKIE_SECURE=false docker compose -f compose.yml -f compose.push.yml up -d --build web
|
||||
```
|
||||
|
||||
`compose.push.yml` bindet die Datei schreibgeschützt unter `/run/secrets/firebase-service-account.json` ein und setzt dort `GOOGLE_APPLICATION_CREDENTIALS` für das Backend. Die Quelldatei muss existieren. Der Sender prüft, dass `FIREBASE_PROJECT_ID` zum Account passt. Die Android-App muss dasselbe Firebase-Projekt nutzen.
|
||||
|
||||
Cloud-Staging richtet der Betreiber separat ein; dort hinter HTTPS `COOKIE_SECURE=true` lassen. Codex auf PinguCore greift nicht automatisch darauf zu. Produktion bekommt später eigene Credentials, keine kopierten Testschlüssel.
|
||||
|
||||
## Prüfen
|
||||
|
||||
Mit zwei Testkonten den Ablauf unter [Push Notifications](Push-Notifications.md) prüfen. Logs enthalten feste Kategorien wie `configuration`, `transient` oder `unregistered`. Bei `configuration` Mount, Projekt-ID, API-Aktivierung und Rechte prüfen. Keine Legacy-Server-Keys einsetzen.
|
||||
|
||||
Der echte Backend-Integrationstest steht aus, solange kein Test-Service-Account hinterlegt ist. Automatisierte Tests simulieren Firebase und bestätigen nicht die Berechtigungen eines künftig erstellten Accounts.
|
||||
|
||||
@@ -16,6 +16,8 @@ MetalCircle ist eine private, invite-only Konzert-Community. Dieses Wiki ergänz
|
||||
- [Photos and Uploads](Photos-and-Uploads.md)
|
||||
- [Android App](Android-App.md)
|
||||
- [Firebase](Firebase.md)
|
||||
- [Push Notifications](Push-Notifications.md)
|
||||
- [Firebase Setup Prompt](Firebase-Setup-Prompt.md)
|
||||
- [Deployment](Deployment.md)
|
||||
- [Gitea Workflow](Gitea-Workflow.md)
|
||||
- [Issues and Bug Reporting](Issues-and-Bug-Reporting.md)
|
||||
|
||||
@@ -0,0 +1,31 @@
|
||||
# Push Notifications
|
||||
|
||||
## Umfang und Einstellungen
|
||||
|
||||
Automatische Android-Pushs gibt es für neue Freundschaftsanfragen, Direktnachrichten und Veranstaltungseinladungen. Allgemeine Konzertänderungen und Kommentare lösen keine Pushs aus. Manuelle Firebase-Kampagnen sind getrennt und beachten die MetalCircle-Einstellungen nicht.
|
||||
|
||||
`PUSH_ENABLED=false` ist der Standard. Erst nach [Firebase-Einrichtung](Firebase.md) wird der Versand aktiviert; während er deaktiviert ist, entstehen keine Versandaufträge für historische Aktivitäten.
|
||||
|
||||
Im eigenen Profil lassen sich die drei Kategorien getrennt einstellen. Die Einstellungen gelten für alle angemeldeten Android-Geräte des Kontos; Android muss zusätzlich Benachrichtigungen erlauben. Ausschalten verwirft ausstehende Meldungen dieser Kategorie. Die zuletzt bei Anmeldung, Geräteanmeldung oder Sprachwechsel gewählte Sprache wird pro Konto in `notification_preferences.language` gespeichert. Der einzelne Sprachbutton bietet jeweils die andere Sprache DE/EN an.
|
||||
|
||||
Pushs enthalten generische Texte, etwa „Neue Nachricht – Du hast eine neue Nachricht.“ Namen, Nachrichtentext und Veranstaltungstitel werden nicht auf den Sperrbildschirm übertragen. Android erhält eine zufällige Versandkennung und die Bindung an die aktuelle Sitzung. Im Vordergrund zeigt die WebView einen Hinweis zum Öffnen an; im Hintergrund übernimmt Android die Systembenachrichtigung.
|
||||
|
||||
Beim Antippen prüft die App die Sitzung. `/notifications/{id}` prüft erneut Empfänger, Sitzung und Berechtigung und leitet zur Unterhaltung, Anfrage oder Veranstaltung weiter. Bereits gelesene Nachrichten, erledigte Anfragen, entfernte Einladungen oder blockierte Kontakte führen zur Übersicht.
|
||||
|
||||
## Versand und Fehlerfälle
|
||||
|
||||
Aktivität und Versandauftrag werden in derselben PostgreSQL-Transaktion gespeichert. Ein Hintergrund-Thread im FastAPI-Prozess verarbeitet `push_notifications`; ein zusätzlicher Broker oder Container ist nicht nötig. Mehrere Prozesse reservieren Aufträge über Zeilensperren und `SKIP LOCKED`.
|
||||
|
||||
Aufträge entstehen nur für aktuell registrierte Geräte. Sie enthalten Geräte-/Session-Referenzen und einen Token-Fingerabdruck, keine Klartext-Tokens oder Nachrichteninhalte. Vor Versand werden Kategorie, Blockierungen, offener/ungelesener Zustand, Berechtigungen, Token und Sitzung geprüft. Geräte-/Session-Sperren koordinieren den Versand mit Logout und Tokenänderungen. Logout löscht Zuordnungen und Aufträge über Fremdschlüssel.
|
||||
|
||||
Firebase Admin SDK 7.1.0 sendet über FCM. Vorübergehende Fehler und Konfigurationsfehler erhalten maximal drei Wiederholungen nach 60, 120 und 240 Sekunden. Nach vier Versuchen wird der Auftrag als fehlgeschlagen markiert. Nicht registrierte Tokens werden entfernt; Projekt-/Authentifizierungsfehler löschen keine Geräte. Logs enthalten nur feste Fehlerkategorien.
|
||||
|
||||
Aufträge verfallen nach einer Stunde; FCM erhält fünf Minuten Gültigkeit. Der laufende Worker bereinigt Metadaten nach sieben Tagen (keine Bereinigung, solange er deaktiviert ist). Bei einem Prozessabbruch nach Firebase-Annahme und vor DB-Commit sind Doppelzustellungen nicht vollständig auszuschließen; die stabile Android-Kennung ersetzt Wiederholungen im Benachrichtigungsbereich.
|
||||
|
||||
Bereits zugestellte Meldungen lassen sich serverseitig nicht zurückrufen. Die App leert eigene Benachrichtigungen beim Sitzungswechsel; generische Texte und Zielprüfung schützen zusätzlich. Ein kleiner Zeitraum zwischen letzter Berechtigungsprüfung und Netzwerkzustellung bleibt technisch bestehen.
|
||||
|
||||
## Tests
|
||||
|
||||
Automatisierte Tests nutzen isolierte lokale PostgreSQL-Schemas und simuliertes Firebase; sie senden keine echten Pushs. Nach der Zugangseinrichtung mit zwei Testkonten prüfen: Anfrage A → B, Freundschaft annehmen und Nachricht senden, private Veranstaltung mit Einladung für B; Vordergrund/Hintergrund, Antippen, EN/DE, Kategorien, Blockierung, entfernte Einladung sowie Logout/Benutzerwechsel. Keine Produktionsaktivitäten dafür verwenden.
|
||||
|
||||
Ein [fertiger ChatGPT-Prompt](Firebase-Setup-Prompt.md) begleitet die Einrichtung.
|
||||
@@ -4,7 +4,7 @@ Die folgenden Punkte sind aus dem aktuellen Produktstand und den vorhandenen Fun
|
||||
|
||||
- Community-, Profil-, Attendance- und Interest-Funktionen weiter ausbauen
|
||||
- Kommentare, Diary und Fotoalben vervollständigen
|
||||
- Android-App und FCM-Benachrichtigungen weiter testen; serverseitigen Push-Versand separat planen
|
||||
- Android-App und den implementierten serverseitigen Push-Versand nach der Firebase-Zugangseinrichtung live testen
|
||||
- weitere Patches und Gamification nach klarer Vergabelogik ergänzen
|
||||
|
||||
Eintragungen hier sind Planung. Sie gelten erst als umgesetzt, wenn Code, Migrationen und Tests vorhanden sind.
|
||||
|
||||
@@ -5,5 +5,5 @@
|
||||
- **Venue-Suche leer oder langsam:** Nominatim ist extern und rate-limited; manuelle Venue-Daten können verwendet werden.
|
||||
- **Upload scheitert:** Dateityp, Größe, Schreibrechte und die Compose-Volumes prüfen.
|
||||
- **Android-Sync schlägt fehl:** Node/npm, JDK, Android SDK und die lokale ignorierte `google-services.json` prüfen.
|
||||
- **FCM fehlt:** App-Berechtigung und Firebase-Konfiguration prüfen; Push-Versand ist aktuell nicht serverseitig aktiviert.
|
||||
- **FCM fehlt:** Android-Berechtigung, Kategorie im Profil, `PUSH_ENABLED`, Projekt-ID und Service-Account-Mount prüfen. Client-Konfiguration allein reicht nicht für Backend-Versand. Siehe [Firebase](Firebase.md).
|
||||
- **Bugreport kann nicht gesendet werden:** Gitea-URL, Bot-Token und Repository-Konfiguration nur lokal prüfen; Secrets nie in Logs kopieren.
|
||||
|
||||
Reference in New Issue
Block a user