[19.0][OU-ADD] crm: Migration scripts

[eduezerouali-tecnativa]

cc @Tecnativa TT58614
@pedrobaeza

[legalsylvain]

/ocabot migration crm

Depends on :

• base_setup : [19.0][MIG] mail+dependencies #5466
• sales_team : [19.0][MIG] sales_team #5528
• mail : [19.0][MIG] mail+dependencies #5466
• calendar : [19.0][MIG] calendar #5613
• resource : [19.0][MIG] resource #5504
• utm : [19.0][MIG] website dependencies #5580
• web_tour : [19.0][MIG] mail+dependencies #5466
• contacts : [19.0][OU-ADD] contacts: Nothing to do #5681
• digest : [19.0][MIG] digest #5505
• phone_validation : [19.0][MIG] hr+dependencies #5566

[pedrobaeza]

I think we should concatenate the mobile in the pone field in case both exist, or write it on the internal notes to not lose data. And put if done in pre-migration or post-migration.

[eduezerouali-tecnativa]

I had the feeling more case can appear so I tag it as case 1. If we concatenate that, can this cause trouble with phone_validation ?

[pedrobaeza]

Well, not really, as that module only format the numbers, not block them, and they are already formatted.

[pedrobaeza]

Suggested change

	#DONE: set to prevent massive compute
	# DONE: pre-migration: pre-created column and set it to prevent massive computation

[pedrobaeza]

And I see you have done it on post-migration, so this is not preventing anything.

[pedrobaeza]

Suggested change

	# Done: Transform m2o to m2m
	# DONE: post-migration: Transform m2o to m2m

[pedrobaeza]

Why the color loading in the stages is problematic? cc @hbrunn

[eduezerouali-tecnativa]

I assume that is because what happens if those records were eliminated by the user, but in this can be manged by the https://github.com/OCA/openupgradelib/blob/ac165a1dccd1fba4f09fb15c194420cdaa4672af/openupgradelib/openupgrade.py#L434
Am i wrong?

[hbrunn]

it's indeed problematic when the stages are deleted. for this hack to be active, you need to pass mode='init_no_create', and then also pass an xml transformation to remove overwriting the config parameter. also a way to go, but not really simpler than what happens now. would be future proof for subsequent changes to the file though

[pedrobaeza]

OK, the forcecreate="False" parameter is the defining one. Then please:

• Specify the real reasons, not only to mention "conflicting".
• Put the load_data instruction, but commented, to give context.

[pedrobaeza]

ping @eduezerouali-tecnativa

[eduezerouali-tecnativa]

Changes Done.

• Move won_status calculation to pre-migration
• Add case to _migrate_lead_mobile where phone and mobile are set
• Add more comments for better explanations

[pedrobaeza]

It can be done in one shot:

Suggested change

	openupgrade.logged_query(
	env.cr,
	"""
	UPDATE crm_lead
	SET phone = mobile
	WHERE (phone IS NULL OR phone = '')
	AND (mobile IS NOT NULL AND mobile != '')
	""",
	)
	# Case 2: both phone and mobile exist and differ → concatenate them
	openupgrade.logged_query(
	env.cr,
	"""
	UPDATE crm_lead
	SET phone = phone || ' / ' || mobile
	WHERE phone IS NOT NULL AND phone != ''
	AND mobile IS NOT NULL AND mobile != ''
	AND btrim(phone) != btrim(mobile)
	""",
	openupgrade.logged_query(
	env.cr,
	"""
	UPDATE crm_lead
	SET phone = CONCAT(COALESCE(phone, ''), mobile)
	WHERE COELESCE(mobile, '') != ''
	""",
	)

[pedrobaeza]

Suggested change

	[
	("crm.lead", "won_status", "selection", None, "crm_lead"),
	],
	[("crm.lead", "won_status", "selection", "pending", "crm_lead")],

[pedrobaeza]

As we are already initializing all of them to "pending", just do 2 updates for the rest (note the changes in the boolean conditions):

       UPDATE crm_lead cl
       SET won_status = 'won'
       FROM crm_stage cs
       WHERE cs.id = cl.stage_id
       AND cs.is_won
       AND cl.probability = 100

       UPDATE crm_lead cl
       SET won_status = 'lost'
       WHERE NOT cl.active
       AND cl.probability = 0