Merge lp:~sylvain-legal/openupgrade-addons/7.0-procurement into lp:openupgrade-addons

[Sylvain LE GAL (GRAP)]

[ADD] 'procurement' analysis. (no change. no script migration)

[Stefan Rijnhart (Opener) (stefan-opener)]

Thanks!

I don't think you can ignore the workflow activities, because it can leave ongoing workflows in an inconsistent state.
 For instance, act_produce_service has moved to project_mrp so you will have to rename its xml-id.

I am actually not sure if you can ignore transitions either, seeing that they can be in a state 'running' too (but that may only be inside a single transaction). We will need to be sure if we choose not to go and look for the replacement transitions, if any.

review: Needs Fixing

[Sylvain LE GAL (GRAP) (sylvain-legal)]

Thanks for your review. You was right about workflows activities. I renamed activities, except one, that is not in fact a real step I think. (Action = none).

I Renamed too the transitions.

More information about workflow changes : http://postimg.org/image/om87dt0xz/full/

However, i didn't understand your remark about the 'running' of transitions. Is it possible to be in a running state if OpenERP service is down ? because upgrade database requires stopping server. (Sorry if it's a senseless question)

[Stefan Rijnhart (Opener) (stefan-opener)]

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.

[Sylvain LE GAL (GRAP) (sylvain-legal)]

Hi.

Thanks for your review.

About the possibility to have data from uninstalled modules after the openupgrade operation, I think that we can use the same kind of function that "warn_possible_dataloss" ('openerp/openupgrade/openupgrade.py') added here https://code.launchpad.net/~therp-nl/openupgrade-server/three-functions-for-addons-migration/+merge/175790.

The function could have the following algorithm :

if the new module ('project_mrp') is installed :
  # No problem.
else :
  if there is no record in that state ('act_produce_service') :
    # No problem. Isn't it ?
  else :
    # There is a problem
    Solution A : just warn the administrator. "WARNING : You have 53 records in an orphaned state"
    Solution B : Openupgrade install 'project_mrp' module ;

I maybe prefer the A solution.

[Sylvain LE GAL (GRAP) (sylvain-legal)]

Hi reviewers !

Holger reviewed today 'mrp' work. (thanks by the way for the review). 'procurement' MP is a prerequisite of 'mrp' work.

I'd like to know your point of view about the problem due to activities & transitions migrations, and about my former comment.
I can write the function and propose a Merge Proposal in openupgrade-server if you're agree.

Regards.

[Stefan Rijnhart (Opener) (stefan-opener)]

Hi Sylvain,

I think this should still be left to the future service module and not done here.

[Stefan Rijnhart (Opener) (stefan-opener)]

Just to let you know, I am planning on merging this in a couple of days but leaving out the migration of the transitions for the reasons I explained above. Please comment if you don't agree.

[Sylvain LE GAL (GRAP) (sylvain-legal)]

Hi,

No problem for me ! I used this script as it for my migration, and it worked.
But I confess that I'm still not very comfortable with workflow & activity concepts.

+++

[Stefan Rijnhart (Opener) (stefan-opener)]

Thanks Sylvain. Merged in http://bazaar.launchpad.net/~openupgrade-committers/openupgrade-addons/7.0/revision/8151, my modifications in http://bazaar.launchpad.net/~openupgrade-committers/openupgrade-addons/7.0/revision/8152

