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

[pedrobaeza]

@Tecnativa

[pedrobaeza]

/ocabot migration payment_redsys

Depends on :

• payment : [19.0][MIG] payment #5526

[BhaveshHeliconia]

Suggested change

	"z": " payment.payment_method_bizum",
	"z": "payment.payment_method_bizum",

[BhaveshHeliconia]

Suggested change

	provider = env["payment.provider"].browse(provider_id)
	provider.payment_method_ids = [
	Command.set(env.ref(PAY_METHOD_MAPPING[redsys_pay_method]).ids)
	]
	xml_id = PAY_METHOD_MAPPING.get(redsys_pay_method)
	if not xml_id:
	continue
	method = env.ref(xml_id, raise_if_not_found=False)
	if method:
	env.cr.execute(
	"""
	INSERT INTO payment_method_payment_provider_rel
	(payment_provider_id, payment_method_id)
	VALUES (%s, %s)
	ON CONFLICT DO NOTHING
	""",
	(provider_id, method.id),
	)

I tested the migration against an existing v18 database and found a couple of issues:

1. Stray whitespace in PAY_METHOD_MAPPING
   There is a leading tab character (\t) before payment.payment_method_bizum in the mapping ("z": "\tpayment.payment_method_bizum"). As a result, env.ref() cannot resolve the Bizum payment method.

2. ORM constraint triggered during migration
   Updating provider.payment_method_ids through the ORM triggers _check_required_if_provider(). If the database contains legacy or test Redsys providers without redsys_merchant_code or redsys_secret_key configured, the write() call raises a ValidationError and the migration fails.

Using direct SQL to populate payment_method_payment_provider_rel avoids triggering ORM constraints while safely creating the required many2many records during the migration.

[BhaveshHeliconia]

Suggested change

	env,
	(
	"payment.provider",
	"payment_provider",
	"redsys_terminal",
	"redsys_merchant_terminal",
	),
	)
	env,
	[
	(
	"payment.provider",
	"payment_provider",
	"redsys_terminal",
	"redsys_merchant_terminal",
	),
	],
	)

[pedrobaeza]

Thanks, @BhaveshHeliconia

I have made direct commit to fix the typos (I expected the CI to detect at least the syntax one, but it's not executed as the DB doesn't contain the OCA module). About the constraint, I expect to fail if the mapping doesn't return any value, as that cases are not covered. They shouldn't be selected anyway in real cases.

[BhaveshHeliconia]

In a real production database, the merchant credentials should already be configured, so the ORM constraint shouldn't be an issue.

[pedrobaeza]

Yes, because the OCA module already makes them mandatory.