IRC logs of #tryton-fr for Wednesday, 2013-02-20

chat.freenode.net #tryton-fr log beginning Wed Feb 20 00:00:02 CET 2013
cedkPilou: qu'est-ce que tu en pense de http://codereview.tryton.org/665003/10:37
Piloudans quel cas l'exception est elle levée ?10:41
cedkPilou: si le pays est utiliser quelque part et qu'on doit le supprimer10:43
cedkPilou: j'ai testé avec le dernier export de pycountry et j'ai pas eu de problème10:44
cedkPilou: du coup on a plus besoin de se tracasser des changements d'id de la norme XML10:45
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.10:46
PilouEn ce qui concerne le patch c'est sain de désactiver ce qui ne doit plus être utilisé.10:46
cedkPilou: pour le wizard, une mise à jour du module le fait10:47
cedkPilou: par contre, j'ai déjà pensé à une fonctionnalité similaire mais pour la mise à jour des records10:47
cedkPilou: par fois, on ne met pas à jour car il a été modifié par l'utilisateur10:48
cedkPilou: du coup ça pourrait être sympat de permet à l'utilisateur d'écraser sa modif avec les données de base10:48
Piloules données des XML ne sont pas immutables ?10:49
cedkPilou: par defaut si, mais tu peux changer le comportement10:51
Pilouil faut modifier le code de trytond pour ça ?10:52
cedkPilou: surcharge la method ModelStorage.check_xml_record10:53
cedkPilou: mais c'est à utiliser en dernier recour10:54
Pilououi je vois ça comme ça aussi :)10:55
PilouCa 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.10:55
cedkPilou: je vois pas comment automatiser10:56
cedkPilou: je ne pense pas que tous les users vont de voir faire quelque chose10:57
cedkPilou: de plus comme les doublons seront desactivés, ils ne seront pas génant10:58
PilouLe patch incomplet ne va pas du tout ? Le problème pour l'utilisateur sera d'identifier ce qu'il doit modifier.10:59
cedkPilou: mais que devra-t-il modifier ?11:00
Pilouben 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.11:02
cedkPilou: s'il le veut11:03
cedkPilou: il y a 719 changements d'id11:03
cedkPilou: je vois pas comment c'est gerable pour nous11:03
cedkPilou: et seulement 1 pays11:04
Pilouben quand c'était possible (par exemple renommage) il me semble que le début de patch ne changeait pas l'id justement.11:04
cedkPilou: et le pays disparait: Netherlands Antilles11:05
Pilouquand c'est pas possible modifié le champ active du pays est une bonne idée :)11:06
cedkPilou: les subdivision ne sont pas si importante en plus11:07
Piloumon 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")11:08
cedkPilou: 2 et 3 sont présents11:11
cedkPilou: 1 je pense que vu la vollatilité (subdivision) des données +700 changement un 2 ans, c'est ingérable11:12
Piloupour 3 tu veux dire que lors de la migration c'est indiqué ?11:12
Piloupour 3 tu veux dire que lors de la migration c'est indiqué par le message d'erreur  "Could not delete id [...]" ?11:12
cedkPilou: oui11:13
Pilouce 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 point11:14
cedkPilou: je pense pas que ce soit nécessaire puisque c'est rejouable11:15
Piloupour 1 est ce que tu veux que je mette à jour le patch en suivant tes remarques ? je peux faire ça pour demain.11:16
Pilouje 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.11:18
cedkPilou: ça m'ennuie vraiment d'avoir de gros script de migration pour quelque chose qu'on ne maitrise pas11:18
Pilouje comprends et c'est pour ça que je propose ^^11:19
cedkPilou: 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 à faire11:19
cedkPilou: avec en plus le problème de conflit entre les 2 migrations11:20
cedkPilou: et la complexité va croite de manière exponentiel11:20
Pilouje 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.11:24
cedkPilou: en fait, on fait déjà un peu la même chose pour les plans comptable11:25
cedkPilou: on fait du «best effort»11:25
Pilouje ne connais pas du tout le fonctionnement au niveau des plans comptables.11:26
cedkPilou: en fait on a un peu la même problématique, des données dont on ne maitrise pas l'évolution11:32
cedkPilou: donc on essaie de mettre à jour mais on supprime pas les anciens s'ils sont utilisés11:33

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!