Tel que elois l’avais conçu :
- A crée une identité pour B, avec comme statut “created”
- B confirme son identité en lui donnant un nom, ce qui crée la demande d’adhésion, et change le statut à “confirmed”
- à la validation de l’identité, son statut passe à “validated”
Après avoir pas mal touché à ça, je me dis que ça pourrait être simplifié en retirant le statut de l’identité qui correspond en fait à un concept d’adhésion. On aurait alors :
- A crée une identité pour B (et la certifie)
- B confirme son identité en lui donnant un nom, ce qui crée la demande d’adhésion
- à la validation de l’identité, pas de changement de statut, simplement le passage de “demande d’adhésion” à “adhésion” (pending membership → membership)
Je creuse cette piste qui simplifierait les concepts et le code, et diminuerait la diversité des messages d’erreurs qu’on pourrait obtenir.
Peut-être qu’il y a une histoire de performances, parce que dans certains cas, ça permet de réaliser des actions sur l’identité sans aller vérifier la présence d’une adhésion. Mais c’est aussi une source d’incohérence parce que le statut de l’identité peut différer de la présence d’une adhésion…
J’avais également pensé à ajouter le statut “disabled” pour les identités qui ne sont plus membres (expiration d’adhésion ou manque de certifications), mais j’ai plus de réticences à ajouter des choses qu’à en enlever.
J’ai l’impression de tomber sur un problème plus profond lié aux pallets instanciables, j’ouvre un autre sujet → Pallets instanciables et vérifications d'adhésion