Usecase to reproduce:
- Create a Product A with a supplier.
- Put 10 in stock
- Create a RR with min 5 and max 10
- Create a SO for 7 products and confirm it
The RFQ is not created.
It happens because the trigger scheduler is set on picking
action_confirm. Not on move _action_confirm to avoid performance issue.
However a SO will launch procurement rules that will create moves
and confirm them. But it will never call action_confirm on the picking
itself and thus never trigger the scheduler.
closesodoo/odoo#57540
X-original-commit: 08af6a3f663abb49d2e77c706e85118a7199ef89
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Purpose
=======
The current kanban view is messy. It is difficult to identify which
apps are installed or not. The user can completely miss a module
that might have interested him. A search panel would make things way
more readable.
closesodoo/odoo#44401
Taskid: 2181557
Related: odoo/enterprise#8144
Related: odoo/upgrade#879
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Without demo data, for the odoo-master transifex project
closesodoo/odoo#41935
X-original-commit: dab7670b73506fb3a835695ee3bd735e0c5e5c2b
Related: odoo/enterprise#7287
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Followup of a425695e
The terms were back in 12.0
Courtesy of Juan José Scarafía
closesodoo/odoo#41624
X-original-commit: 85d0c7001a997748d7691205bbb8d066597591a5
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
Only search once for batch of moves that should be assign
to the same picking and assign them all at once.
Since the moves are processed in batch for a picking
commit 8fe8ca9 is not needed anymore.
closesodoo/odoo#30699
When a quantity is increased in SO, the related picking is unreserved
then re-assigned, we can just call assign, as we don't want to lose what
has already been done in the picking.
As the decreased quantity on SO is not propagated on move, not
unreserving won't cause trouble.
Previously mrp, stock and purchase used _run methon on procurement
group and start with a if checking for the action type. This commit
instead launch a specific method depending the rule's action's type
Also _run method and their submethod used in procurement group
was always called with a rule. Thus we choose to move this method
on the rule object himself.