Thank you for the changes. Your question is correct, I was not thinking straight at the time of my first review. In the first place, there is no reference to the crossreferences to the transitions anywhere in the workflow tables, so transitions only live at runtime. Therefore no migration seems to be needed.
In fact, removing the transitions seems to save us from potentially big problems in this case. For the first time, if I am not mistaken, we encounter workflow parts being split off to a module that is not a new and logical dependency of the existing modules (such as sale_stock, which will always be installed on databases that were using sale in 6.1). So consider a situation in which project_mrp is not installed, so that we migrate the workflow states to a non-installed module. That means that the states will remain in the system after the upgrade. If there are no transitions to reach them, that does not really matter. But if we preserve the transitions, then the system will attempt to run the workflow even if it is not installed properly. So the transition's condition may check fields that are not present, or call a nonexisting method. And if the transition succeeds, the workflow ends up in an orphaned state. So it seems that I was completely wrong in suggesting that you should migrate the transitions as well, and I apologize for that. Anyway, migrating data to possibly uninstalled modules may have further consequenses that we may need to think about a little bit more. -- https://code.launchpad.net/~sylvain-legal/openupgrade-addons/7.0-procurement/+merge/184206 Your team OpenUpgrade Committers is subscribed to branch lp:openupgrade-addons. -- Mailing list: https://launchpad.net/~credativ Post to : [email protected] Unsubscribe : https://launchpad.net/~credativ More help : https://help.launchpad.net/ListHelp
