[17.0][OU-ADD] base: migration to 17.0#4430
Conversation
daiduongnguyen-odoo
force-pushed
the
v17_ou_add_base
branch
2 times, most recently
from
17dc70f to
defcb14
Compare
|
/ocabot migration base |
pedrobaeza
changed the title
| _deleted_xml_records = [ | ||
| "base.icp_mail_bounce_alias", | ||
| "base.icp_mail_catchall_alias", | ||
| "base.icp_mail_default_from", |
There was a problem hiding this comment.
These three pieces of data seem to have been deleted during the pre-migration phase.
There was a problem hiding this comment.
Are you sure ?, normally those xml-id that have noupdate need to be manually deleted using migration script, in lower version (15, 16) i usually do that
There was a problem hiding this comment.
Are you sure ?, normally those xml-id that have noupdate need to be manually deleted using migration script, in lower version (15, 16) i usually do that
Sorry, it seems I didn’t express myself clearly before; What I meant was that the three _deleted_xml_records and their corresponding deletion methods appear repeatedly in post_migration.py and end_migration.py. I think it’s only necessary to clean them up once in either place.
There was a problem hiding this comment.
oh yeah,sorry i'll update now
daiduongnguyen-odoo
force-pushed
the
v17_ou_add_base
branch
from
defcb14 to
88b5969
Compare
daiduongnguyen-odoo
force-pushed
the
v17_ou_add_base
branch
from
88b5969 to
45355d4
Compare
daiduongnguyen-odoo
force-pushed
the
v17_ou_add_base
branch
from
45355d4 to
23ad634
Compare
|
Dah it green before :)) |
|
Hello, I'm creating a new analysis tool called odoo-module-diff, it's explained here: https://github.com/akretion/odoo-module-diff To review or complete the PR, you might be interested by these key commits of the base module migration to 17.0: |
| openupgrade.logged_query( | ||
| cr, | ||
| """ | ||
| WITH tmp AS ( | ||
| SELECT t1.id, t1.state, t2.col1, t2.value, t2.evaluation_type, | ||
| t3.name AS update_field_name, t3.ttype, | ||
| t3.relation, t4.id AS selection_field_id | ||
| FROM ir_act_server t1 | ||
| JOIN ir_server_object_lines t2 on t1.id = t2.server_id | ||
| JOIN ir_model_fields t3 on t2.col1 = t3.id | ||
| LEFT JOIN ir_model_fields_selection t4 on t3.id = t4.field_id | ||
| ) | ||
| UPDATE ir_act_server ias | ||
| SET | ||
| update_field_id = CASE | ||
| WHEN tmp.state = 'object_create' THEN NULL | ||
| WHEN tmp.state = 'object_write' THEN tmp.col1 | ||
| ELSE NULL | ||
| END, | ||
| update_path = CASE | ||
| WHEN tmp.state = 'object_create' THEN NULL | ||
| WHEN tmp.state = 'object_write' THEN tmp.update_field_name | ||
| ELSE NULL | ||
| END, | ||
| update_related_model_id = CASE | ||
| WHEN tmp.state = 'object_write' AND tmp.evaluation_type = 'value' | ||
| AND tmp.relation IS NOT NULL THEN | ||
| (SELECT id FROM ir_model WHERE model=tmp.relation LIMIT 1) | ||
| ELSE NULL | ||
| END, | ||
| update_m2m_operation = 'add', | ||
| evaluation_type = CASE | ||
| WHEN tmp.evaluation_type = 'value' then 'value' | ||
| WHEN tmp.evaluation_type = 'reference' then 'value' | ||
| WHEN tmp.evaluation_type = 'equation' then 'equation' | ||
| ELSE 'VALUE' | ||
| END, | ||
| value = tmp.value, | ||
| resource_ref = CASE | ||
| WHEN tmp.ttype in ('many2one', 'many2many') | ||
| THEN tmp.relation || ',' || tmp.value | ||
| ELSE NULL | ||
| END, | ||
| selection_value = CASE | ||
| WHEN tmp.ttype = 'selection' THEN tmp.selection_field_id | ||
| ELSE NULL | ||
| END, | ||
| update_boolean_value = CASE | ||
| WHEN tmp.ttype = 'boolean' then 'true' | ||
| ELSE NULL | ||
| END | ||
| FROM tmp | ||
| WHERE ias.id = tmp.id | ||
| """, | ||
| ) |
There was a problem hiding this comment.
This one is tricky, since ir_act_server has been modified in v17 to update only 1 field per action (for 'object_create' / 'object_write' state).
The above script does not cover the case where you ir_act_server was updating multiple fields in v16.
I have been scratching my head to find proper way-forward for these cases, but I could not find a solution I am satisfied with.
As a matter of fact with default installation (even with demo), there are only cases for state = 'code' so I guess these other types are mostly linked to base automation module ?
I suppose that for 'object_write' state, we could create multiple actions and link them together in a new ir_act_server with state 'multi'.
For 'object_create' it is more tricky, since you can only define a value (static one) now for 1 field only, so previous action would probably need to be converted to 'code' to get it working in v17. There I am not sure what should be done ? Any idea @pedrobaeza @StefanRijnhart @legalsylvain @MiquelRForgeFlow ?
There was a problem hiding this comment.
Well now look back, i don't understand why i wrote it lol @@@
There was a problem hiding this comment.
Handled in #4582 creating always "multi" action server, and converting lines to children actions.
There was a problem hiding this comment.
Thank you, i really want to contribute more but my boss keep doing nonsense :)
There was a problem hiding this comment.
No worries, it can be a collaborative work.
|
Superseded by #4582 |
6 participants
No description provided.