Salut,
Alors c’est pas un bug, mais la demande d’un ajout de fonctionnalité.
En fait beaucoup de gens migrent, du coup d’autres personnes certifient les anciens comptes, ce qui crée des invitations, et peut embrouiller les gens qui ont l’impression d’avoir deux comptes certifiés ou un bug de migration.
Du coup serait-il possible de mettre un message d’avertissement avant de pouvoir certifier un compte qui vient d’être migré?
Clairement un bug UX.
Ticket créé : #168 - Avertissement avant de certifier un ancien compte migré
cc @poka je ne sais pas comment se comporte Ğecko sur ce point.
Je pense même qu’il faut tout bonnement empêcher de certifier une address dont une identité a précédemment été migré, côté app. Pas juste un avertissement.
Je me demande même si ça ne nécessite pas un changement de comportement côté Duniter pour empêcher de pouvoir certifier une adresse qui a subit un changeOwnerKey.
@elois qu’en penses-tu ?
Ca dépend de cas, j’ai déjà un ticket Duniter pour ça, j’ai déjà répondu ici:
J’ai l’impression que le sujet ici porte plus sur la migration des identités pas encore membre.
Ici le sujet est plutôt la possibilité de continuer de certifier une adresse qui a déjà subit une changeOwnerKey, dont une identité y était associé dans le passé, mais ne l’est pas à présent.
Je pense qu’on devrait interdir cette possibilité, dans tous les cas de figure.
C’est bien ce dont je parle dans l’autre sujet, relis mes post
@elois Ok pour la migration d’une identité tu as répondu, c’est un sujet à part.
Mais pour le compte ayant subi une migration @poka indique être favorable à une interdiction de réception d’une certification (a fortiori créatrice d’identité).
Côté wallet ça me semble déjà important pour éviter les confusions. Mais pousse-t-on la règle jusque dans le runtime ? On a déjà la donnée si je ne m’abuse, ça fait une règle en plus mais de stockage supplémentaire.
On en a discuté avec Poka et Hugo. Notre conclusion côté Duniter est qu’on devrait interdire la création d’identité (1ʳᵉ certif) si le compte est déjà lié à une identité. Cela inclut les anciens comptes, car change_owner_key ne supprime pas le champ link_idty : il reste en place pendant 6 mois après la migration. On peut donc faire le check sans surcoût côté Duniter, puisque le champ link_idty est déjà lu car présent dans AccountData.
J’ai créé un ticket Duniter pour ça: Forbid idty creation on account with link_idty field (#361) · Issues · nodes / rust / Duniter v2S · GitLab
Issue créé côté Gecko: UX: empêcher la certification d'un ancien compte migré (#160) · Issues · clients / Ğecko · GitLab