In some cases the MRP scheduler can remain blocked on an infinite loop
consuming a lot of CPU. The reason comes from the loop 'Check done
procurements'
If a new procument is created from another process (such like MTO
orders) during this loop, the process never ends.
The only way to reproduce is in debug mode:
1. Put a breakpoint on line 'Check done procurements'
2. Launch the MRP scheduler manually and stay paused on the breakpoint
3. In parrallel, create and confirm a sale order with a MTO route, this
will trigger the creation of a new procurement order in state
'Running'
4. Continue debugging step by step the scheduler and you will notice
that the loop never ends.
Closes#21565
opw-787651
Dominican team is focused on Transifex traductions using es.po,
as es_DO.po has a lot of issues in the website and reviewed strings
with wrong wording and mixing english and spanish. From now on
Dominican Republic will inherit es.po and just make specific changes
on github just in the needed words or setences that change base on
region.
Closes#18834
based on v10 terms and saas-15
add the new languages
Much noise due to the different softwares that do not indent the terms the same
way. Merged the po files with --no-wrap option which makes long lines.
opw-751014
Issue: 741582
This bug happens when you click multiple time quickly on 'run scheduler' button
or if you call 'run reordering rules' and then 'run scheduler' rapidly
It could create duplicate PO or MO.
This happens because the run_scheduler function free the lock while it should
not. ProcurementSudo was created with the old cursor that contains the lock and
the record set that search returns also contains this cursor. The run will call the record set with the bad cursor and commit the lock instead of the wanted
behavior.
This commit creates the ProcurementSudo with the new cursor that does not
contains the lock.
Christophe Simonis