diff options
| author | jem-odoo <jem@openerp.com> | 2018-06-07 14:06:26 +0200 |
|---|---|---|
| committer | jem-odoo <jem@openerp.com> | 2018-08-10 16:30:19 +0200 |
| commit | 80ef7146d21eb5763336fc11b0ad964910be4730 (patch) | |
| tree | a4a26edd2c620239fc3383dd4edb081c8c3f7d83 /addons/website/static/src/xml/website.editor.xml | |
| parent | 867e47927dc9e38f397f8abc4dc5e295784331b4 (diff) | |
[REF] sale_*: '_action_confirm' implementation
Impacted modules: sale, sale_timsheet, sale_stock, delivery and
event_sale
The commit ee2b9fae3519c2494f34dacf15d0a3b5bd8fbd06 split the
implementation and the api of the `action_confirm` method of
a Sales Order.
This commit tries to go further:
1/ change this API: the private method is the implementation that
should be extended when the confirmation should generated other
documents. The state change is extract to be sure that in all
override of `_action_confirm` the SO state will be 'sale' (and
not 'done', in case of activating the options).
2/ adapt other module to this new API. Some of them does not required
the change to correctly work, but it can introduce future bugs.
Doing it now is better ;-)
3/ With this new implementation, we can prioritize SO line treatment
on confirmation. We want the stockable lines to be processed before the
service ones. Indeed, the line (service and stockable) that should
create a purchase order (future dev for services) will search for an
existing PO, but stock has more precise criteria than services. So,
service SO line will find the existing PO from stock while the opposite
is not true.
So, this is why we are now calling `_action_launch_procurement_rule`
before the `super`.
The rest of the treatments (event, delivery, ...) depends on the module
loading order.
Task #39340.
Diffstat (limited to 'addons/website/static/src/xml/website.editor.xml')
0 files changed, 0 insertions, 0 deletions
