94263c6447
Le check-in remplace l'intégration banking V1 (cf. CLAUDE.md → Glossaire) :
avant que la 1re relance ne parte, on demande à l'user "as-tu été payé ?"
via email, et il clique sur l'un des 2 liens publics.
Service checkin_token.ts : génération + hash SHA-256. 32 bytes random base64url, plain dans le mail, hash en DB (CheckinTask.token_hash unique).
Service checkin_scheduler.ts :
- scheduleCheckinForInvoice(invoice) : crée 1 CheckinTask à dueDate (now+1min si dueDate dans le passé). Idempotent par invoice — cancel les scheduled précédents avant.
- cancelCheckinForInvoice(invoiceId) : appelé par mark-paid pour stopper.
Job send_checkin_job.ts : worker queue 'checkins', skip si invoice paid/cancelled (no-op), construit l'URL avec le plain token (passé dans le payload du job, pas relu DB), appelle sendCheckinEmail.
mail_dispatcher.ts : sendCheckinEmail() — texte brut, destinataire = user (pas client !), 2 URLs (paid / pending), TTL 24h annoncé.
Controller CheckinController :
- GET /api/v1/checkin/:token/paid : status=answered + answer=paid + mark invoice paid (mêmes effets que POST /invoices/:id/mark-paid : rubis +1, ActivityEvent invoice_paid avec label "via check-in", cancelFutureRelances). Idempotent : 2e click → redirect "already_answered".
- GET /api/v1/checkin/:token/pending : status=answered + answer=still_pending. Les relances suivent leur cours.
- Validation : lookup hash, expiry (sentAt + 24h), redirects propres pour invalid / expired / already_answered.
Routes : nouveau group public `checkin` (PAS de middleware.auth) à côté du group auth, sous /api/v1.
Triggers branchés :
- InvoicesController.store et ImportBatchesController.validateDraft → scheduleCheckinForInvoice après création
- InvoicesController.markPaid → cancelCheckinForInvoice dans la tx
start/queue.ts : registerWorker('checkins', sendCheckinJob).
env : nouveau WEB_URL (URL du SPA pour redirects), default localhost:5173 en dev.
Bruno : nouveau dossier 08-Checkin avec doc complète du flow + 2 requêtes (paid / pending). var d'env `checkinToken` à remplir manuellement après avoir reçu l'email dans Mailpit.
Rubis API — Collection Bruno
Collection Bruno qui répertorie toutes les routes de l'API et permet de les tester en suivant un parcours réaliste (signup → onboarding → création client → facture → encaissement).
Installation
- Installe Bruno : https://www.usebruno.com/downloads
- Dans Bruno, Open Collection → sélectionne le dossier
bruno/à la racine du repo. - Sélectionne l'environnement local dans le sélecteur en haut à droite.
Démarrer l'API
pnpm dev:up # Postgres, Redis, MinIO, Mailpit
pnpm dev:api # API sur http://localhost:3333
Si la DB est neuve : pnpm -F api exec node ace migration:run
Variables d'environnement
Définies dans environments/local.bru. Les valeurs vides (token, userId, etc.) sont remplies automatiquement par les script:post-response :
| Variable | Source | Utilisée par |
|---|---|---|
baseUrl |
en dur (http://localhost:3333) |
toutes |
email / password / fullName |
en dur (login fixture) | Signup, Login |
token |
rempli après Signup/Login | toutes les routes auth |
userId |
rempli après Signup/Login | (info) |
organizationId |
rempli après Signup/Login | (info, debug) |
clientId |
rempli après Create client | détail/update client, création facture |
planSlug |
en dur (standard-30j) |
détail/update plan |
invoiceId |
rempli après Create invoice OU Validate draft | détail/mark-paid |
batchId / draftId |
remplis après Upload (mock) | Get batch / Validate / Skip / Cancel |
Parcours recommandé (premier run)
- Auth → 01 Signup (récupère un token + crée l'org + provisionne les 4 plans)
- Account → 01 Get profile (vérifie l'auth)
- Organizations → 02 Update my org (onboarding step 2)
- Clients → 04 Create (crée un client, capture
clientId) - Plans → 01 List (vérifie les 4 plans pré-fournis)
- Invoices → 04 Create (crée une facture liée au client)
- Invoices → 05 Get detail (vérifie la timeline)
- Invoices → 06 Mark paid (encaisse + bonus rubis)
- Organizations → 01 Get my org (vérifie
rubisCountincrémenté) - Clients → 02 List with stats (vérifie les compteurs)
- Imports → 01 Upload (mock) (capture
batchId+draftId) - Imports → 02 Get batch (review des drafts pending)
- Imports → 03 Validate draft (transforme le draft en facture)
Flow refresh (silent re-login)
Une fois Signup ou Login passé, Bruno a stocké le cookie rubis_refresh dans sa cookie jar. Tu peux vider token dans l'env actif (pour simuler une expiration), puis appeler Auth → 04 Refresh : tu reçois un nouveau access token sans devoir re-saisir email/password. C'est ce que le SPA fera silencieusement quand une requête revient en 401.
Reset entre runs
L'email alice@bruno.test est unique en DB → 2e signup retourne 422 email_taken.
Pour repartir propre :
docker exec rubis-postgres psql -U rubis -d rubis_dev -c "DROP SCHEMA public CASCADE; CREATE SCHEMA public;"
pnpm -F api exec node ace migration:run
Ou change email dans l'environnement local pour forcer un nouveau signup à chaque run.