openerp-dev-web team mailing list archive

["Olivier Dony \(OpenERP\)" <odo@xxxxxxxxxxx>]

> Technical side :
> The Fields.related will take an impact only once the record is saved, and will
> not have the desired effect on onchange. This way, fields.dummy have an edge
> to fields.related in this case.

It think fields.dummy doesn't specifically help here, you could do the same with fields.related too, with the same on_change that would update the client side.
The only thing you need to be careful with, is that this field should never be saved, otherwise you may alter the tracking status of the product if something went wrong.


> At the other hand, reopening the saved form will give us a hint that
> fields.related will be a better option. As a solution, I opted to override
> write() as shown above.
> As an overall effect, to have less(negligible) burden on server, I chose this
> approach.

This override of write() seems a bit hacky, and pushes the error to the server-side, but it will do the job too, so I guess it's sufficient for stable.


> Functional side:
> I agree this is not a bug, but yes, it adds a nice handling of allowing stock
> handler to assign Lots as and when needed.Consider the same way like having
> required accounts on journals of type=cash.

Yes, it appears to do that, but in fact my intuition is it will create problems with the current implementation of physical inventories, because production lots are meant to be specified only for initial inventories.
This patch would make it required all the time if the [unrelated!] checkbox is checked on the product form, leading to very strange behavior for corrective inventories.
See comment #18 on the bug report for some explanation [1].


[1] https://bugs.launchpad.net/openobject-addons/+bug/700928/comments/18
-- 
https://code.launchpad.net/~openerp-dev/openobject-addons/6.0-bug-700928-jvo/+merge/55334
Your team OpenERP R&D Team is subscribed to branch lp:~openerp-dev/openobject-addons/6.0-bug-700928-jvo.