Ğecko talks / user support

Dans identités ça mouline

Puis

j’ai du réseau !

Vérifie sur quel noeud squid tu es connecté, en mode auto ?

le squid axiom team

et en Ğ1 temporaire pas Ğtest

Moi je n’ai pas de problème, tu es bien en 1.0.0. ?

oui

edit, ça remarche

puis re souci de réseau

étrange

transactions et certifs marchent mieux

Et quand je clique vite deux fois sur le coin bas gauche de l’écran d’accueil (une fois sur le numéro de version suffit, ça s’illumine en vert, ok ça doit être là exprès) il me met diagnostic copié dans clipboard

Merci @poka pour la dernière version 1.0.0 qui maintenant fonctionne bien en espéranto.

Une dernière chose pour que ce soit parfait serait de mettre le lien vers la licence en espéranto (actuellement cela dirige vers la licence en anglais).

La licence en Eo se trouve ici : www/license/license_g1-eo-EO.md · master · clients / Cesium-grp / Cesium · GitLab

ou ici : g1_monetary_license_eo.rst · master · documents / g1_monetary_license · GitLab

Edit : j’ai aperçu aussi une chaîne non traduite mais je ne l’ai pas retrouvée sur le weblate (idem pour les autres langues) :

Ça c’est le compte au format v1, legacy.

Je me connecte dessus si des gens se trompent par habitude et font encore des virements dessus, même si c’est obsolète. Ça peut encore recevoir des junes, vérifié.

Mais du coup pas de fonction visible pour juste oublier ce compte legacy, dans mon cas il a déjà été migré et je me connecte dessus parce qu’il existe encore.

Donc faut oublier tous les coffres et réimporter juste ceux qu’on veut garder; donc un bout en oublier sur le compte legacy aiderait, ok c’est pas un coffre

Au lieu de l’importer tu peux juste avoir ton coffre et utiliser la migration id/password pour voir si il reste des sous dessus, et les migrer en 1 clic si il y en a.

ok testé, ça marche bien

Après l’avoir fait le compte legacy parmi les coffres ne disparaît pas

C’est à dire ? Je ne comprends pas.
Tu ne devrais pas pouvoir avoir un compte legacy + des coffres, je veux bien des screenshots stp.

Oui je sais que c’est un cas qui n’arrivera pas souvent

Ah je vois, tu as d’abords importé un legacy, puis tu as créer d’autres coffre via l’écran de demande de code secret, c’est ça ?

Du coup, j’hésite à tout bonnement interdir la création d’autre coffre via cet écran si on a un legacy, c’était mon intention de base. T’en pense quoi ?

Tant que tu n’as pas migré, tu ne créer pas de coffre, sauf via le bouton “Migrer vers un nouveau coffre” affiché en gras. Non ?

Oui forcer à migrer le legacy dans un coffre comme condition pour en créer me paraît bien.

Du coup, le scénario à suivre, si on veut migrer vers une nouvelle adresse que l’on a créée ailleurs (génération vanity), c’est de :

  • Importer la nouvelle adresse avec la phrase de restauration
  • Demander de “migrer un ancien compte id/mdp” depuis ce coffre là

Je n’avais pas vu ton post. J’ai fait un test rapide, le résultat est ici : https://forum.duniter.org/t/forgerons-v1-preparez-vous-a-la-v2/13580 Cela n’a pas fonctionné pour moi

Je viens de me connecter à la G1 “prod” pour tester rapidement la migration de compte. Cela n’a pas fonctionné.

J’ai utilisé la version la plus récente de Gecko 1.0.0.

J’ai restauré un compte puis j’ai tenté de migrer, voici l’erreur produite :

@poka as-tu une idée de l’origine du pb ?

Je regarde ça en prio, je te tiens au jus dès que j’ai une version corrective pour android à installer et tester rapidement.

Tu as installé gecko via store ou apk ?

Si c’est par APK, peux-tu tester avec ce build STP ?

https://cloud.axiom-team.fr/s/woJR74zawJRfPxk/download/app-arm64-v8a-release.apk

Ca dois mieux décoder les erreurs de Duniter.
Tu es smith, mais offline, donc normalement tu devrais pouvoir changeOwnerKey, mais je suis presque sûr que le problème vient de là.

j’utilise l’apk téléchargé depuis les releases de gitlab. Voici l’erreur générée en version 1.0.1

@poka Mon intuition, c’est que ça échoue parce que ton batch tente de migrer l’identité avant de transférer les fonds ; du coup, le nouveau compte n’existe pas encore. Si c’est le cas, alors la migration va échouer pour tous les membres (pas seulement les forgerons) avec ce correctif : Identity on empty account (#321) · Issues · nodes / rust / Duniter v2S · GitLab

L’extrinsic pour migrer un compte doit être batchAll[transferAll, changeOwnerKey], et surtout pas l’inverse.