[Mission] Afficher une pop-up lors de la suppression d'une mission si des actions ont été créées par d'autres centres

[claire2212]

Explication de la cinématqiue front pour expliquer le parti-pris en back :

• Je clique sur supprimer

• je vérifie qu'il n'y a pas d'actions "externes"

• Si oui -> Affichage de la pop-up d'alerte indiquant que des actions ont été créées par d'autres appli (juste fish pou rle moment mais rapport nav aussi à terme)

• L'utilisateur peut confirmer ou non la suppression

• Si non -> Affichage de la pop-up de confirmation de suppression (iso à l'actuel)

• L'utilisateur peut confirmer ou non la suppression

Côté Fish et RapportNav : il n'y aura qu'à ajouter l'appel à la nouvelle api can_delete (pas de modification faites sur l'api privée et publique de suppression)

Côté technique :

• Création d'un nouveau endpoint can-delete qui renvoie soit true soir une erreur si des actions sont trouvées

Related Pull Requests & Issues

• Resolve Missions - Bloquer la suppression d'une mission quand elle contient des actions Fish ou RapportNav #1123

---

• Tests E2E (Cypress)

[claire2212]

Plus utilisé en back mais en front oui. A fixer

[claire2212]

je sais pas ce que c'est ça

[thoomasbro]

c'est pour le linter back. Le nom du package ne devrait pas être use_case mais useCase. On retrouve donc cette ligne dans tous les fichiers sous domain/use_case

[claire2212]

@thoomasbro, il y a plein de useCase qui n'ont pas cette ligne (dossier amps, controlUnit, Administration, ControlPlan,...)

[thoomasbro]

Effectivement... j'étais persuadé d'avoir retiré -e "Package name must not contain underscore"du linter. J'avais ajouté ces annotations dans ce but. Je serais pour remettre cette annotation.

[louptheron]

La méthode me semble bien, je me demande juste si le use-case DeleteMission ne doit pas appeler le use-case CanDelete, car sinon il n'est pas protégé ?

[thoomasbro]

Je me demande si on a vraiment besoin d'avoir les entités MonitorFishActions dans le domaine. Car en fait c'est utilisé par l'appel api qui est dans la partie infra, et uniquement là. Je l'aurais mis dans quelque chose du genre infrastructure.api.adapters.monitorfishApi.FishActionDataInput. Il ne devrait plus y avoir besoin de l'annotation @serializable. Le useCase pourrait d'ailleurs être MissionHasFishActionset retourner simplement un boolean. On pourrait ne parser de l'api que l'id, ce qui permettrait d'éviter d'avoir des soucis si le contenu du json change.

[claire2212]

@thoomasbro, j'ai supprimé le useCase (commentaire de Loup : #1162 (comment)) et j'ai gardé simplement id et missionId.
Et je suis obligée de laisser l'entité car je m'en sert dans IMonitorFishMissionActionsRepository (qui n'autorise pas un import venant deinfrastructure)

[thoomasbro]

Je me suis posé la même question. J’avais pensé à `input` car c’est une information que l’on fait rentrer dans le domaine, pas une donnée qui est envoyée depuis le domaine.

…

Le 2 févr. 2024 à 09:20, Claire Dagan ***@***.***> a écrit : @thoomasbro <https://github.com/thoomasbro>, j'ai supprimé le useCase (commentaire de Loup) et j'ai gardé simplement id et missionId. Par contre pour moi c'est plutôt un output étant donné que c'est la réponse au get mission_actions que je type, non? — Reply to this email directly, view it on GitHub <#1162 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABCFQPMM365Z67UEIEJVRDDYRSOU3AVCNFSM6AAAAABCTPJTQKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRTGMYDGMBUGQ>. You are receiving this because you were mentioned.