Odoo Changelog — 2025-04-09

Wednesday, April 9, 2025

3 changes

Branch: master

2 changes

Refactoring(2)

Code cleanup and technical improvements

[REF] mail, various: stop autosubscribe of customers

PR #81895

Enterprisemasteraccount_sepa_direct_debitappointmenthr_appraisalpos_restaurant_appointmentMEDIUM

Customer recipients are no longer automatically added as followers when sending appointment, HR, and direct debit communications. This keeps followers focused on internal users while making customer recipients clearer and more intentional in messages and templates.

Original PR description

Since [1] customers are given as default or suggested recipients for
communications. Both chatter and templates proposes them by default. Followers
should now be mostly be internal users that want to receive news from a record
while customers should be actively displayed and chosen.

In this PR calendar mainly is updated. We know correctly use attendees when
mailing events instead or relying always on followers and forced subscription.
See also [2] and [3] that already worked on that specific issue.

Task-4655022

[1] odoo/odoo#185240
[2] odoo/odoo#201514
[3] odoo/odoo#204326

#communications#followers#appointments#recipients

[REF] test_mail_enterprise: make `add_members` private

PR #83061

Enterprisemastertest_mail_enterprise

This change tidies an internal mail testing helper by making it private. It does not change product behavior for users, but helps keep the test code clearer and easier to maintain.

Original PR description

part of task-4712367.

community: https://github.com/odoo/odoo/pull/205186

#maintenance#tests#mail

Branch: 18.0

1 change

Refactoring(1)

Code cleanup and technical improvements

[REF] web_tour: macro.js

PR #194508

Core18.0test_websitewebweb_tourwebsite

This refactor changes how Odoo’s automated web tours detect page elements, making the process simpler and less dependent on timing assumptions. It should reduce inconsistent tour failures and make related issues easier to understand and resolve, with no intended direct change for end users.

Original PR description

In this commit, we're refactoring macro.js by completely changing
its operation.
To detect triggers in the DOM, we no longer rely on DOM mutations, but
instead check for each frame to see if the trigger is in the DOM.
Once the trigger is found, we perform the action and move on to the
next step.
This significantly simplifies understanding of how macro.js works,
tours, and, more importantly, the bugs that can occur in tours.
This also avoids many indeterministic errors that could occur in the
tours due to the completely arbitrary "checkDelay" parameter (the time
period after which there are no more mutations before the element is
checked to see if it is in the DOM).
This checkDelay parameter is therefore no longer used.
It will be completely removed from the codebase in a future PR.

#web tours#reliability#testing

Since [1] customers are given as default or suggested recipients for communications. Both chatter and templates proposes them by default. Followers should now be mostly be internal users that want to receive news from a record while customers should be actively displayed and chosen. In this PR calendar mainly is updated. We know correctly use attendees when mailing events instead or relying always on followers and forced subscription. See also [2] and [3] that already worked on that specific issue. Task-4655022 [1] odoo/odoo#185240 [2] odoo/odoo#201514 [3] odoo/odoo#204326

In this commit, we're refactoring macro.js by completely changing its operation. To detect triggers in the DOM, we no longer rely on DOM mutations, but instead check for each frame to see if the trigger is in the DOM. Once the trigger is found, we perform the action and move on to the next step. This significantly simplifies understanding of how macro.js works, tours, and, more importantly, the bugs that can occur in tours. This also avoids many indeterministic errors that could occur in the tours due to the completely arbitrary "checkDelay" parameter (the time period after which there are no more mutations before the element is checked to see if it is in the DOM). This checkDelay parameter is therefore no longer used. It will be completely removed from the codebase in a future PR.