Community mailing list archives
Re: Sale and purchase workflowby
The inconsistency is hugely annoying (well requires a custom module at least). Consider the most common use case, VAT. With very few exceptions this is generally charged. Now a user creates a product and doesn't have access to one company. The company is losing money or breaking the law or both.
On sale orders it takes it from taxes_id - not a property.
Hi Fabien,On invoices it takes it from the account, itself a property field of product.template
You miss my point re taxes.
You miss my point re taxes.
If you look at partners, products or any static data model that is generally shared, the multicompany fields are property fields which means defaults work. These taxes are the only exception meaning that essentially the act of creating a product can only be performed by an administrator EVEN IF defaults have been set.
If you either a: make this field a property field or b: make sale orders behave the same way as invoices then personally I think you create a huge usability improvement for very little effort.
Also re GTK, I'm sure it wasn't 6.1. Maybe it was but it worked fine for years.
On Sat, Sep 19, 2015 at 1:18 AM, Alexandre Fayolle <firstname.lastname@example.org> wrote:
On 16/09/2015 13:17, Fabien Pinckaers wrote: > There are several approaches to hook in the code. Use the one that fits > your use case: > > - extend on the action, not the event (easy if you want to change the > behaviour of an action, just a method to overwrite) > - extend on the recompute of the computed field (easy if you want to > trigger something new on a change: e.g. if the invoice_status changed, > just a method to overwrite) > - extend on write/create (not super clean, but basically the same than > what the workflow was doing) > - extend the trigger of the change of the computed field (extend @depends) > Hello Fabien, We can certainly make such approach work (even if I think this is not moving in the best direction). However, I'm begging you to consider porting at least the computed fields of stock.py in v9 to the new API. The fact that the state of stock.pickings is declared using the old API has very nasty consequences: * overriding the field is harder than required, and cannot be done in the new API afaik * it is not possible to call other pieces of code from within the overridden function and expect these calls to see the updated state of the picking. It sure is possible to work around this but readability and maintainability are badly harmed in the process If we are to extend the recompute of computed fields, please pretty please help us by having all these computed fields in v9 be declared with the new API. Thanks for your work on Odoo, and for considering this request. -- Alexandre Fayolle Chef de Projet Tel : +33 4 58 48 20 30 Camptocamp France SAS Savoie Technolac, BP 352 73377 Le Bourget du Lac Cedex http://www.camptocamp.com