Thank you for your explanation (and your technical changes which look good). I personally still think that it should suffice for the administrator to review the list of columns to be removed once we have the cleanup module ready. In a sense, removing each of those columns constitutes a potential data loss, but then again, if a model column is dangling after the upgrade, it is by definition not used in the (ORM) system.
I actually traced your use case to the invoicing part of OpenERP, as in 6.1 there still is a filter on purchasable products in the case of a supplier invoice even if the purchase module is not installed. That has now been dropped, see lp:1171794. So for this particular use case, when only invoicing is used, the data loss is indeed theoretic. Even if one decides to install the purchase module for the sake of managing this field, it is still not applied when using invoicing without purchase orders. We could consider putting up hints in the cleanup module if we have information available that a column has moved to a different module, but even that could lead to a false sense of security in case of columns that moved between modules in a way that is not yet detected by the analysis process. But with a sensible disclaimer, that I would find useful. So far for my two cents, what do other people think? -- https://code.launchpad.net/~sylvain-legal/openupgrade-server/three-functions-for-addons-migration/+merge/174668 Your team OpenUpgrade Committers is subscribed to branch lp:openupgrade-server. -- Mailing list: https://launchpad.net/~credativ Post to : [email protected] Unsubscribe : https://launchpad.net/~credativ More help : https://help.launchpad.net/ListHelp
