Community mailing list archives

Re: Sale and purchase workflow

Antony Lesuisse (al)
- 09/19/2015 06:07:59
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 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
>     _______________________________________________
>     Mailing-List:
>     Post to: <>
>     Unsubscribe:
> _______________________________________________
> Mailing-List:
> Post to:
> Unsubscribe: