DOC
Accueil/ Projets/ MJY Task Platform/ Sprint Backlog - Sprint 07 (Compte utilisateur, onboarding & fonctionnalités demandées) - [STATUT : OUVERT]

Sprint Backlog - Sprint 07 (Compte utilisateur, onboarding & fonctionnalités demandées) - [STATUT : OUVERT]

Période : À planifier (post Sprint 06) - lancement programmé le 09/07/2026 à 16h15 Type : 👤 Compte & profil utilisateur + 🔔 Notifications (in-app + Web Push) Sources : propositions_nouvelles_fonctionnalites.md (§1.A, §2.B) · product_backlog.md (US1.3) · Sprint Review 06

🎯 Objectif Principal (Sprint Goal)

Livrer les fonctionnalités demandées mais pas encore intégrées autour du compte utilisateur : une page Profil self-service (consultation + édition nom/email + PIN) et la gestion des emails par le super-admin (US1.3). Puis livrer les notifications « tâche à valider » - in-app en temps réel (Supabase Realtime) et push navigateur/PWA sans Firebase (Web Push standard / VAPID).

🚫 Hors périmètre (décidé) :

  • Onboarding email automatisé (PIN temporaire + email de bienvenue, proposition §1.C) : reporté (décision PO) - le roster actuel (voir tout le monde + choisir) suffit pour le moment. Renvoyé au backlog de suggestions.
  • Firebase / FCM : non retenu - les notifications passent par Supabase Realtime (in-app) et le Web Push standard (VAPID), sans compte tiers. Firebase ne serait utile que pour un futur push mobile natif.
  • Refonte de l'écran de connexion (proposition §1.B « écran neutre ») : écartée - on conserve le roster (confirmé aux Sprints 05/06).
  • Déploiement en production : reste un sprint dédié à venir (prérequis dans Sprint Backlog 06 §Après). Le Sprint 07 construit par-dessus l'existant local/test.
  • Refonte visuelle (§1.D), PWA hors-ligne complet, audit trail, pièces jointes, isolation stricte par filiale : conservés au backlog de suggestions. (NB : un Service Worker minimal est introduit ce sprint pour le Web Push - pas le mode hors-ligne complet.)

🧭 Portée & priorisation

Items classés : 🔴 Cœur de sprint (engagement ferme), 🟠 Valeur produit, 🟡 Amélioration & report.

📋 Stories Sélectionnées pour le Sprint

🔴 Bloc 1 - Compte utilisateur : Profil & emails

  1. US7-PROF-01 : Page Profil utilisateur - 5 SP

    • Réf. : propositions §1.A
    • Description : vue Profil accessible depuis chaque dashboard (bouton dans l'en-tête). Consultation : nom, email, rôle, projets/entités rattachés. Édition self-service du nom d'affichage et de l'email (requêtes Supabase soumises à la RLS member_update_self ; l'email auth.users passe par le serveur - cf. US7-EMAIL-03). Point d'entrée unifié vers le changement de PIN.
    • Critère d'acceptation : chaque rôle voit ses infos correctes et peut modifier son nom ; la modification d'email est prise en compte (ou déléguée au serveur) sans casser la session.

  2. US7-PIN-02 : Changement de PIN renforcé (ancien PIN requis) - 3 SP

    • Réf. : propositions §1.A (« l'ancien code PIN doit être saisi pour validation »)
    • Description : étendre ChangePinModal pour re-vérifier l'ancien PIN avant modification (re-signInWithPassword avec l'email courant + ancien PIN, ou vérification serveur), puis supabase.auth.updateUser. Conserver le refus du PIN par défaut et le flag pin_customized.
    • Critère d'acceptation : un mauvais ancien PIN bloque le changement ; un bon ancien PIN + nouveau PIN valide met à jour le mot de passe natif.
    • ⚠️ Note archi : aucun hashage manuel - le bcrypt reste géré par Supabase (updateUser). La spec « hachage bcrypt côté serveur » est adaptée à l'auth native (ADR 0002).

  3. US7-EMAIL-03 : Édition des emails des membres par le super-admin (US1.3) - 3 SP

    • Réf. : product_backlog US1.3, Admin API
    • Description : le super-admin / admin édite l'email de n'importe quel membre (et le sien) via l'Admin API (auth.admin.updateUserById) côté serveur - endpoint /api/member (server.js) et netlify/functions/member.js (parité iso-contrat), avec propagation dans public.member.
    • Critère d'acceptation : un super-admin change l'email d'un membre ; un rôle non autorisé reçoit 403 ; l'email est cohérent entre auth.users et member.

