chat.freenode.net #tryton-fr log beginning Wed Feb 20 00:00:02 CET 2013 | ||
2013-02-20 10:37 <cedk> Pilou: qu'est-ce que tu en pense de http://codereview.tryton.org/665003/ | ||
2013-02-20 10:41 <Pilou> dans quel cas l'exception est elle levée ? | ||
2013-02-20 10:43 <cedk> Pilou: si le pays est utiliser quelque part et qu'on doit le supprimer | ||
2013-02-20 10:44 <cedk> Pilou: j'ai testé avec le dernier export de pycountry et j'ai pas eu de problème | ||
2013-02-20 10:45 <cedk> Pilou: du coup on a plus besoin de se tracasser des changements d'id de la norme XML | ||
2013-02-20 10:46 <Pilou> ça ne vaudrait pas le coup d'enregistrer db_id, model, tb_s dans une table et d'avoir un bouton/wizard qui permet d'essayer à nouveau la suppression ? Le cas utilisateur serait: après une mise à jour je vérifie la vue qui contient db_id, model, tb_s. Je corrige les problèmes dans les données (ie ne plus utiliser db_id), je réessaie de supprimer en utilisant le bouton. | ||
2013-02-20 10:46 <Pilou> En ce qui concerne le patch c'est sain de désactiver ce qui ne doit plus être utilisé. | ||
2013-02-20 10:47 <cedk> Pilou: pour le wizard, une mise à jour du module le fait | ||
2013-02-20 10:47 <cedk> Pilou: par contre, j'ai déjà pensé à une fonctionnalité similaire mais pour la mise à jour des records | ||
2013-02-20 10:48 <cedk> Pilou: par fois, on ne met pas à jour car il a été modifié par l'utilisateur | ||
2013-02-20 10:48 <cedk> Pilou: du coup ça pourrait être sympat de permet à l'utilisateur d'écraser sa modif avec les données de base | ||
2013-02-20 10:49 <Pilou> les données des XML ne sont pas immutables ? | ||
2013-02-20 10:51 <cedk> Pilou: par defaut si, mais tu peux changer le comportement | ||
2013-02-20 10:52 <Pilou> il faut modifier le code de trytond pour ça ? | ||
2013-02-20 10:53 <cedk> Pilou: surcharge la method ModelStorage.check_xml_record | ||
2013-02-20 10:54 <cedk> Pilou: mais c'est à utiliser en dernier recour | ||
2013-02-20 10:55 <Pilou> oui je vois ça comme ça aussi :) | ||
2013-02-20 10:55 <Pilou> Ca vaut quand même le coup d'automatiser les changements d'id pour country non ? c'est une tâche automatisable que tous les users vont devoir faire. | ||
2013-02-20 10:56 <cedk> Pilou: je vois pas comment automatiser | ||
2013-02-20 10:57 <cedk> Pilou: je ne pense pas que tous les users vont de voir faire quelque chose | ||
2013-02-20 10:58 <cedk> Pilou: de plus comme les doublons seront desactivés, ils ne seront pas génant | ||
2013-02-20 10:59 <Pilou> Le patch incomplet ne va pas du tout ? Le problème pour l'utilisateur sera d'identifier ce qu'il doit modifier. | ||
2013-02-20 11:00 <cedk> Pilou: mais que devra-t-il modifier ? | ||
2013-02-20 11:02 <Pilou> ben si il a un modèle qui utilise un champ "country" qui a pour valeur un id qui correspond à un pays qui est passé inactif (parce que le code du pays a été renommé), il voudra surement pointer vers le nouveau code. | ||
2013-02-20 11:03 <cedk> Pilou: s'il le veut | ||
2013-02-20 11:03 <cedk> Pilou: il y a 719 changements d'id | ||
2013-02-20 11:03 <cedk> Pilou: je vois pas comment c'est gerable pour nous | ||
2013-02-20 11:04 <cedk> Pilou: et seulement 1 pays | ||
2013-02-20 11:04 <Pilou> ben quand c'était possible (par exemple renommage) il me semble que le début de patch ne changeait pas l'id justement. | ||
2013-02-20 11:05 <cedk> Pilou: et le pays disparait: Netherlands Antilles | ||
2013-02-20 11:06 <Pilou> quand c'est pas possible modifié le champ active du pays est une bonne idée :) | ||
2013-02-20 11:07 <cedk> Pilou: les subdivision ne sont pas si importante en plus | ||
2013-02-20 11:08 <Pilou> mon point de vue: l'idéal c'est 1) ne pas changer les id quand c'est possible 2) passer en inactif les pays supprimer 3) rendre la liste des actions de maintenance disponible à l'utilisateur (ie "impossible de supprimer tel pays") | ||
2013-02-20 11:11 <cedk> Pilou: 2 et 3 sont présents | ||
2013-02-20 11:12 <cedk> Pilou: 1 je pense que vu la vollatilité (subdivision) des données +700 changement un 2 ans, c'est ingérable | ||
2013-02-20 11:12 <Pilou> pour 3 tu veux dire que lors de la migration c'est indiqué ? | ||
2013-02-20 11:12 <Pilou> pour 3 tu veux dire que lors de la migration c'est indiqué par le message d'erreur "Could not delete id [...]" ? | ||
2013-02-20 11:13 <cedk> Pilou: oui | ||
2013-02-20 11:14 <Pilou> ce serait plus user friendly si c'était stocké dans un modèle mais ok ce n'est pas obligé de faire quelque chose sur ce point | ||
2013-02-20 11:15 <cedk> Pilou: je pense pas que ce soit nécessaire puisque c'est rejouable | ||
2013-02-20 11:16 <Pilou> pour 1 est ce que tu veux que je mette à jour le patch en suivant tes remarques ? je peux faire ça pour demain. | ||
2013-02-20 11:18 <Pilou> je me dis que si les données des payes sont créées par Tryton, c'est un peu à Tryton de faciliter la migration. Peut être qu'une autre solution serait de fournir le script pycountry mais de ne pas charger les données à l'installation du module. | ||
2013-02-20 11:18 <cedk> Pilou: ça m'ennuie vraiment d'avoir de gros script de migration pour quelque chose qu'on ne maitrise pas | ||
2013-02-20 11:19 <Pilou> je comprends et c'est pour ça que je propose ^^ | ||
2013-02-20 11:19 <cedk> Pilou: c'est pas le problème mais dans 1-2 ans quand on remettra encore à jour, on va encore avoir un script de la même taille à faire | ||
2013-02-20 11:20 <cedk> Pilou: avec en plus le problème de conflit entre les 2 migrations | ||
2013-02-20 11:20 <cedk> Pilou: et la complexité va croite de manière exponentiel | ||
2013-02-20 11:24 <Pilou> je suis d'accord que c'est un script moche (Un utilisateur qui utilise beaucoup tous les codes sera obligé de faire un script). Personnellement je trouve ça logique de ne pas inclure les données par défaut si les nombreuses modifications automatisables ne sont pas inclues. | ||
2013-02-20 11:25 <cedk> Pilou: en fait, on fait déjà un peu la même chose pour les plans comptable | ||
2013-02-20 11:25 <cedk> Pilou: on fait du «best effort» | ||
2013-02-20 11:26 <Pilou> je ne connais pas du tout le fonctionnement au niveau des plans comptables. | ||
2013-02-20 11:32 <cedk> Pilou: en fait on a un peu la même problématique, des données dont on ne maitrise pas l'évolution | ||
2013-02-20 11:33 <cedk> Pilou: donc on essaie de mettre à jour mais on supprime pas les anciens s'ils sont utilisés |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!