[API] Mise à jour affectation #3655
Conversation
sfinx13
force-pushed
the
feature/3619-update-affectation
branch
from
9592304 to
cb21afe
Compare
sfinx13
requested review from
numew,
emilschn and
hmeneuvrier
and removed request for
numew and
emilschn
There was a problem hiding this comment.
Quelques commentaires dans le code (pas grand choses)
Quelques test KO :
- Si j'envoie un payload sans valeur
{
"statut": null,
"motifCloture": null,
"motifRefus": null,
"message": null,
"notifyUsager": null
}
J'ai un crash erreur 500 (si possible et pas trop compliqué à corriger en erreur propre)
- Si j'envoi le payload d'exemple de la doc
{
"statut": "EN_COURS",
"motifCloture": "DEPART_OCCUPANT",
"motifRefus": "EN_COURS",
"message": "Lorem ipsum dolor sit amet, consectetur adipiscing elit.",
"notifyUsager": "true"
}
Le payload d'exemple génère des erreurs (notifyUsager, motifRefus)
Difficile d'être exhaustif dans les tests
| Signalement $signalement, | ||
| Affectation $affectation, | ||
| User $user, | ||
| Request $request, | ||
| FirstAffectationAcceptedSpecification $firstAcceptedAffectationSpecification, | ||
| DossierMessageFactory $dossierMessageFactory, | ||
| MessageBusInterface $bus, | ||
| ): Response { | ||
| $this->denyAccessUnlessGranted(AffectationVoter::ANSWER, $affectation); |
There was a problem hiding this comment.
Est-ce qu'on ne devrait pas ici ajouter un check du statut existant pour autoriser uniquement si STATUS_WAIT ?
There was a problem hiding this comment.
Je pourrais à la place appliquer le nouveau voter la ou il est applicable ? (Je voudrais le faire valider avant et faire un autre ticket)
There was a problem hiding this comment.
Pour ce cas précis le workflow me parait pas assez restrictif, on veux uniquement que ce soit possible si le statut est STATUS_WAIT (mais ca peux en effet attendre le ticket dédié d'application du voter)
sfinx13
force-pushed
the
feature/3619-update-affectation
branch
from
c75a78a to
53d478c
Compare
sfinx13
force-pushed
the
feature/3619-update-affectation
branch
from
53d478c to
cc4e5fc
Compare
| ); | ||
|
|
||
| $signalement->addSuivi($suivi); | ||
| $this->sendMailToPartner( |
There was a problem hiding this comment.
Pourquoi le dispatch de SuiviCreatedEvent dans le SuiviManager ne suffit pas ?
There was a problem hiding this comment.
ça fait planter les tests, il faudrait faire un tour sur ce qui reste comme envoi de mail après création de suivi je crée un ticket
| @@ -61,22 +57,6 @@ public function onSignalementClosed(SignalementClosedEvent $event): void | |||
| $this->sendMailToPartners($signalement); | |||
There was a problem hiding this comment.
Y'a des conditions dans le SuiviCreatedEventSubscriber pour ignorer les signalement cloturés.
Faudrait une suite au ticket refacto suppression ActivityListener mais dans l'absolu je suis d'accord de tout centraliser. Mais pas dans cette PR
|
Ticket
#3619
Description
Mise à jour des affectations selon le workflow de l'application
flowchart TD NOUVEAU[NOUVEAU] -->|Accepter| EN_COURS[EN COURS] NOUVEAU -->|Refuser| REFUSE[REFUSÉ] EN_COURS -->|Fermer| FERME[FERMÉ] REFUSE -->|Annuler le refus| EN_COURS FERME -->|Ré-ouvrir| NOUVEAUChangements apportés
AffectationpoursignalementResponseuuidsur la tableaffectationAffectationVoter::VALID_WORKFLOW_STATUTdans le voter afin de restreindre les mises à jour aux seules transitions valides.SecurityApiExceptionListeneraffectation.closedPré-requis
Configuration
Tests
http://localhost:8080/api/doc#tag/Affectations/operation/patch_api_affectations_update/api/affectations/{{affectation_uuid}}avec un workflow valide (Même comportement que sur l'app)Tests TNR