[15.0][MIG] google_calendar: migration script

[MiquelRForgeFlow]

Supersedes #3407.

[pedrobaeza]

Mixed of modules

[MiquelRForgeFlow]

I know, but I was too lazy to do another PR.

[pedrobaeza]

Please do it in this case for not mixing things.

[legalsylvain]

naive question.

If I understand correctly
before your commit :

• crm_team.create_date -> crm_team_member.create_date
• crm_team.create_uid -> crm_team_member.create_uid
• crm_team.write_date -> crm_team_member.write_date
• crm_team.write_uid -> crm_team_member.write_uid

With your commit

• crm_team.write_date -> crm_team_member.create_date
• crm_team.write_uid -> crm_team_member.create_uid
• crm_team.write_date -> crm_team_member.write_date
• crm_team.write_uid -> crm_team_member.write_uid

why not conserve create information ?

[MiquelRForgeFlow]

Because that's something I realized, I think it's the best approach. How to explain... Well, it happens that the model crm.team.member with table crm_team_member it's also a m2m table for field crm_team_ids of res.users. So, who created the user or who created the team maybe not who added the user as a team member of the team. The same for date. Maybe I am wrong, but I thought that adding the write_uid instead is less wrong: who can modify a team or modify the user is more probably to also be who adds the user as a team member.

[pedrobaeza]

I think neither of the approaches will be accurate, so better to leave it as it was

[MiquelRForgeFlow]

Do you mean, to leave them without uids and dates?

[legalsylvain]

Thanks for the explanation @MiquelRForgeFlow.

I abstain on that point, I don't know what is the best approach.

to leave them without uids and dates?

i remember a case, when having empty create date / uid was a problem. In recent odoo version, the fied are filled, but as my database comes from a V5, some values was absent. So once I had to write (pseudo) update xxx set create_date = write date where create_date is null. But I don't remember exactly the context.

[pedrobaeza]

No, I mean to leave it as it was. And the end, this is merely information not tied to business logic.

[MiquelRForgeFlow]

Ok, the PR is in #3490. I will think about it a bit more. All options are bad, but I will try to find the "less" bad one. If not, I will close it.

[MiquelRForgeFlow]

/ocabot migration google_calendar

[OCA-git-bot]

The migration issue (#3287) has been updated to reference the current pull request.
however, a previous pull request was referenced : #3407.
Perhaps you should check that there is no duplicate work.
CC : @duong77476