[adekock11]

Summary

Migration scripts and annotated analysis for the 19.0 → 20.0 discuss/mail cluster: mail, the new mail_tracking module (and its auto-install glue), bus, im_livechat, plus the small livechat satellites website_livechat and hr_livechat.

mail.tracking.value keeps the same model name and the same table (mail_tracking_value). Nothing auto-installs mail_tracking. Without a script, chatter field-change history stays in an unowned table and the UI stops reading it. The mail pre-migration marks mail_tracking to install during the same registry load (the module graph loop picks up to install before ir.model.data._process_end), and renames the moved xmlids onto mail_tracking so those records are updated instead of deleted.

No commit from OCA#6068 is in this branch. The upgrade_analysis.txt files and docsource/modules190-200.rst were copied from hbrunn/20.0-base (that PR) and then annotated. The base module migration itself is not included; a real upgrade still needs OCA#6068 (see Testing).

Overlap with #2

#2 (cursor/crm-190-200-91bd) already adds openupgrade_scripts/scripts/im_livechat/20.0.1.0/pre-migration.py whose only job is _preserve_chatbot_script_source: if crm_livechat is installed or queued, copy chatbot.script.source_id into ou_crm_livechat_chatbot_source before im_livechat drops the column. Its crm_livechat post-migration reads that table into crm.lead.utm_reference and drops it. That PR says the rest of im_livechat belongs in a dedicated PR and that the function should be merged into it.

This PR is that dedicated PR. im_livechat/20.0.1.0/pre-migration.py calls _preserve_chatbot_script_source with the same SQL and the same guards as #2, then does the rating, waiting status, and looking-for-help timestamp work. upgrade_analysis.txt is byte-identical to #2 (same blob as OCA#6068). upgrade_analysis_work.txt replaces #2's DEFERRED notes with the real handling, and marks source_id DONE by that shared function.

