+106
−0
apps/web/src/coque/ChoixPorteur.tsx
0 → 100644
+112
−0
Loading
Question posée à l'écran : pourquoi ne puis-je pas m'attribuer une action ? Parce que la liste « qui la porte » ne rendait que les comptes admis dans une cellule. Or l'accès à une crise vient de l'appartenance à l'organisation, pas d'une cellule : celui qui ouvre la crise n'y figurait donc pas, alors qu'il est par définition en train d'agir. Le serveur, lui, l'acceptait : « responsableId » n'est validé que comme UUID. La restriction n'existait que dans la liste du client. Trois populations, groupées, et l'ordre est le propos. Les membres de chaque cellule d'abord, par cellule : c'est là qu'on cherche, et savoir de quelle cellule quelqu'un relève dit à peu près tout. L'annuaire gelé ensuite, car une action se fait souvent par quelqu'un qui ne siège dans aucune cellule — un responsable d'application, un chef de site. Ceux qui n'ont pas de compte y figurent aussi, marqués comme tels : l'action portera leur nom en clair, ce que « responsable_libelle » sait faire depuis l'origine, et cela évite de recopier à la main un nom que le dossier connaît déjà. Les membres de l'organisation absents de l'annuaire enfin. Cette troisième population ne m'était pas demandée — la proposition s'arrêtait à l'annuaire — mais sans elle le défaut signalé reviendrait à l'identique pour la personne qui ouvre la crise, qui n'est pas nécessairement à l'annuaire. Une route distincte plutôt que l'élargissement de « /membres », que trois autres écrans utilisent : ils ne posent pas la même question. Écrire un message direct à quelqu'un sans compte n'a pas de sens ; porter une action, si. Six garanties, dont la première est exactement le cas signalé : celui qui a ouvert la crise se trouve dans la liste, et y est signalé comme étant lui-même. Ces fichiers portent aussi la route de lecture et ses garanties, qui viennent avec le lot sur la main courante. Co-Authored-By: Claude (RCA)