IRC logs of #tryton for Monday, 2012-07-23 #tryton log beginning Mon Jul 23 00:00:01 CEST 2012
-!- sharoonthomas(~sharoonth@ has left #tryton07:47
marc0shi, is there any script around for migrating old translation csv files to the new .po ones? (i just wanted to ask before coding it myself)13:38
sampacmarc0s: I don't know the old csv system but you can export .po files with the translations as they stand in the database...14:10
cedkmarc0s: we did the migration by importing in the old system and than migrate the DB to the new one14:15
marc0ssampac: thanks :)14:16
marc0scedk: yes, the point is that now i have no old DB with me module already installed, but i could do it that way ...14:17
cedkmarc0s: it is easy to create one :-)14:19
marc0scedk: sure :) just laziness14:20
marc0si ended up with this if it's of interest to anyone14:58
sharoonthomascedk: there is a possibility for zero division error in project plan module if there are allocations with zero percentage assigned15:13
sharoonthomascedk: can we consider this a bug ? and if so should the patch handle a zerodivisionerror or check if total_allocation is zero ?15:14
bechamelsharoonthomas: IMO the fix would be to add a constrain on the percentage field15:17
sharoonthomasbechamel: not letting 0% in the allocation ?15:17
bechamelsharoonthomas: yes15:17
bechamelthis bug is there because when the module was written a required float meant also non-zero15:19
bechamelbut now a required field can be zero, so the constraint must be added15:20
cedkbechamel, sharoonthomas: it is nicoe who forget this one during migration15:24
bechamelnicoe: boooh! booh! ;)15:25
sharoonthomascedk: so will write a patch and send.. you will need a patch for both 2.4 and trunk ?15:25
sharoonthomasACTION won't it be better to have a `min` and `max` attribute on int and float fields which would validate when saving the record 15:28
bechamelsharoonthomas: this would make sense, but should be also implemented in the client15:29
cedksharoonthomas: only trunk because it can not be backported15:29
sharoonthomascedk: ok15:29
cedksharoonthomas: I think it must be domain15:29
sharoonthomasbechamel: will it be difficult to have on client ?15:30
cedkI think for domain support on non-relation field should be not too difficult15:31
sharoonthomascedk: an pylon already has gt, ge, lt, le15:31
bechamelthe main difficulty is to have something user-friendly15:34
cedkbechamel: field becomes red15:34
bechamelcedk: you should have missed "user-friendly" in my answer :)15:38
cedkbechamel: no15:44
bechamelcedk: currently, red == missing. here we need to tell the user that the value is out of domain. This is different.15:53
cedkbechamel: no, red == wrong15:55
cedkbechamel: look at the domain inversion15:59
bechamelcedk: so the user must guest the correct value by himself ?16:00
cedkbechamel: yes16:02
cedkbechamel: it is not optimal but I don't think it is possible to do better16:03
bechamelcedk: a simple message would be useful, like we have for the constraints16:07
cedkbechamel: not possible16:08
bechamelACTION thinks constraint and domains are the same things and should be merged :)16:08
cedkbechamel: not possible16:08
cedkbechamel: it is possible to express a constraint as a domain but not always16:09
bechamelit's Possimpible ! (
bechamelcedk: joke aside, why do you think that a custom message for domain is not possible ?16:13
bechamelcurrently we show "Invalid form" under the title, what about a dynamic string16:14
cedkbechamel: ok it is on impossible but will required a very much work16:17
cedkbechamel: because you have to make a sentence out of a domain16:17
cedkbechamel: or just show the domain16:18
cedkand the domain could be showed like in the search box16:25
bechamelcedk: no, the module developper must give an explicit message (just like the constraints, the framework doesn't make sentence from them)16:25
bechamelcedk: actually, I like the idea of "translating" the pyson domain into something "readable" by the user16:26
cedkbechamel: it is not possible16:26
cedkbechamel: I don't think you understand how domain inversion work16:28
bechamelcedk: I don't see why you talk about domain inversion actually16:30
cedkbechamel: because it define a domain for each fields16:31
cedkthis took me half a day to fix :-(18:28
bechamelcedk: what should be the traceback ?18:36
cedkbechamel: the one from property I think18:36
bechamelcedk: but maybe __getattr__ is called when an AttributeError is raised, so there are no way to know which one to raise18:38
bechamelcedk: it is not a bug but a feature18:40
cedkbechamel: yes of course but I think it is wrong to call __getattr__ for a property18:40
cedkbechamel: that's why I mark it as behavior18:40
bechamelcedk: IMO it is the expected behavior :)18:41
cedkbechamel: we will see18:46

Generated by 2.11.0 by Marius Gedminas - find it at!