IRC logs of #tryton for Friday, 2014-01-31 #tryton log beginning Fri Jan 31 00:00:01 CET 2014
buxyCan we open a single code review ticket for multiple successive changes that are unrelated but that still do affect the same parts of a single XML file and are thus interlinked ?09:29
pokolibuxy: can you be more verbose?09:32
buxypokoli: I have done some cleanup in the french chart of accounts (see in a total of 3 commits.09:34
buxythe changes can be considered separately on their own merit but patch3 depends on patch2 right now because they do different changes to some common accounts09:35
buxy(unfortunately I discovered after the fact that with a git-hg repository would not display the 3 commits as 3 patch sets)09:35
pokolibuxy: so for me is one codereview per commit, you can put in the description a link to the other required codereviews if they have dependencies09:43
Piloubuxy: there is an example here: (required reviews are indicated in the description). By the way it seems that a 'patch set n+1' is a modified version of 'patch set n'.10:07
buxyRight, it's not very convenient to use.10:09
grasbauercedk: ping10:14
cedkgrasbauer: pong10:16
grasbauercedk: I just get an call because of the following mistake a customer has done: he pressed str+d in a One2Many and exspected to delete the line.10:19
cedkgrasbauer: CTRL+d is for the all form and Del is for the widget10:20
grasbauercedk: shure thats is a user error - I was thinking of a better deletion message - to put the model in the message or something like this10:22
cedkgrasbauer: why not10:22
grasbauercedk: ok, so I wanna try this - never tochd the client in deep before :)10:23
Piloubuxy: There are git repositories mirrored on github foreach projects:
cedkbuxy: codereview is about pre-commit review so you have to work on different clone without commiting10:29
buxycedk: I'm a git user and I'm used to have branches that I rebase to integrate changes from review10:30
buxyhonestly, I was keen to try out tryton but the more I see the more I have doubts10:31
buxynot technical but in the way the project is managed10:32
buxyI mean how can we let French users out in the cold without any solution to their tax changes? I can of course create new taxes on my own for me. But then when I switch to 3.2 I will have duplicated taxes.10:33
cedkbuxy: we can do nothing if the French community did not take step earlier to prepare this change10:34
buxycedk: you can accep an exception to your rule10:34
buxyIf something breaks, it will French users only who will be affected.10:34
cedkbuxy: no because it requires historization which will impact everybody10:35
pokolibuxy: I wonder how you reached the conclusion of duplicated taxes in the switch to 3.210:35
pokolibuxy: AFAIK if xml id are the same it won't produce any tax duplication10:36
buxypokoli: and how are persons supposed to guess xml ids ? And I don't see a way to input the xml id in the client...10:37
pokolibuxy: it's managed internally in tryton. See, no need for persons to guess xml_ids10:38
pokolibuxy: so you have to manually apply your patch to your running version, and when upgrading to 3.2 remove it10:38
buxycedk: people want solution that works with 3.0 even if it requires changes to their products, we can add historization after the fact if10:39
cedkpokoli: yes but it is always better to have clean XML ids, so a migration of record to the new one is good10:39
cedkbuxy: people are free to use your patch but then we could not garantee the migration10:40
buxycedk: I mean we can add another update to the chart of account for 3.2 where the new taxes become the rate-agnostic parent of the rate-specific taxes10:40
cedkbuxy: what is your solution for 3.0 ?10:40
cedkbuxy: if it is about creating extra taxes then how the user will update taxes on all his products ?10:42
cedkbuxy: how will it update back when the historization will be there ?10:42
cedkbuxy: how will you manage the case of migration from 2.8 to 3.2 ?10:42
cedkso people who wants it, can still add them manually10:43
cedkso yes, it is a pitty that French guys did not care before about this, so now we have to deal with it for 3.210:45
buxycedk: I don't know enough of what can be done with to provide a good answer, are the "ids" used as primary keys and referenced in other tables?10:45
cedkbuxy: is used to link xml ids to database ids10:45
buxycedk: so we good in theory switch the ids without breaking the links ?10:48
cedkby the way, we don't want to rush for a solution but want to provide a good one10:49
buxyWhere could the code that plays with be hosted and do we have similar examples in the codebase somewhere?10:49
cedkbuxy: yes, already did:
cedkbuxy: we try to put such things in the Model.__register__ that is affected10:50
buxyso it would be in account/TaxTemplate and Tax ?10:53
cedkbuxy: in account_fr module10:55
cedkbuxy: I propose to fix it on trunk and someone could publish a patch with the fix for 3.0 for those who want it10:56
buxycedk: having the fix in account_fr seems better but that module doesn't provide a Model, no?10:58
cedkbuxy: no, it should be added10:58
buxycedk: what model?10:59
buxyA new model dedicated to the upgrade logic?10:59
cedkbuxy: yes11:03
pokolibuxy: I see in a review message that in france there are three chart of accounts, do you have some requirements for using standard and reduced in tryton?12:34
pokolibuxy: may be usefull for the france use case?12:35
buxypokoli: the 3 charts are compatible, they are subset/superset12:36
buxybut some of the accounts in the reduced/standard chart are actually configured as views in the extended chart that tryton provides12:36
buxyso I just want to switch them to real accounts so that it's possible to use the subset of interest12:37
pokolibuxy: so if someone what's to use the reduced/standard you mark the not needed accounts as inactive, and desconfigure the views?12:38
buxyNope. I don't care if I see too many accounts.12:39
buxyThe rules are not set in stone, you are allowed to use the level that makes sense for your company, you can use the extended accounts in one part if you need that level of details and the standard account in another parts where splitting doesn't bring any value to your company.12:41
buxySo I submitted What should I expect from now on? Are there rules on number of reviewers ? Who gets to decide whether to apply it or not ? Are there maintainers for each module ? (I couldn't find any answer to those questions in the wiki or on the website)12:47
Piloubuxy: only cedk is allowed to allow your review to be commited12:55
PilouThere is one maintainer/leader for each project. There are listed here:
Pilou1) cekd will comment your reviews with "LGTM" (for example (if not you must improve the patch according to his comments) 2) you should attach a patch to the 3) cedk will commit the path13:01
trcIn If expression in domain, is else part mandatory ?13:05
cedktrc: yes PYSON must always be "evalutable"13:06
trccedk: OK. I wish to add a domain only if condition is true otherwise select everything. What is domain tuple to select everything, something like (True, '=', True)?13:10
trccedk: BTW I'm sorry I couldn't check the fix for stock_shipment_sale (on_change_with problem). I got involved somewhere else and it got off my mind13:12
cedktrc: []13:13
trccedk: ok thanks13:15
rmuI want to ask about opinions regarding
rmuI built a small proof-of-concept module that implements (more or less) phantom products13:31
rmubut to me it is not eniterly clear which object should have the "phantom" designation13:31
rmuprobably it is another "kind" of product like service, consumable, stockable13:32
rmusorry that should have been goods, assets, services13:34
rmuother possibilities would be the BOM and even the BOM-line could make sense13:36
cedkrmu: indeed I think it will be better to prevent to create a product13:37
cedkrmu: so a kind of mixin BOM will be great13:37
cedkrmu: it could be just a m2m on bom to include the input/output of other boms13:37
rmucedk: something analogous to bom inputs and outputs, except with other BOMs instead of products?13:43
cedkrmu: I think just copying input/outputs of an other bom13:45
trcI wish to do something like this? Seems like its not correct Eval('reference_field.__name__')13:45
cedktrc: Eval of reference field should return a string 'model,id'13:46
trcOk. In that case is there a way check if model name is equal to something specific13:48
rmucedk: how to deal with quantities? have some kind of multiplier on the m2m line?13:50
cedktrc: I don't think so13:50
cedkrmu: yes probably so it will be one2many13:50
trccedk: ok. Thanks for help :)13:51
rmucedk: i will try to come up with a module14:04
buxyPilou: thanks, and what does LGTM stands for?14:19
Pilou"looks good to me"14:23
rmucedk: it is not a simple copy, (bom, product) has to be unique15:30
cedkrmu: who says that?15:39
rmucedk: nevermind, i was confused15:50
rmucopying will only happen into production input/output moves15:53
-!- strebitz(~sebastian@ has left #tryton20:51

Generated by 2.11.0 by Marius Gedminas - find it at!