=== added file 'procurement/migrations/7.0.1.0/openupgrade_analysis_work.txt'
--- procurement/migrations/7.0.1.0/openupgrade_analysis_work.txt	1970-01-01 00:00:00 +0000
+++ procurement/migrations/7.0.1.0/openupgrade_analysis_work.txt	2013-09-13 11:50:57 +0000
@@ -0,0 +1,41 @@
+---Fields in module 'procurement'---
+# Ignore, no existing data to push as messages
+procurement  / procurement.order        / message_ids (one2many)        : NEW relation: mail.message
+
+# Ignore, change type.
+procurement  / procurement.order        / name (char)                   : type is now 'text' ('char')
+
+### Not a new field. 'type' field was in 'product' module before with the selection keys.
+# Ref 6.1. addons/product/product.py 
+# Ref 7.0. addons/procurements/procurement.py
+procurement  / product.template         / type (False)                  : NEW selection_keys: ['consu', 'product', 'service'], mode: modify
+
+
+---XML records in module 'procurement'---
+
+# act_produce_check is not a real activity because its action is None. No possibility to have a object in this state. Nothing to do.
+DEL workflow.activity: procurement.act_produce_check
+
+# following transaction is between act_confirm_mto and act_produce_check. Deleted. Nothing to do.
+DEL workflow.transition: procurement.trans_confirm_mto_produce_check
+
+# new Transition. Nothing to do.
+NEW workflow.transition: procurement.trans_confirm_mto_make_done
+
+### moved from 'procurement' to 'project_mrp' module.
+DEL workflow.activity: procurement.act_produce_service
+DEL workflow.transition: procurement.trans_produce_service_cancel
+DEL workflow.transition: procurement.trans_produce_service_make_done
+DEL workflow.transition: procurement.trans_product_check_produce_service
+
+### moved from 'procurement' to 'purchase' module.
+DEL workflow.transition: procurement.trans_confirm_mto_purchase
+
+### Ignore interface and access records
+NEW ir.actions.act_window: procurement.product_open_orderpoint
+DEL ir.actions.act_window: procurement.act_product_product_2_stock_warehouse_orderpoint
+
+NEW ir.ui.view: procurement.product_form_view_procurement_button
+NEW ir.ui.view: procurement.product_search_form_view_procurment
+NEW ir.ui.view: procurement.product_template_form_view_procurement
+DEL ir.ui.view: procurement.product_normal_form_view

=== added file 'procurement/migrations/7.0.1.0/pre-migration.py'
--- procurement/migrations/7.0.1.0/pre-migration.py	1970-01-01 00:00:00 +0000
+++ procurement/migrations/7.0.1.0/pre-migration.py	2013-09-13 11:50:57 +0000
@@ -0,0 +1,34 @@
+# -*- coding: utf-8 -*-
+##############################################################################
+#
+#    OpenERP, Open Source Management Solution
+#    This module copyright (C) 2013 Sylvain LE GAL
+#
+#    This program is free software: you can redistribute it and/or modify
+#    it under the terms of the GNU Affero General Public License as
+#    published by the Free Software Foundation, either version 3 of the
+#    License, or (at your option) any later version.
+#
+#    This program is distributed in the hope that it will be useful,
+#    but WITHOUT ANY WARRANTY; without even the implied warranty of
+#    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+#    GNU Affero General Public License for more details.
+#
+#    You should have received a copy of the GNU Affero General Public License
+#    along with this program.  If not, see <http://www.gnu.org/licenses/>.
+#
+##############################################################################
+
+from openerp.openupgrade import openupgrade
+
+xmlid_renames = [
+    ('procurement.trans_confirm_mto_purchase', 'purchase.trans_confirm_mto_purchase'),
+    ('procurement.act_produce_service', 'project_mrp.act_produce_service'),
+    ('procurement.trans_produce_service_cancel', 'project_mrp.trans_produce_service_cancel'),
+    ('procurement.trans_produce_service_make_done', 'project_mrp.trans_produce_service_make_done'),
+    ('procurement.trans_product_check_produce_service', 'project_mrp.trans_product_check_produce_service'),
+]
+
[e-mail]()
+def migrate(cr, version):
+    openupgrade.rename_xmlids(cr, xmlid_renames)

=== added file 'procurement/migrations/7.0.1.0/user_notes.txt'
--- procurement/migrations/7.0.1.0/user_notes.txt	1970-01-01 00:00:00 +0000
+++ procurement/migrations/7.0.1.0/user_notes.txt	2013-09-13 11:50:57 +0000
@@ -0,0 +1,2 @@
+The migration script has only changes in workflows. 
+Analysis of changes available here. http://postimg.org/image/om87dt0xz/full/