[12.0][MIG] hr_family

[umiphos]

This is a migration for hr_family.

This migration was done as it was in 11.0, no big changes, just the manifest

[luisg123v]

Remember to extract commits from the module in v11, so historic is not lost and your changes are visible

For more info, see: https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-12.0#user-content-technical-method-to-migrate-a-module-from-110-to-120-branch

[umiphos]

Trying to install it as a dummy, this error comes by

bad query: b" INSERT INTO ir_translation(name, lang, res_id, src, type, value, module, state, comments)\n                           SELECT name, lang, res_id, src, type, value, module, state, comments\n                           FROM tmp_ir_translation_import\n                           WHERE type = 'model'\n                           ON CONFLICT (type, lang, name, res_id) WHERE type = 'model'\n                            DO UPDATE SET (name, lang, res_id, src, type, value, module, state, comments) = (EXCLUDED.name, EXCLUDED.lang, EXCLUDED.res_id, EXCLUDED.src, EXCLUDED.type, EXCLUDED.value, EXCLUDED.module, EXCLUDED.state, EXCLUDED.comments);\n                       "
ERROR: ON CONFLICT DO UPDATE command cannot affect row a second time
HINT:  Ensure that no rows proposed for insertion within the same command have duplicate constrained values.

But I found that this error has been reported previously odoo/odoo#27992

[oca-clabot]

Hey @umiphos, thank you for your Pull Request.

It looks like some users haven't signed our Contributor License Agreement, yet.
You can read and sign our full Contributor License Agreement here: http://odoo-community.org/page/cla
Here is a list of the users:

• @umiphos (login unknown in OCA database)

Appreciation of efforts,
OCA CLAbot

[tarteo]

Code looks good.

[tarteo]

Can you elaborate on the use cases of this module? I don't see a reason why somebody should use this module.

[alexey-pelykh]

I may jump in here: some employees get presents for their children's birthdays. Yet I'm not sure if this module should be as-is, since there may be different types of relations and probably it would be better to refactor this module to have family_member model with relation_type, and rest of fields.

@pedrobaeza what would be a procedure if there's a different way for getting similar features?

[pedrobaeza]

Well, the idea is to get the best solution for a problem. Sometimes the answer is not trivial, and depends on use cases, implementation budget, etc.

For this case, indeed it's a very specific case that was implemented quickly, but it's very uncommon. If you ask me, I would go for a generalization using the same scheme as partner_multi_relation, defining relations and linking to partners, but this time having one of the sides of the relation being the employee, and then you can make use of all the possible interesting information in the partner.

[alexey-pelykh]

Maybe to proceed in-between, since employee family being in contacts/partners seems overhead? Usually it's name + phone + DOB + gender w/o extra information?

[umiphos]

the effort to make a more generic hr_family is in here #489 thanks @alexey-pelykh, we can continue this conversation over there

[alexey-pelykh]

I'd keep migration separate from refactor, plus approaches differ a bit

[umiphos]

I agree with you, this should keep as a migration, and #489 should be an improvement, I deleted everything from this change that is not part of the migration

[oca-clabot]

Hey @umiphos,
We acknowledge that the following users have signed our Contributor License Agreement:

• @umiphos

Appreciation of efforts,
OCA CLAbot

[alexey-pelykh]

FYI: #489

[umiphos]

@pedrobaeza in the recent add to #489 this PR should be closed, right?

[alexey-pelykh]

IMHO, it would be great to just port hr_family to 12 w/o that particular enhancement, it order for end-users to select what they are used to

[umiphos]

@alexey-pelykh thanks for the answer, let's wait to see opinions, also, I make a similar change than #489, but I will remove that change if this module should stay as a migration.

[alexey-pelykh]

For sure! And sorry for jumping in :)

[BT-mgomez]

@gurneyalex @alexey-pelykh

Can this be merged to 12.0 ? it was approved long ago.

[BT-mgomez]

/ocabot merge

[OCA-git-bot]

Sorry @BT-mgomez you do not have push permission, so I can't merge for you.

[alexey-pelykh]

@BT-mgomez not enough approves. My opinions stands: though this PR is a good migration, maybe we still should consider writing migration script to hr_employee_relative

[jarroyomorales]

I also think it is better just to write a migration script to 12.0 and stop this module in 11.0 since it doesnt provide any extra information comparing it to the relatives module.

I think it would be better to have a migration script indeed

[umiphos]

I agree you all to keep this in 11.0 and not migrate it, also, there was another module that has more information and a better structure, @alexey-pelykh

• can I close this PR?
• to whom we have to report this?
• what's a migration script?

thanks in advance

[alexey-pelykh]

@umiphos I think it's safe to keep this PR but rewrite the migration to a module that does the migration and installs the other module as dependency. right, @pedrobaeza ?

for migrations, see https://github.com/OCA/maintainer-tools/tree/master/template/module/migrations/8.0.1.0.0

[jarroyomorales]

Should we close this then?

[alexey-pelykh]

Guess so! @umiphos as far as I've understood, you're ok with closing this PR, but if I've understood your poorly, please let me know