| chat.freenode.net #tryton log beginning Fri Jan 31 00:00:01 CET 2014 | ||
| 2014-01-31 09:29 <buxy> Can 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 ? | ||
| 2014-01-31 09:32 <pokoli> buxy: can you be more verbose? | ||
| 2014-01-31 09:34 <buxy> pokoli: I have done some cleanup in the french chart of accounts (see http://codereview.tryton.org/3121002) in a total of 3 commits. | ||
| 2014-01-31 09:35 <buxy> the changes can be considered separately on their own merit but patch3 depends on patch2 right now because they do different changes to some common accounts | ||
| 2014-01-31 09:35 <buxy> (unfortunately I discovered after the fact that upload.py with a git-hg repository would not display the 3 commits as 3 patch sets) | ||
| 2014-01-31 09:43 <pokoli> buxy: so for me is one codereview per commit, you can put in the description a link to the other required codereviews if they have dependencies | ||
| 2014-01-31 10:07 <Pilou> buxy: there is an example here: http://codereview.tryton.org/711003/ (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'. | ||
| 2014-01-31 10:09 <buxy> Right, it's not very convenient to use. | ||
| 2014-01-31 10:14 <grasbauer> cedk: ping | ||
| 2014-01-31 10:16 <cedk> grasbauer: pong | ||
| 2014-01-31 10:19 <grasbauer> cedk: 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. | ||
| 2014-01-31 10:20 <cedk> grasbauer: CTRL+d is for the all form and Del is for the widget | ||
| 2014-01-31 10:22 <grasbauer> cedk: shure thats is a user error - I was thinking of a better deletion message - to put the model in the message or something like this | ||
| 2014-01-31 10:22 <cedk> grasbauer: why not | ||
| 2014-01-31 10:23 <grasbauer> cedk: ok, so I wanna try this - never tochd the client in deep before :) | ||
| 2014-01-31 10:26 <Pilou> buxy: There are git repositories mirrored on github foreach projects: https://github.com/tryton/. | ||
| 2014-01-31 10:29 <cedk> buxy: codereview is about pre-commit review so you have to work on different clone without commiting | ||
| 2014-01-31 10:30 <buxy> cedk: I'm a git user and I'm used to have branches that I rebase to integrate changes from review | ||
| 2014-01-31 10:31 <buxy> honestly, I was keen to try out tryton but the more I see the more I have doubts | ||
| 2014-01-31 10:32 <buxy> not technical but in the way the project is managed | ||
| 2014-01-31 10:33 <buxy> I 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. | ||
| 2014-01-31 10:34 <cedk> buxy: we can do nothing if the French community did not take step earlier to prepare this change | ||
| 2014-01-31 10:34 <buxy> cedk: you can accep an exception to your rule | ||
| 2014-01-31 10:34 <buxy> If something breaks, it will French users only who will be affected. | ||
| 2014-01-31 10:35 <cedk> buxy: no because it requires historization which will impact everybody | ||
| 2014-01-31 10:35 <pokoli> buxy: I wonder how you reached the conclusion of duplicated taxes in the switch to 3.2 | ||
| 2014-01-31 10:36 <pokoli> buxy: AFAIK if xml id are the same it won't produce any tax duplication | ||
| 2014-01-31 10:37 <buxy> pokoli: and how are persons supposed to guess xml ids ? And I don't see a way to input the xml id in the client... | ||
| 2014-01-31 10:38 <pokoli> buxy: it's managed internally in tryton. See ir.model.data, no need for persons to guess xml_ids | ||
| 2014-01-31 10:38 <pokoli> buxy: so you have to manually apply your patch to your running version, and when upgrading to 3.2 remove it | ||
| 2014-01-31 10:39 <buxy> cedk: people want solution that works with 3.0 even if it requires changes to their products, we can add historization after the fact if | ||
| 2014-01-31 10:39 <cedk> pokoli: yes but it is always better to have clean XML ids, so a migration of ir.model.data record to the new one is good | ||
| 2014-01-31 10:40 <cedk> buxy: people are free to use your patch but then we could not garantee the migration | ||
| 2014-01-31 10:40 <buxy> cedk: 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 taxes | ||
| 2014-01-31 10:40 <cedk> buxy: what is your solution for 3.0 ? | ||
| 2014-01-31 10:42 <cedk> buxy: if it is about creating extra taxes then how the user will update taxes on all his products ? | ||
| 2014-01-31 10:42 <cedk> buxy: how will it update back when the historization will be there ? | ||
| 2014-01-31 10:42 <cedk> buxy: how will you manage the case of migration from 2.8 to 3.2 ? | ||
| 2014-01-31 10:43 <cedk> so people who wants it, can still add them manually | ||
| 2014-01-31 10:45 <cedk> so yes, it is a pitty that French guys did not care before about this, so now we have to deal with it for 3.2 | ||
| 2014-01-31 10:45 <buxy> cedk: I don't know enough of what can be done with ir.model.data to provide a good answer, are the "ids" used as primary keys and referenced in other tables? | ||
| 2014-01-31 10:45 <cedk> buxy: ir.model.data is used to link xml ids to database ids | ||
| 2014-01-31 10:48 <buxy> cedk: so we good in theory switch the ids without breaking the links ? | ||
| 2014-01-31 10:48 <buxy> s/good/could/ | ||
| 2014-01-31 10:49 <cedk> by the way, we don't want to rush for a solution but want to provide a good one | ||
| 2014-01-31 10:49 <buxy> Where could the code that plays with ir.model.data be hosted and do we have similar examples in the codebase somewhere? | ||
| 2014-01-31 10:50 <cedk> buxy: yes, already did: http://hg.tryton.org/modules/stock/file/f16059813d1a/shipment.py#l179 | ||
| 2014-01-31 10:50 <cedk> buxy: we try to put such things in the Model.__register__ that is affected | ||
| 2014-01-31 10:53 <buxy> so it would be in account/TaxTemplate and Tax ? | ||
| 2014-01-31 10:55 <cedk> buxy: in account_fr module | ||
| 2014-01-31 10:56 <cedk> buxy: I propose to fix it on trunk and someone could publish a patch with the fix for 3.0 for those who want it | ||
| 2014-01-31 10:58 <buxy> cedk: having the fix in account_fr seems better but that module doesn't provide a Model, no? | ||
| 2014-01-31 10:58 <cedk> buxy: no, it should be added | ||
| 2014-01-31 10:59 <buxy> cedk: what model? | ||
| 2014-01-31 10:59 <buxy> A new model dedicated to the upgrade logic? | ||
| 2014-01-31 11:03 <cedk> buxy: yes | ||
| 2014-01-31 12:34 <pokoli> buxy: 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? | ||
| 2014-01-31 12:35 <pokoli> buxy: may http://code.google.com/p/tryton/wiki/AccountsChartVariants be usefull for the france use case? | ||
| 2014-01-31 12:36 <buxy> pokoli: the 3 charts are compatible, they are subset/superset | ||
| 2014-01-31 12:36 <buxy> but some of the accounts in the reduced/standard chart are actually configured as views in the extended chart that tryton provides | ||
| 2014-01-31 12:37 <buxy> so I just want to switch them to real accounts so that it's possible to use the subset of interest | ||
| 2014-01-31 12:38 <pokoli> buxy: so if someone what's to use the reduced/standard you mark the not needed accounts as inactive, and desconfigure the views? | ||
| 2014-01-31 12:39 <buxy> Nope. I don't care if I see too many accounts. | ||
| 2014-01-31 12:41 <buxy> The 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. | ||
| 2014-01-31 12:47 <buxy> So I submitted https://bugs.tryton.org/issue3631 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) | ||
| 2014-01-31 12:55 <Pilou> buxy: only cedk is allowed to allow your review to be commited | ||
| 2014-01-31 12:57 <Pilou> There is one maintainer/leader for each project. There are listed here: http://code.google.com/p/tryton/wiki/ProjectOrganization#Sub-projects | ||
| 2014-01-31 13:01 <Pilou> 1) cekd will comment your reviews with "LGTM" (for example http://codereview.tryton.org/3151002/) (if not you must improve the patch according to his comments) 2) you should attach a patch to the https://bugs.tryton.org/issue3631 3) cedk will commit the path | ||
| 2014-01-31 13:01 <Pilou> s/path/patch | ||
| 2014-01-31 13:05 <trc> In If expression in domain, is else part mandatory ? | ||
| 2014-01-31 13:06 <cedk> trc: yes PYSON must always be "evalutable" | ||
| 2014-01-31 13:10 <trc> cedk: 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)? | ||
| 2014-01-31 13:12 <trc> cedk: 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 mind | ||
| 2014-01-31 13:13 <cedk> trc: [] | ||
| 2014-01-31 13:15 <trc> cedk: ok thanks | ||
| 2014-01-31 13:30 <rmu> I want to ask about opinions regarding https://code.google.com/p/tryton/wiki/TrytonMRPIntegration#Phantom_Subassembly_Module(production_phantoms) | ||
| 2014-01-31 13:31 <rmu> I built a small proof-of-concept module that implements (more or less) phantom products | ||
| 2014-01-31 13:31 <rmu> but to me it is not eniterly clear which object should have the "phantom" designation | ||
| 2014-01-31 13:32 <rmu> probably it is another "kind" of product like service, consumable, stockable | ||
| 2014-01-31 13:34 <rmu> sorry that should have been goods, assets, services | ||
| 2014-01-31 13:36 <rmu> other possibilities would be the BOM and even the BOM-line could make sense | ||
| 2014-01-31 13:37 <cedk> rmu: indeed I think it will be better to prevent to create a product | ||
| 2014-01-31 13:37 <cedk> rmu: so a kind of mixin BOM will be great | ||
| 2014-01-31 13:37 <cedk> rmu: it could be just a m2m on bom to include the input/output of other boms | ||
| 2014-01-31 13:43 <rmu> cedk: something analogous to bom inputs and outputs, except with other BOMs instead of products? | ||
| 2014-01-31 13:45 <cedk> rmu: I think just copying input/outputs of an other bom | ||
| 2014-01-31 13:45 <trc> I wish to do something like this? Seems like its not correct Eval('reference_field.__name__') | ||
| 2014-01-31 13:46 <cedk> trc: Eval of reference field should return a string 'model,id' | ||
| 2014-01-31 13:48 <trc> Ok. In that case is there a way check if model name is equal to something specific | ||
| 2014-01-31 13:50 <rmu> cedk: how to deal with quantities? have some kind of multiplier on the m2m line? | ||
| 2014-01-31 13:50 <cedk> trc: I don't think so | ||
| 2014-01-31 13:50 <cedk> rmu: yes probably so it will be one2many | ||
| 2014-01-31 13:51 <trc> cedk: ok. Thanks for help :) | ||
| 2014-01-31 14:04 <rmu> cedk: i will try to come up with a module | ||
| 2014-01-31 14:19 <buxy> Pilou: thanks, and what does LGTM stands for? | ||
| 2014-01-31 14:23 <Pilou> "looks good to me" | ||
| 2014-01-31 15:30 <rmu> cedk: it is not a simple copy, (bom, product) has to be unique | ||
| 2014-01-31 15:39 <cedk> rmu: who says that? | ||
| 2014-01-31 15:49 <rmu> cedk: http://hg.tryton.org/modules/production/file/a46bc3dc10c7/bom.py#l77 | ||
| 2014-01-31 15:50 <rmu> cedk: nevermind, i was confused | ||
| 2014-01-31 15:53 <rmu> copying will only happen into production input/output moves | ||
| 2014-01-31 20:51 -!- strebitz(~sebastian@91.183.59.105) has left #tryton |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!