[17.0][OU-ADD] mail: migration to 17.0

[hbrunn]

#4431 with review followup

[hbrunn]

/ocabot migration mail

Depends on :

• bus : TODO
• web_tour : TODO

[hbrunn]

@remi-filament I think we should fill this with a dummy value after all, otherwise Odoo won't be able to set up the not null constraint

[hbrunn]

@remi-filament I don't think we need to remove this manually - that's necessary when we do something during migration that would violate it, and afterwards it's deleted anyways

[hbrunn]

to discuss: message_main_attachment_id has been moved to its own mixin and most models don't inherit that one. As I assume there's a plethora of private code out there doing $deity knows what with this field, should we loop through all models in end-migration and copy away the column to its legacy name for further processing?

[pedrobaeza]

In general, the work file is very hard to be followed, due to not proper logical blocks grouping, and the models renaming that are not taken into account for it.

May you consider to re-run analysis to get a cleaner one and do the groupings (or at least this second one).

[pedrobaeza]

to discuss: message_main_attachment_id has been moved to its own mixin and most models don't inherit that one. As I assume there's a plethora of private code out there doing $deity knows what with this field, should we loop through all models in end-migration and copy away the column to its legacy name for further processing?

I don't think we should rename. The goal of OU is the preservation, and this is achieved not doing anything, as the column is preserved with main_attachment_id name. In fact, I only rename when there's a risk of collapsing with other thing. If not, I prefer to keep the original column name. This way, any module restoring the feature don't need to re-rename again the column in pre_init_hook.

[hbrunn]

@pedrobaeza thanks for your points, I'll pick them up next Monday. Or some member of @OCA/openupgrade-maintainers before, I suspect I couldn't push to the original PRs because they come from a fork of a fork, while my copy is forked directly from here.

[pedrobaeza]

I have pushed a rebased branch with my comments applied. I see that the new analysis doesn't contain the model renaming for shortening the analysis file, but I have shorten it myself.

[hbrunn]

@pedrobaeza thanks for taking over, but I'm not sure I agree with shortening/reordering the work file. What I do currently to verify all analysis points are covered is diff upgrade_analysis.txt upgrade_analysis_work.txt, and if any non-comment line shows up there, something is missing. That's especially crucial now we have changed analysis files.

How do you do that? Compare manually?

[pedrobaeza]

I don't need to do anything with the _work file. What I do is to check the diff of the regular file in the new analysis PR, and incorporate what needed both in the migration scripts and in the work file.

In your PR https://github.com/OCA/OpenUpgrade/pull/4606/files, I already checked that there's nothing touched in mail analysis file.