Skip to content

[18.0][IMP] mail_tracking: Reactive tracking status in the chatter - #263

Open
CarlosRoca13 wants to merge 1 commit into
OCA:18.0from
Tecnativa:18.0-IMP-mail_tracking-reactivity
Open

[18.0][IMP] mail_tracking: Reactive tracking status in the chatter#263
CarlosRoca13 wants to merge 1 commit into
OCA:18.0from
Tecnativa:18.0-IMP-mail_tracking-reactivity

Conversation

@CarlosRoca13

Copy link
Copy Markdown
Contributor

The tracking status shown in the chatter only refreshed on a page reload.

A mail.tracking.email state change happens outside of any user session and doesn't touch mail.notification, so core's _notify_message_notification_update() is never triggered for it and nothing is pushed to the bus. Notify the involved users on every state write instead. The store has to be built once per recipient because is_failed_message is computed for the reader, and the refresh is aggregated in cr.precommit so that a message with several recipients emits a single notification instead of one per email sent.

Furthermore, MessageTracking captured props.partner_trackings in setup(), which isn't re-run when the props change. As tracking_status() returns a brand new list on every call, the component kept rendering the trackings the message had when it was created. Read them from the props on each render.

cc @Tecnativa

ping @christian-ramos-tecnativa @pedrobaeza

The tracking status shown in the chatter only refreshed on a page reload.

A mail.tracking.email state change happens outside of any user session and doesn't touch mail.notification, so core's _notify_message_notification_update() is never triggered for it and nothing is pushed to the bus. Notify the involved users on every state write instead. The store has to be built once per recipient because is_failed_message is computed for the reader, and the refresh is aggregated in cr.precommit so that a message with several recipients emits a single notification instead of one per email sent.

Furthermore,  MessageTracking captured props.partner_trackings in setup(), which isn't re-run when the props change. As tracking_status() returns a brand new list on every call, the component kept rendering the trackings the message had when it was created. Read them from the props on each render.
@pedrobaeza pedrobaeza added this to the 18.0 milestone Sep 5, 2026

@pedrobaeza pedrobaeza left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code review

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants