Aller au contenu

Fiche admin d'une demande de financement (BO Projets)

GET /administration/project-financing-request/:projectFinancingRequestId, PATCH …/:projectFinancingRequestId/presentation et PATCH …/:projectFinancingRequestId/account-manager (AdminAuthGuard) servent le volet « dossier » de la fiche Projet du BO Projets (BRI-2232, BRI-2407). Les pièces du projet et de sa société vivent sur …/:projectFinancingRequestId/documents* — voir Documents admin. La vue est valable pour tout statut.

GET /administration/project-financing-request/project/:projectId sert la même vue depuis l'id projet réservé (projectId_view, BRI-1549) : la fiche Projet est keyée sur cet id, posé dès la création du dossier, avant toute row properties. 404 project-financing-request-not-found quand aucun dossier ne le porte — le cas de tout projet legacy. La vue expose projectId dans les deux sens.

Source : project-financing-request-administration.controller.ts, contrat projectFinancingRequestDetail.endpoint.ts (api-communication-bricksoffice).

Choix

  • Guard local ensureDraft plutôt que ensurePresentationEditable (portail) : un seul code 404 sur la fiche.
  • Le projet est verrouillé et son statut revérifié dans la transaction : un dossier qui quitte draft pendant la sauvegarde rend 409, pas une écriture sur un dossier figé.
  • La présentation manquante est semée dans cette même transaction (getOrCreate(projectId, transac), insert DO NOTHING puis relecture verrouillée) : un rollback emporte la row, et le seed n'écrase jamais une sauvegarde portail concurrente.
  • Ordre des verrous : présentation puis projet, celui de completePresentation (portail). L'inverser fait deadlocker un renommage BO contre une complétion porteur.
  • Le status de la présentation est conservé : une présentation completed renommée reste completed. Le save portail, lui, le recalcule.
  • Patch typé (produce inline dans le service) sans reparse zod : isoDate_zod attend des strings, la row en mémoire porte des Date.
  • Pas de taggage S3 : le patch ne touche pas aux images.
  • Cohabitation avec …/users* (module utilisateurs, même préfixe) : find-my-way sert les segments statiques avant :projectFinancingRequestId — test de non-régression dans la suite GET.

Société emprunteuse

company ({ id, companyName?, siren?, legalForm? } ou null) est jointe depuis project_owner_company par project_financing_request."companyId" ; null tant que le portail n'a pas créé la société (première étape société). Nourrit la carte « Société emprunteuse » de la fiche BO et son lien vers la fiche Société.

Account manager

accountManager ({ id, firstName, lastName } ou null) est joint depuis project_financing_request_account_manager quand le dossier porte un accountManagerId. PATCH …/:id/account-manager le pose, le change ou le retire (null) ; un PATCH qui ne change rien n'écrit pas et ne notifie pas. Le reste — jobs Slack et CRM — vit dans le module project-financing-request-account-manager.

Un changement réel pingue aussi Projet Analyse (reason: 'account-manager-assigned'), hors transaction et seulement hors draft : un brouillon ne lui a jamais été soumis, il n'aurait rien à relire.