I didn't really consider either 1 or 2 issues, as I completely understand why the procurement can be in the state it was (confirmed and past scheduled date) and I wasn't reporting those. As for #3 - yes, agreed, but it's separate from my issue.
#4 is definitely a bug and not a code improvement. Specifically, the fact that it will never break out of the while loop under the conditions I mentioned is an issue. The result it a pegged CPU and, if the scheduler is catching up on Open ERP startup, the server will not start properly. -- You received this bug notification because you are a member of C2C OERPScenario, which is subscribed to the OpenERP Project Group. https://bugs.launchpad.net/bugs/798890 Title: [trunk][procurement] MRP Scheduler 'looping' on confirmed procurement past scheduled date Status in OpenERP Modules (addons): Confirmed Bug description: I'm not quite certain how the procurement got to this state to begin with, but there seems to be an issue which will cause the scheduler to loop under the following conditions: 1. The Procurement Order scheduled date is in the past 2. The state is confirmed 3. The move is not cancelled (it can be done or confirmed) I realize that it shouldn't be in that state - however, the scheduler should handle it a tad more gracefully. Right now it continually loops on the record and the job runs continually. The offending while statement is in the schedulers.py procure_confirm() - you can see that it will never return from the loop under this scenario as it will always be true and will always return ids. I would suggest changing the while to a for loop and just process all the ids, unless there's something I'm missing. To manage notifications about this bug go to: https://bugs.launchpad.net/openobject-addons/+bug/798890/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~c2c-oerpscenario Post to : [email protected] Unsubscribe : https://launchpad.net/~c2c-oerpscenario More help : https://help.launchpad.net/ListHelp
