Effectivement, c’est toute la nature de la discussion avec cgeek il y a un an : À quoi servent les pending membership? - #11 by cgeek. Il proposait de supprimer la pallet membership. On pourrait le faire mais j’ai un peu freiné par crainte de bouger trop de choses, c’était sûrement une erreur, mais c’est comme ça actuellement. Donc en résumé :
status: Member
membership.membership(index) == Some(_)status: !Member membership.membership(index) == None
Il reste cette proposition pour supprimer la pallet membership : Proposition pour supprimer la pallet membership. La lecture peut être intéressante car elle révèle les incohérences et redondances du modèle actuel (qui ont d’ailleurs déjà été source de bugs).
Dans Duniter Squid et Duniter Panel, j’ai fait le choix de fusionner le “identity.next_scheduled” et “membership.expire_on” en une seule variable dont le sens change en fonction de l’état. En gros :
Unconfirmed→ suppression programmée au blocnext_scheduledUnvalidated→ suppression programmée au blocnext_scheduledMember→ perte d’adhésion au blocexpire_onNotMember→ révocation programmée au blocnext_scheduledRevoked→ suppression programmée au blocnext_scheduled
À lire pour plus de détail sur la suppression d’identité : Récapitulatif du parcours membre.