Fiche détail d'une demande de compte (backoffice)
src/views/backoffice/AccountRequestDetailView.vue (frontend) — pendant de la Fiche détail d'une demande de prêt, pour les demandes d'ouverture de compte (formulaire public).
Vérifié le 2026-08-13.
GET /api/account-requests et GET /api/account-requests/:id n'exigeaient aucune authentification — n'importe qui pouvait lister toutes les demandes d'ouverture de compte (identité, téléphone, email, adresse, données FATCA). verifyToken ajouté, et filtrage par agence/zone (agencyScopeWhere/canAccessAgency) appliqué — voir Agences, zones & GAB et Bugs & failles actives connues.
Une doc backend affirmait que le système de demande de compte suit "le même pattern quasi identique" que le prêt. C'est faux pour cette fiche et pour la mise à jour de statut. Elle est nettement plus pauvre — voir le tableau ci-dessous.
1. Comparatif avec la fiche prêt
| Fonctionnalité | Fiche prêt | Fiche compte |
|---|---|---|
Brouillon éditable (draft, dirty-check, patch partiel) | ✅ | ❌ Lecture seule, aucun champ éditable |
| Aperçu de l'email avant décision | ✅ | ❌ Aucun équivalent |
| Génération PDF | ✅ | ❌ Aucun équivalent |
Historique réel via activity-log.service.js | ✅ | ❌ Deux entrées codées en dur ("Demande créée" + "Passée en examen" si statut ≠ EN_ATTENTE), aucun appel à /api/activity-log |
| Ajout de documents depuis la fiche | ✅ | ❌ Documents en lecture seule uniquement (liens de téléchargement) |
| Changement de statut + note | ✅ (analyst_notes) | ⚠️ Présent mais cassé en l'état (voir ci-dessous), champ nommé internal_notes |
2. Note : bug corrigé le 2026-08-13
AccountRequestDetailView.vue/AccountRequestsView.vue appelaient PATCH /api/account-requests/:id pour changer le statut — cette route n'existait pas (account_requests.routes.js n'expose que PATCH /:id/status, avec suffixe), l'appel échouait en 404. Corrigé : les deux vues appellent désormais PATCH /:id/status.
3. Un seul contrôleur désormais (account.controller.js supprimé le 2026-08-13)
Il existait auparavant deux contrôleurs opérant sur la même table Prisma account_requests : account.controller.js (monté sur /api/account, protégé verifyToken + filtrage agence/zone, pas de create/remove) et account_requests.controller.js (monté sur /api/account-requests). Le premier n'était appelé par aucun code frontend (vérifié par recherche exhaustive dans frontend/src) ni par aucun autre fichier backend — confirmé non utilisé, il a été supprimé (account.controller.js, account.routes.js, démontage de /api/account dans server.js).
account_requests.controller.js (/api/account-requests) est maintenant la seule implémentation : create reste public (soumission du formulaire), getAll/getById exigent verifyToken + filtrage par agence/zone (corrigé le 2026-08-13, voir Bugs & failles actives connues), updateStatus valide le statut contre une whitelist (route PATCH /:id/status), plus remove.
4. Documents des signataires/bureau/promoteur — corrigé le 2026-08-13
Les CNI jointes en dehors des documents génériques (signataires pour un compte Société, membres du bureau pour une Association, promoteur pour une Entreprise Individuelle) restaient en base64 dans additional_data, jamais créées dans la table documents, donc invisibles dans l'onglet Documents de cette fiche. Corrigé côté formulaire public — voir Ouverture de compte — elles apparaissent désormais dans cet onglet comme les autres pièces.
5. Statuts
EN_ATTENTE (défaut à la création) → EN_COURS → APPROUVE / REJETE, validés uniquement côté account_requests.controller.updateStatus. Aucun email n'est envoyé lors d'un changement de statut (contrairement au prêt, voir aperçu email) — un email de reçu est envoyé à la création (sendReceiptEmail), mais rien à la décision.