Community mailing list archives
Re: Sale and purchase workflowby
Elmatica AS, Luis Alberto Panozzo
Where is this documented. please?
This and other nuances as far as configuration is concerned.
Thank you in advance
On 19 September 2015 at 12:13, Antony Lesuisse <email@example.com> wrote:
If records rules are set correctly you should only see the taxes from the company you are currently in. To setup the product P1, as a regular user switch to company A and set P1.taxes_id = [TA1, TA2] The switch to company B and set P1.taxes_id = [TB1, TB2] If you are loggued as administrator you see P1.taxes_id = [TA1, TA2, TB1, TB2] but it's forbidden to work as administrator in a multi company environement. As a regular user everything work perfectly because of the record rules. On 09/19/2015 09:04 AM, Graeme Gellatly wrote: > Hi Fabien, > > You miss my point re taxes. > > On invoices it takes it from the account, itself a property field of > product.template > On sale orders it takes it from taxes_id - not a property. > > 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. > > 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 > > 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 > > _______________________________________________ > Mailing-List: https://www.odoo.com/groups/community-59 > Post to: mailto:firstname.lastname@example.org <mailto:email@example.com> > Unsubscribe: https://www.odoo.com/groups?unsubscribe > > > _______________________________________________ > Mailing-List: https://www.odoo.com/groups/community-59 > Post to: mailto:firstname.lastname@example.org > Unsubscribe: https://www.odoo.com/groups?unsubscribe >