When the two PRs merge, keep this im_livechat pre-migration.py and upgrade_analysis_work.txt (they contain #2's function plus the rest). On docsource/modules190-200.rst, take this PR's im_livechat line (Done). Leave crm_livechat to #2: this branch does not touch that module. #2 owns create_lead_and_forward → create_lead, the utm.utm_source_livechat merge, and crm.lead.utm_reference. Those files are intentionally absent here so the two PRs do not both add scripts/crm_livechat/.

What changed between 19 and 20, and what the scripts do

File references are odoo/odoo 20.0 vs 19.0. OCA#6068's analysis is the field-by-field list; the notes below are the rows that lose or misread data.

mail_tracking (new, not auto_install)

addons/mail_tracking/__manifest__.py depends on mail only. addons/mail_tracking/models/mail_tracking_value.py is the same model mail.tracking.value. addons/mail_tracking_mass_mailing and addons/mail_tracking_sms are auto_install on top of mass_mailing / sms.

Without a script the table survives as an orphan (Odoo 20 does not drop models that are simply absent from the registry; it logs them), but new tracking is not written and old rows are not shown. update_list() runs before any module pre-migration, so the auto_install glue is missed unless something marks it to install after mail_tracking is scheduled.

pre-migration (mail/20.0.1.19/pre-migration.py):

• Sets mail_tracking to to install when it is uninstalled. Logs an error if the module row is missing (addons path does not contain it).
• If mass_mailing or sms is installed, to upgrade, or to install, schedules mail_tracking_mass_mailing / mail_tracking_sms the same way. Their only schema change is a new empty column (source_mailing_id, source_sms_template_id). Nothing to copy.
• Renames xmlids onto mail_tracking: the tracking action, menu, form, list, and model_mail_tracking_value. The access xmlid is left to base: [20.0][MIG] base OCA/OpenUpgrade#6068 renames every ir.model.access / ir.rule xmlid before mail runs, and mail_tracking's CSV creates the ir.access row.
• Copies mail_tracking_value.currency_id into field_info.currency_id before the column goes away. 20.0 stores the currency there (addons/mail/models/mail_track_mixin.py, monetary branch) and drops the many2one. Verified: the column is gone after upgrade and field_info is {"currency_id": 1}.
• Retags mail.message rows of type notification that have tracking values to message_type = 'tracking'. 20.0's "changes" filter (mail/models/mail_message.py, _message_fetch) only matches that type. Comments that also carry tracking values stay comments.

Bookmarks (renamed stars)

mail.message.starred_partner_ids (mail_message_res_partner_starred_rel) became bookmarked_partner_ids (mail_message_res_partner_bookmarked_rel) in addons/mail/models/mail_message.py. Same column names. Pre-migration renames the relation table before the new field's update_db would create an empty one. Verified: 1 row survived in the new table.

Activity chaining

addons/mail/models/mail_activity_type.py: chaining_type, suggested_next_type_ids (m2m mail_activity_rel) and triggered_next_type_id are replaced by a single suggested_next_type_id. previous_type_ids still uses mail_activity_rel, so every old suggestion remains visible as a preceding activity.

Pre-migration creates suggested_next_type_id and fills it from triggered_next_type_id when chaining_type = 'trigger', otherwise from the lowest mail_activity_rel.recommended_id. Automatic triggering is gone; the link is kept as a suggestion. Extra suggestions are not copied into the single many2one. Verified: Email (suggest → Call and Meeting) kept Call; Call (trigger → To-Do) kept To-Do; both m2m rows remain.

mail.activity.previous_activity_type_id and recommended_activity_type_id are wizard hints, not the audit trail. Nothing to do. mail.activity.plan.template.next_activity_ids is a denormalized copy of the type's suggestions. Nothing to do.

Server actions: notes vs email

addons/mail/models/ir_actions_server.py removes mail_post_method (email / comment / note) and adds state log_note with log_note_note. A 19.0 note action rendered template_id. 20.0 posts the HTML field and does not render a template.

Pre-migration, for state = mail_post and mail_post_method = note: set state = log_note and copy mail_template.body_html (jsonb, translations included) into log_note_note. comment stays mail_post. email also stays mail_post: on a mail.thread model, 20.0 always posts the template as a comment. There is no email-only path left. Verified: the seeded note action is log_note and the template body is in log_note_note.

Views that still name removed fields

Loading mail/views/ir_cron_views.xml validates the cron form before ir_actions_server_views.xml replaces the 19.0 inherit. The stored arch still contains mail_post_method (and activity views still contain chaining_type, triggered_next_type_id, and so on). The upgrade aborted on that until pre-migration emptied those view archs. Standard mail views are not noupdate, so the module XML reloads them. Verified after upgrade: the server-action form is 5888 characters and no longer mentions mail_post_method.

A custom view that still names one of those removed fields is reduced to an empty arch as well. That customization is not reconstructed. The fields are: mail_post_method, chaining_type, triggered_next_type_id, suggested_next_type_ids, previous_activity_type_id, recommended_activity_type_id, has_recommended_activities, custom_channel_name, fetched_message_id, starred_partner_ids.

Channel owners

discuss.channel.member.channel_role is new (owner / admin) in addons/mail/models/discuss/discuss_channel_member.py. Archiving a channel or a group, and editing a read-only channel, requires an owner (or a system administrator). Post-migration sets owner on the creating user's membership when they are still a member, otherwise on the oldest active internal member. Chats are left without a role (the model forbids a role there). The standard #general admin membership (mail.channel_member_general_channel_for_admin) is set to owner, matching discuss_channel_data.xml. Verified: both seeded channels have the admin partner as owner.

member_indices is a new stored compute for chats, with a partial unique index. The ORM fills it. Two chats with the same members will fail that index. This script does not merge chats, because merging would drop messages.

Noupdate data that is applied, and noupdate data that is not

The generated noupdate_changes.xml from OCA#6068 is not loaded. It would write empty name and description on #general and the admin channel (20.0 fills those in Python for translation reasons).

Post-migration instead:

• Rewrites standard activity icons from Font Awesome to Material Symbols only when the icon is still the 19.0 default (fa-envelope → mail, and the same for call, meeting, todo, upload, warning). Verified: Email's icon is mail.
• Renames mt_comment / mt_note English source terms (Discussions → Messages, Note → Notes) and swaps sequences (note 100 → 90, activities 90 → 100) only when the old value is still there.
• Adds base.group_user to mail.group_mail_canned_response_admin implied groups if it is missing (mail/data/mail_groups.xml).

bus and im_status

Checked, not assumed. bus 20.0 has no model or column change. The deleted ir.model.access row is the ir.model.access → ir.access merge done in base (OCA#6068); bus no longer ships a security CSV.

im_status is not a bus column. On res.users and mail.guest it is a non-stored compute in both versions (addons/mail/models/res_users.py, addons/mail/models/discuss/mail_guest.py). The type change Char → Selection does not touch a column. The values were already online / away / busy / offline, coming from mail.presence.status (still that selection, unchanged in addons/mail/models/mail_presence.py) and manual_im_status (unchanged). The old partner value bot was also a non-stored compute; res.partner no longer has im_status. Nothing to do.

im_livechat

addons/im_livechat/models/discuss_channel.py drops rating.mixin. rating_last_value (float 1/3/5) becomes selection livechat_rating. Pre-migration adds the column and copies rounded 1, 3 and 5 before the float column is removed. rating.rating rows are left in place. im_livechat.channel.member.history.rating was a non-stored related; 20.0 recomputes the stored selection from livechat_rating. rating_percentage_satisfaction was a non-stored integer compute and is now a non-stored float. Nothing to cast.

Status key waiting ("Waiting for customer") is removed. Open sessions become in_progress. A session with livechat_end_dt set must have a null status (the existing check). need_help now requires livechat_looking_for_help_since_dt. 19.0 did not store that instant, so pre-migration fills "now" for sessions already in need_help. The stored compute may overwrite it during init. Verified: waiting → in_progress with rating 5; need_help kept with rating 3 and a timestamp; a closed session stayed without a status and got rating 1.

livechat_operator_id is dropped. 19.0 already stores the agent on im_livechat.channel.member.history, which 20.0 uses. Nothing to copy.

Conversation tags (im_livechat.conversation.tag and the m2m) are removed with no replacement. Tag names are dropped. Nothing to do, and the loss is real.

chatbot.script no longer inherits utm.source.mixin (addons/im_livechat/models/chatbot_script.py). Per-bot source_id is preserved only by the #2 function described above, and only when crm_livechat is installed. The utm.source rows themselves are not deleted. New chatbot leads use im_livechat.utm_source_chatbot.

The redesigned transcript email and the noupdate channel rename YourWebsite.com → Support are not forced onto existing databases.

ir.model.access / ir.rule / ir.access rows everywhere in this analysis are the base merge from OCA#6068. This PR does not touch them. Standard rows are reloaded from module data. Rows without an xmlid are preserved by base.

website_livechat and hr_livechat

website.visitor.livechat_operator_id was a stored compute of the channel operator. The operator still lives on the channel members and the history model, so the cache column can go. The noupdate website record now points at base.default_website, which base renames from website.default_website; channel_id itself is unchanged, so the generated noupdate file is not loaded.

hr_livechat only deletes a search view for the removed looking-for-help action.

Deliberately not in this PR

• crm_livechat (steps, UTM source, utm_reference): [OU-ADD] crm: migrate CRM and close modules from 19.0 to 20.0 #2.
• mail_group, mass_mailing (beyond scheduling its tracking glue), snailmail, mail_plugin (res.partner.iap is removed there), resource_mail, auth_totp_mail. Each has its own analysis and should be its own PR.
• mail_bot and mail_bot_hr: no database layout change. Coverage lines are Nothing to do.
• mail.thread.cc is an abstract model with no table. crm.lead, project.task and project.update inherit it in 19.0 and do not redeclare email_cc in 20.0, so those columns drop when those modules upgrade. That belongs in the crm and project scripts, not here.
• discuss.channel.member.custom_channel_name and fetched_message_id: feature removed, no successor. fetched_message_id is a read cursor; seen_message_id remains. pinned_message_ids is a non-stored one2many; pins stay on mail.message.pinned_at.
• Push-to-talk and the Discuss sidebar-open flags on res.users.settings: feature removed.
• res.users mail.thread / activity fields that changed from related to stored computes: the ORM adds the columns and recomputes them. contact_address_inline moved to base with the same column; base loads first.

How it was tested

Local only. No external server.

1. PostgreSQL 16. Odoo 19.0 (odoo/odoo branch 19.0) installed bus, mail, im_livechat into database ou_mail (--stop-after-init). That pulled 41 modules. ir_module_module.demo stayed false, so this was not a demo-data database; the cases below were inserted with SQL instead.
2. Seeded: one tracking row with currency_id = 1; one starred message; activity type Email suggesting Call and Meeting, Call triggering To-Do; a server action mail_post / note with a mail template; three livechat channels (waiting + rating 5, need_help + rating 3, closed + rating 1).
3. Odoo 20.0 upgrade with --upgrade-path pointing at this branch's openupgrade_scripts/scripts and, for base only, the scripts from hbrunn/20.0-base ([20.0][MIG] base OCA/OpenUpgrade#6068). Those base files are not in this commit.

Two local patches were required for the upgrade process and are not in this PR:

• Odoo 20 odoo/modules/migration.py calls inspect.signature on migrate. That follows __wrapped__, so @openupgrade.migrate() (def migrate(env, version) inside a (cr, version) wrapper) is rejected. The test used follow_wrapped=False. Every script in this PR uses the decorator the same way [20.0][MIG] base OCA/OpenUpgrade#6068 does, so this blocks the whole 20.0 series until openupgradelib or the framework adjusts it.
• openupgradelib load_data calls odoo.tools.convert_xml_import. Odoo 20 no longer exports that name from odoo.tools (it lives in odoo.tools.convert). [20.0][MIG] base OCA/OpenUpgrade#6068's base post-migration dies there (AttributeError) before mail runs. The test re-exported convert_xml_import. After that, base from [20.0][MIG] base OCA/OpenUpgrade#6068 finished (base 19.0.1.3 → 20.0.1.3) and these scripts ran.

First mail attempt then failed in mail/views/ir_cron_views.xml (Field "mail_post_method" does not exist). The view neutralization above fixes that. The successful run was -u mail,im_livechat on the database whose base and bus were already at 20.0. Exit code 0, Modules loaded.

Checked after that run: mail_tracking installed and the tracking xmlids live there; tracking row kept with field_info.currency_id; message type tracking; bookmark relation renamed with the row intact; activity suggestions as described; note action converted; livechat ratings and statuses as described; channel owners set; activity icon and subtype labels updated. mail_tracking_sms installed because sms was already installed; mail_tracking_mass_mailing stayed uninstalled because mass_mailing was not. crm_livechat was not installed, so _preserve_chatbot_script_source correctly no-op'd and create_lead_and_forward was left for #2 (the seeded step still has that value).

Known gaps and risks

• Depends on [20.0][MIG] base OCA/OpenUpgrade#6068 for ir.model.access + ir.rule → ir.access, and for the upgrade to get past base. This branch does not vendor those commits.
• The migrate signature mismatch and the missing convert_xml_import export will stop a stock 20.0 + current openupgradelib run before these scripts do anything useful. They need a framework or openupgradelib fix, not a per-module workaround.
• Custom views that mention a removed field are blanked, not rewritten.
• Only one suggested next activity is kept. The others stay on previous_type_ids.
• Email-only server actions on mail.thread models start posting a comment.
• Duplicate chats can fail the new member_indices unique index.
• Conversation tags, custom channel names, and push-to-talk settings are discarded.
• email_cc on crm leads and project tasks/updates is out of scope and will be dropped by those modules' ORM updates.
• Noupdate transcript templates and the demo livechat channel name are left as the database has them.
• Merge with [OU-ADD] crm: migrate CRM and close modules from 19.0 to 20.0 #2 as described above. Do not keep both copies of im_livechat/20.0.1.0/pre-migration.py.