Community mailing list archives
Re: Sale and purchase workflowby
Sorry all my links went badshould be the last two. Also in that last one, it seems crazy that only the superuser is filtered for company_id. Surely it would apply to any multicompany user and just as efficient for a single company one and could just use one lot of code instead of if statements.
On Fri, Sep 18, 2015 at 10:39 AM, Graeme Gellatly <firstname.lastname@example.org> wrote:
In https://github.com/odoo/odoo/blob/9.0/addons/sale/sale.py#L384 it is a bit difficult to understand what is going on. In general there are no docstrings or help throughout making community adjustment that much more difficult.For example in https://github.com/odoo/odoo/blob/9.0/addons/sale/sale.py#L47 the order lines are iterated over 4 times. This seems pointless and could just be once.There are some decisions that have been made maybe based on very small orders or very simple workflows.Hi Fabien,I just conducted a very quick static review of one file and I really think we do need to give this a little time for review.
https://github.com/odoo/odoo/blob/9.0/addons/sale/sale.py#L384 here it seems a design decision has been made that invoices out count towards quantity but refunds are not to decrement it. I'd like to understand that. A common action is/was refund and modify, to me that would double count.
https://github.com/odoo/odoo/blob/9.0/addons/sale/sale.py#L384 here one of the most frustrating inconsistencies has been retained. Sale Orders get their tax from the product, invoices fallback to the account. Pretty please change this. In multicompany environments this is so frustrating. Only a user with access to all companies can create a product if it needs taxes. If another user does, then another company uses it, no tax gets charged.On Fri, Sep 18, 2015 at 9:24 AM, Graeme Gellatly <email@example.com> wrote:Actually looking forward to this change. Might jump early to 9 than intending depending on how buggy it is, whether they get fixed. Seems to fit nicely for my business even though I can see it being a lot of rewrite work for existing customizations. I get that for complex installs it may create issues but for me the existing workflows create issues too and training users in what scenario to use what workflow is always fun.Of course a roadmap would be nice, especially since only a few days ago a code freeze was announced. Seems every release a massive surprise hits just before launch. 6.0 - not 5.x, new web client, 6.1 - Hmm no surprises I remember, 7.0 - Partner Model, 8.0 Reports/Products, 9.0 Sale/Purchase and ???. Also agree that perhaps the first few months an early release stable policy should be maintained where outright refusal of changes isn't the norm and can be considered or at least a one month Release Candidate period. There will be errors and oversights and there really isn't very thorough testing in these modules. How do I know this - see previous surprises.
Fun fact, around 50% of our database CPU time is deleting workflow related records. Another 5-10% is creating them. Now of course stock moves is the large majority of these, but still less contention on that table all good by me.On Fri, Sep 18, 2015 at 5:28 AM, Nhomar Hernández <firstname.lastname@example.org> wrote:2015-09-17 12:18 GMT-05:00 Nhomar Hernández <email@example.com>:If one of my programmers should offer me such solution, I inmediatly stopped them in any case and fired him inmediatly ;-), we solved already a lot of performance issue without remove the workflow.And Community.Be carefull to misinterprete my conclusions here, I support and will support odoo always, we live frem this environment 100% of our day by day live, but honestly this kind of moves piss me off....At the end of the day I will learn the new way to do thing, but not as happy as usual.