IRC logs of #tryton-fr for Thursday, 2011-05-12

chat.freenode.net #tryton-fr log beginning Thu May 12 00:00:02 CEST 2011
-!- yangoon(~mathiasb@p549F29F3.dip.t-dialin.net) has joined #tryton-fr05:19
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton-fr09:49
-!- nicoe(~nicoe@62.58.29.41) has joined #tryton-fr09:51
-!- bechamel(~user@cismwks02-virtual1.cism.ucl.ac.be) has joined #tryton-fr10:07
-!- sisalp(~dominique@annecy.sisalp.net) has joined #tryton-fr14:48
nicoevoila14:49
sisalpsalut la question est donc : est il utile d'avoir des produits à prix de vente= 014:49
sisalpet les techniciens traduisent comment détecter que le prix est à 0 ou inconnu14:50
sisalpc'est ça ?14:50
cedkoui c'est nico qui est parti en vrille14:50
cedken fait, on a un problème qui est qu'on ne sait pas vendre des produits avec un prix de zero14:51
sisalpSisalp propose des abonnements gratuits et je dois les gérer, savoir à qui j'en ai livrés14:51
cedksisalp: tu fais une facture pour ça ?14:51
sisalpon ne sait pas vendre ou on ne sait pas créer ?14:52
cedksisalp: on ne sait pas créer car il y a une contrainte14:52
cedksisalp: mais cette contrainte est là pour se prémunir de l'encodage par erreur de ligne gratuit14:52
sisalpok donc j'ai un problème et je ne le savais pas ;-)14:52
cedksisalp: mais la contrainte est trop fort14:53
cedksisalp: c'est pour ça que j'ai proposer d'ajouter une check box qui donnerait l'autorisation d'encoder une ligne à 014:53
sisalpoui mais 0 est peut être une erreur, mais 100 ou mille peuvent aussi être faux14:53
cedksisalp: pour en revenir à tes abonements, est-ce que tu fais une facture pour les gratuits ?14:54
sisalpun client orange a reçu une facture de 70 M€14:54
cedksisalp: faut leur vendre une install Tryton :-)14:54
sisalpje pourrais la faire si je vends un service avec14:54
sisalple gratuit fait partie de contrat14:54
cedksisalp: c'est contournable avec quelque ligne de code14:55
nicoeACTION écrit une livre "De l'utilité de la différence entre 0 et NULL"14:55
cedksisalp: le problème du zéro, c'est qu'il est la valeur par defaut14:55
sisalppourquoi 0 est plus suspect qu'une autre valeur ?14:55
cedksisalp: 0 = valeur par defaut14:55
sisalpok14:56
cedksisalp: si tu ne met pas de produit par example14:56
sisalpla check box est dans la vente ?14:56
cedksisalp: oui14:56
sisalpmais le prix est dans le produit ?14:56
cedksisalp: je pense que si le prix du produit est zero alors la checkbox doit etre cochée automatiquement14:57
sisalpune case pour forer une ligne à 0 dans la vente semble ok alors14:57
sisalpla valeur par défaut de la checkbox est indifférente a mon avis14:58
sisalpforcer14:58
cedkde plus, on peut modifier le prix qui vient du produit14:58
cedksisalp: je dirai pas cocher pour garder le comportement actuel14:58
sisalpce qui est bizarre c'est qu'il est idiot de décocher la checkbox14:59
sisalpelle est donc décochée par défaut dans tous les cas14:59
cedksisalp: oui15:00
cedksisalp: elle sert juste à vérifier que l'utilisateur a vraiment bien réfléchit avant de mettre un prix de 015:01
sisalpne faut il pas  considérer qu'une valeur float est toujours valide et que des contrôles de saisie peuvent être ajoutées selon le masque de saisie ?15:01
sisalppar exemple import de données15:02
sisalpil y a une notion de controle de saisie dans tryton ?15:02
cedksisalp: on a pas encore de masque de saisie15:03
sisalpla vue n'en est pas un ?15:03
sisalpbtw un prix négatif pourrait aussi être "warné"15:04
cedksisalp: ca dépend du produit, ça peut etre un produit de réduction15:05
sisalpou une erreur ;-)15:05
bechamelACTION pense aussi que 0 != None15:06
sisalpmoi je pense plutôt de None n'existe pas dans l'ensemble des reels15:07
nicoeACTION se dit qu'on peut maintenant soumettre la question au vote lors d'une AG de B2CK ;)15:07
sisalpça va chier15:07
sisalpest ce qu'il existe une valeur non valide dans la représentation d'un float ?15:09
nicoeN'importe quelle valeur peut être une erreur en fait ... C'est pourquoi avoir un champs vide que l'utilisateur est obligé de remplir (ou qui est rempli automatiquement) c'est bien ...15:09
sisalpnicoe: mais dans ce cas tu dois avoir les actions remplir et vider ?15:10
sisalpquand même, si on oublie de faire payer, on ne mérite pas de vovre , non ?15:11
bechamel0 est une valeur comme une autre, None c'est l'absence de valeur (est-ce qu'on a pas déjà fait une modif du même ordre pour les booleén??)15:11
sisalpvovre15:11
sisalpvivre15:11
nicoeBen comme c'est un champs numérique on sait que s'il contient la chaine vide alors c'est qu'il est vide ...15:12
nicoesisalp: ou qu'on est très généreux avec ses clients15:12
sisalpplus sérieux, on doit vérifier le total d'un devis avant de l'envoyer.15:13
sisalpnicoe : oui, mais None ne sert qu'a semer la pagaille il me semble15:14
sisalpje ne rensigne pas le  prix. cas 1 je donne au client ce que je voulais lui vendre, cas 2 Traceback "c'est cet imbécile"15:15
sisalpmoi je préfère cas 115:18
sisalple required tryton est une contrainte en base ?15:19
sisalpon peut l'ajouter par la suite ?15:19
cedkbechamel: pour les booleen, on a just mis une contraint pour n'avoir que True/False et pas de None15:21
cedksisalp: le required est de base dans sale line15:22
sisalpcedk: comment c'est possible de ne pas avoir True/False ?15:22
cedksisalp: non seulement True/False15:23
cedkEn fait, pouvoir gérer des None dans les Float c'est une envie d'informaticien15:24
cedkdans la pratique c'est pas tres utile15:25
nicoeC'est juste utile dans les lignes de vente et de facture, des trucs d'informaticiens quoi ;)15:27
cedkbechamel: on a déjà eu cette discussion, il y a ~2 ans si tu te rappel bien15:27
bechamelcedk: oui oui15:27
cedksisalp: pour les controles dont tu parle, je pense qu'on pourrait faire un module de warning pour quand on encode un prix de vente qui s'écarte de x% du prix par defaut15:28
cedkACTION n'aurait jamais du faire entrer plus d'informaticien que d'ingénieur dans B2CK15:31
sisalpcedk: les controles de saisie devraient être paramétrables, en fonction des erreurs qu'on souhaite éviter15:32
sisalppar exemple mettre acide et base dans un même carton15:32
sisalpc'est fonctionnel, pas structurel15:33
cedksisalp: oui x serait définit dans une config15:33
sisalpdans ce cas, on pourrait faire un controle assisté par ordi des grilles de saisie15:34
nicoeACTION pense qu' un ingénieur c'est un mec qui a eu un VRAI cours de math15:34
sisalpsur des notes de frais, par exemple, ça serait super intéressant15:34
sisalpnicoe : comment on représente l'infini en float ?15:36
cedksisalp: float('inf')15:36
sisalpet pourquoi c'est pas la valeur None ?15:37
bechamelen fait, dans le cas qui nous occupe le problème c'est pas vraiment la DB mais l'interface graphique15:37
nicoeNone c'est undefined, c'est à dire même pas un concept mathématique15:37
cedkbechamel: +115:37
sisalpbechamel : +115:37
bechamelont n'accepte de toute façon pas none, c'est juste qu'on veut aussi accepter zero15:37
sisalpoui mais un prix float('inf'), c'est sur que c'est une erreur15:38
cedksisalp: je suis pas sur qu'on peut le mettre dans la DB float('inf')15:38
sisalppostgres ne sait pas stocker la taille de l'univers ?15:39
sisalpraté alors15:39
cedkACTION ce serait cool de faire une vente avec un prix ∞15:40
sisalpet une ristourne du meêm montant :-)15:40
nicoesisalp: postgres sait le contenir, il faut just choisir la bonne unité15:41
sisalpnicoe: lol15:41
sisalpon le trouve où le caractère infini ?15:42
bechamelhttp://www.postgresql.org/docs/8.2/static/datatype-numeric.html#AEN406815:43
bechamelqui donne comme exemple : UPDATE table SET x = 'Infinity'15:43
bechamelsinon, j'ai testé, "SELECT sum(amount) .." retourne bien la somme des non-null15:44
bechamelmais c'est vrai que pour monsieur tout-le-monde ce genre de subtilité est à éviter15:45
cedkbechamel: mais "SELECT a + b" si un des deux est null pose problème15:46
cedkbechamel: est les clause du genre > 0 ?15:47
bechamelcedk: oui ça retourne null, mais c'est logique15:47
cedkbechamel: je dis pas que c'est pas logique15:48
cedkbechamel: mais que c'est un problème qu'on risque de rencontrer si on autorise NULL pour les float15:48
nicoeÉcrit-on tant de query sql ?15:51
nicoeMême si avec pysql il pourrait y en avoir plus, c'est quand même un truc à éviter15:51
nicoenon ?15:51
cedknicoe: non15:52
nicoeJe pense que si tu dois utiliser une valeur dans ton calcul c'est que le champs doit avoir reçu une valeur15:55
bechamelsinon pour en revenir au problème du début, est-ce que ce n'est pas mieux de mettre la checkbox qui authorise un prix de zéro directement sur le produit ?15:55
cedknicoe: donc comme on utilise toujours les champs qu'on crée, ils doivent tous avoir une valuer :-) CQFD15:55
nicoeben non15:56
cedkbechamel: pourquoi?15:56
bechamelcedk: ben je sais pas, j'imagine qu'on ne vend à zéro que certain produit particulier15:57
nicoecedk: tu préconises donc de rendre tous les champs requis si j'ai bien compris ;)15:57
bechameldu coup, ça facilite l'encodage des lignes15:57
cedkbechamel: quid du produit que tu offres15:58
cedknicoe: non seulement les Float comme c'est maintenant15:58
bechameloui en fait si on veut faire le truc a font il faut le faire sur les deux, la checkbox sur le produit donne la valeur par defaut de la checkbox sur la ligne16:00
bechamelcedk: les float, integer et boolean  non ?16:01
nicoesauf que comme c'est maintenant c'est buggé16:01
nicoele simple exemple de l'encodage des enfants pour un formulaire d'assurance le montre16:05
nicoeEt puis, si tu fais ta query en sql, normallement tu connais l'existence de coalesce16:06
cedknicoe: tu peux utiliser -1 comme valeur16:07
nicoecomme valeur pour quoi ? -1 pour moi c'est -1, pas autre chose16:12
cedknicoe: -1 enfant ça n'existe pas16:13
nicoeOn a pas -1 enfants Christine et moi mais 0. Et si par exemple l'assurance nous rembourse leur décès au pro rata de leur nombre ben je veux pas leur devoir de l'argent (la peine étant déjà bien assez lourde)16:16
cedknicoe: ben tu met zero si tu a zero enfant16:17
cedken fait, tu ne sais rien faire avec des None16:19
cedkil n'y a aucune information16:19
cedkdonc je pense que dans ton example, il faudra une validation du formulaire et donc une valeur sera donnée16:20
cedkbechamel: je vois pas trop l'interet de la checkbox sur le produit16:20
nicoeC'est un champs requis, je peux pas mettre 016:24
cedknicoe: pq ?16:24
nicoet'es borné c'est fou16:25
bechamelcedk: ben si tu a un produit cadeau que tu donne systématiquement ça évite de cliquer la checkbox sur la ligne de vente16:27
cedkbechamel: relit plus haut16:30
bechamelben je lis "Sisalp propose des abonnements gratuits" dans ce cas j'imagine que c'est plus simple de mettre la checvkbox sur le produit (qui a lui-même sont prix unitaire à zero) -> mais effectivement je lis plus bas la regle du % qui résoud le problème.16:34
cedkbechamel: non, si le list price est 0 alors on check automatiquement la checkbox16:35
cedknicoe: "patch is welcome" mais alors pour la consistance du system il faut qu'on puisse mettre un NULL dans tous les champs16:37
bechamelcedk: je trouve la règle du % plus élégante (interface plus simple + gère plus de situations)16:37
cedket il faudrait avoir un nonzero, nonempty etc.16:37
cedket il faudra aussi un system pour différencier un Many2One vide d'un pas connu16:38
cedkpareil pour les M2M16:38
nicoeMais c'est n'importe quoi16:38
nicoeTu refuses une amélioration sous le prétexte qu'il faudrait la faire pour tous les champs16:38
bechamelen fait j'ai naturellement tendance à favoriser la gestion des null, mais je suis incapable de trouver une situation où c'est vraiment utile16:39
cedknicoe: non s'il y a un interet à avoir une valeur NULL pour un float alors il y a aussi le meme interet pour les autres champs16:39
cedkbechamel: je pense que le module de % est une extention et ne doit pas etre de base16:40
cedkbechamel: le cas du zero du prix de vente et un cas particulier16:40
cedkbechamel: pas gérable par un %16:41
bechamelcedk: pq pas ?16:41
nicoeIl y a un intérêt pour les autres champs, on peut d'ailleurs le faire pour le booléen16:41
bechamelfaut juste faire un test pour éviter la division par zero16:41
cedkbechamel: ben l'ecart en % d'un prix par rapport à zéro n'existe pas16:42
bechamelcedk: ben un produit dont le prix de base est non-null qui est vendu pour 0 est considéré comme depassant l'écart (peut importe ça valeu), ça me semble naturel16:43
nicoeJe propose donc que pour la consistance du système on décide d'une valeur par défaut pour les champs date16:44
bechamelnicoe: quel exemple concret vois-tu où la gestion du null apporterait qqch de mieux  ?16:44
cedkbechamel: du coup tu ne sais pas donner des produits16:44
nicoeJe te l'ai déjà donné 1000x16:44
bechamelcedk: ben si mais tu a un warning16:44
cedkbechamel: oauis16:44
nicoeEt même pour le unit_price à 0 ça donne quelque chose aussi d'ailleurs16:44
bechamelnicoe: ben le seul que je vois c'est le nombre d'enfant, mais pour moi c'est un contre-exemple. tu a effectivement 0 enfant. null pourrait être intérressant pour modéliser le fait que tu ne connais pas le nombre d'enfant.16:46
cedkbechamel: y a aussi qu'on a pas toujours un produit dans une vente16:46
nicoeEt le unit_price à 0 ?16:46
bechamelcedk: damn !16:46
nicoene me réponds pas par un workaround, je sais qu'il existe ...16:47
cedken fait, ce que veut nicoe c'est splitter le concept de required en deux:16:51
cedk- notnull16:51
cedk- notzero/false16:51
cedk.. notzero/false/empty16:51
cedkmais perso, je pense que les gens aiment bien développer dans Tryton/OE parce que justement des choix on été fait qui simplifie la vie dans la grosse majorité des cas16:54
nicoepour moi required == notnull en effet16:55
cedknicoe: ce qui est faut pour la mojorité de fields de Tryton16:56
cedks/faut/faux/16:56
cedken fait required actuellement c'est: ne doit pas etre evaluer à False en Python16:57
nicoeCe qui est stupide pour les nombres, car 0 est un nombre comme un autre16:57
cedknicoe: ask Guido16:57
nicoeGuido n'a rien à voir là dedans16:58
-!- bechamel(~user@host-85-201-144-79.brutele.be) has joined #tryton-fr21:14
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton-fr21:17

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