🟠 Bloc 2 - Notifications « tâche à valider » (proposition §2.B) - sans Firebase

  1. US7-NOTIF-04 : Notification in-app en temps réel - 3 SP

    • Réf. : Supabase Realtime déjà en place (useData écoute task/task_notes)
    • Description : alerter le manager assigné quand une tâche passe en pending_validation - badge (« X à valider ») + liste dédiée côté manager, mis à jour sans rechargement via le Realtime existant. Marquage lu/non-lu local.
    • Critère d'acceptation : une soumission de tâche par un collaborateur fait apparaître l'alerte côté manager en < 5 s, sans refresh ; le compteur se met à jour au traitement.

  2. US7-NOTIF-05 : Push navigateur / PWA (Web Push, sans Firebase) - 5 SP

    • Réf. : Web Push API standard + VAPID ; pas de Firebase
    • Description : notif système même app fermée (desktop + Android). Introduire un Service Worker minimal + manifest.webmanifest (juste pour le push, pas le hors-ligne complet), gérer l'abonnement Push (permission + PushSubscription stocké en base), et l'envoi depuis une Netlify Function / server.js (lib web-push, clés VAPID) - déclenché sur passage en pending_validation (Database Webhook Supabase ou appel serveur).
    • Critère d'acceptation : un manager ayant autorisé les notifications reçoit un push « Tâche [X] à valider » app fermée (desktop/Android) ; abonnement révocable.
    • ⚠️ Notes : iOS ne supporte le Web Push que pour une app installée en PWA (iOS 16.4+) - dégradation gracieuse ailleurs (l'in-app US7-NOTIF-04 reste le socle). Décision : génération/stockage des clés VAPID (env serveur) + table push_subscriptions.

🟡 Bloc 3 - Report (peut déborder)

  1. US7-VAL-06 : Validation de l'import par les chefs (report Sprint 06) - 1 SP
    • Réf. : recette_demo.md, report TS6.32
    • Description : présenter la démo d'import à Julien & Marco (après le vendredi soir), consigner la validation formelle au §4 du script de recette.
    • Critère d'acceptation : validation formelle consignée ; ajustements éventuels notés.

📊 Capacité & Engagement

Bloc Stories Effort
🔴 Compte & profil US7-PROF-01, US7-PIN-02, US7-EMAIL-03 11 SP
🟠 Notifications (in-app + Web Push) US7-NOTIF-04, US7-NOTIF-05 8 SP
🟡 Report US7-VAL-06 1 SP
Total 6 stories 20 SP

⚖️ Engagement ferme : Bloc 1 (11 SP) + Bloc 2 in-app (US7-NOTIF-04). Le Web Push (US7-NOTIF-05) et le report validation (Bloc 3) peuvent déborder.

🗂️ Backlog de suggestions (non engagé - reporté)

À prioriser lors d'un sprint ultérieur, par ordre de valeur pressentie :

  1. Onboarding email automatisé (proposition §1.C - PIN temporaire + email de bienvenue + must_change_pin) : reporté ce sprint (roster conservé). Nécessitera un fournisseur d'email (Resend / SendGrid / Nodemailer).
  2. Notifications étendues (email / Slack sur bloquant, rejet ; regroupement) - extension d'US7-NOTIF-04/05.
  3. Pièces jointes aux tâches (Supabase Storage + RLS) - photos terrain Miyan / bons de livraison ENGWE.
  4. Audit trail (audit_logs : connexion échouée, changement de PIN, suppression projet, validation).
  5. Isolation stricte par filiale (renforcement RLS multi-entités).
  6. PWA hors-ligne complet (Service Worker + IndexedDB + sync) - au-delà du SW push introduit ce sprint.
  7. Refonte visuelle (§1.D - en fin de projet).
  8. Push mobile natif (FCM / APNs = Firebase) - seulement si virage app native.

🚧 Décisions à trancher (PO / archi)

  1. ⚠️ Édition d'email self-service (US7-PROF-01) : tranché par défaut conservateur (lecture seule pour soi, édition déléguée au super-admin) - à confirmer/ajuster par le PO.
  2. ✅ Web Push (US7-NOTIF-05) : tranché - Option B (appel serveur explicite depuis useData.saveTask, pas de Database Webhook Supabase). Voir ADR 0010, statut Accepté. Compte Supabase gratuit confirmé compatible (09/07).
  3. Périmètre iOS : Web Push iOS uniquement en PWA installée (16.4+) - dégradation gracieuse acceptée par construction (in-app US7-NOTIF-04 reste le socle partout), non testé sur iOS réel ce sprint.

✅ Definition of Done du sprint

Conforme à definition_of_done.md, et en particulier :

  • Page Profil opérationnelle pour les 3 rôles ; changement de PIN avec ancien PIN vérifié ; édition d'email cohérente auth.users ↔ member.
  • Notifications : in-app temps réel côté manager (< 5 s, sans refresh) ; Web Push app fermée (desktop/Android) avec abonnement révocable, sans Firebase ; dégradation gracieuse sur navigateurs non compatibles.
  • Parité serveur (server.js) ↔ Netlify Functions maintenue sur les endpoints touchés (contrat /api).
  • npm run build réussit ; npm run test et npm run test:e2e passent ; nouveaux ADR consignés (Web Push / VAPID).

🔗 Références