[MIG] 13.0 l10n_fi_business_code

jarmokortetjarvi commented 3 years ago

Migrate to 13.0

Changes to 12.0

Change the licence from AGPL3 to LGPL3
Drop the partner_identification dependency and use a simple Char field instead
Change field name from business_id to business_code
Add a duplicate business code check (identical to duplicate vat check)
Set business code as a commercial field

mlaitinen commented 3 years ago

Since the dependency to partner_identification was dropped, should the migration script include migrating the business ID records from the table res_partner_id_number to res_partner? Something along the lines of:

UPDATE res_partner AS p
SET business_code = i.name
FROM 
  (SELECT num.partner_id, num.name 
   FROM res_partner_id_number AS num 
   INNER JOIN res_partner_id_category AS cat ON cat.id = num.category_id AND cat.code = 'business_id') AS i
WHERE p.id = i.partner_id;

This of course won't take into account the fact that business_code is now a commercial field.

jarmokortetjarvi commented 3 years ago

Since the dependency to partner_identification was dropped, should the migration script include migrating the business ID records from the table res_partner_id_number to res_partner? Something along the lines of:
UPDATE res_partner AS p
SET business_code = i.name
FROM 
  (SELECT num.partner_id, num.name 
   FROM res_partner_id_number AS num 
   INNER JOIN res_partner_id_category AS cat ON cat.id = num.category_id AND cat.code = 'business_id') AS i
WHERE p.id = i.partner_id;
This of course won't take into account the fact that business_code is now a commercial field.

Yes. I remembered the partner identification fields being stored and skipped the migration.

Your code seemed to work on a simulated migration situation. Thanks! Migration has been added https://github.com/OCA/l10n-finland/pull/35/files#diff-0e6d688ba5614ad317a76ae9dcb55471277647f5258b8f1d1ce5159f094e8625R5

I have no idea what to do with the commercial field-issue though. There shouldn't be cases where a child has a different business id, but a misconfigured address type is not impossible.

mlaitinen commented 3 years ago

Since the dependency to partner_identification was dropped, should the migration script include migrating the business ID records from the table res_partner_id_number to res_partner? Something along the lines of:
UPDATE res_partner AS p
SET business_code = i.name
FROM 
  (SELECT num.partner_id, num.name 
   FROM res_partner_id_number AS num 
   INNER JOIN res_partner_id_category AS cat ON cat.id = num.category_id AND cat.code = 'business_id') AS i
WHERE p.id = i.partner_id;
This of course won't take into account the fact that business_code is now a commercial field.
Yes. I remembered the partner identification fields being stored and skipped the migration.

Your code seemed to work on a simulated migration situation. Thanks! Migration has been added https://github.com/OCA/l10n-finland/pull/35/files#diff-0e6d688ba5614ad317a76ae9dcb55471277647f5258b8f1d1ce5159f094e8625R5

I have no idea what to do with the commercial field-issue though. There shouldn't be cases where a child has a different business id, but a misconfigured address type is not impossible.

Maybe a call to res.partner._commercial_sync_from_company() or res.partner._commercial_sync_to_children()? We could get the partner id's by adding a RETURNING id to the UPDATE query and then (probably) calling env['res.partner'].browse(ids)._commercial_sync_to_children(). This assumes that all the business ID's are set to the parents though.

jarmokortetjarvi commented 3 years ago

Since the dependency to partner_identification was dropped, should the migration script include migrating the business ID records from the table res_partner_id_number to res_partner? Something along the lines of:
UPDATE res_partner AS p
SET business_code = i.name
FROM 
  (SELECT num.partner_id, num.name 
   FROM res_partner_id_number AS num 
   INNER JOIN res_partner_id_category AS cat ON cat.id = num.category_id AND cat.code = 'business_id') AS i
WHERE p.id = i.partner_id;
This of course won't take into account the fact that business_code is now a commercial field.
Yes. I remembered the partner identification fields being stored and skipped the migration. Your code seemed to work on a simulated migration situation. Thanks! Migration has been added https://github.com/OCA/l10n-finland/pull/35/files#diff-0e6d688ba5614ad317a76ae9dcb55471277647f5258b8f1d1ce5159f094e8625R5 I have no idea what to do with the commercial field-issue though. There shouldn't be cases where a child has a different business id, but a misconfigured address type is not impossible.
Maybe a call to res.partner._commercial_sync_from_company() or res.partner._commercial_sync_to_children()? We could get the partner id's by adding a RETURNING id to the UPDATE query and then (probably) calling env['res.partner'].browse(ids)._commercial_sync_to_children(). This assumes that all the business ID's are set to the parents though.

Your idea seems to work. I returned the ids from UPDATE query and ran _commercial_sync_to_children() for each. The result was:

Children that are not companies will inherit the business id from commercial partner
Children that are companies will retain their own business id

Seems good to me. Thanks again!

OCA / l10n-finland

[MIG] 13.0 l10n_fi_business_code #35