Daily updates from Odoo
Tuesday, July 14, 2026
13 changes · 19.0
Enhancements to existing features
This update strengthens marketing automation behavior around campaign synchronization, message failures, and user-triggered activities such as opens and clicks. It fixes scheduling and trace handling issues across email, SMS, and WhatsApp journeys, helping campaigns behave more consistently as they scale.
Original PR description
RATIONALE In order to prepare upcoming improvements for marketing automation application, as well as performance improvements, some tests are added to improve coverage and cover some synchronization…
RATIONALE
In order to prepare upcoming improvements for marketing automation
application, as well as performance improvements, some tests are added
to improve coverage and cover some synchronization use cases.
SPECIFICATIONS
Add some tests improve coverage of synchronization, as we recently
discovered limitations
* "opposite" triggers when checking brother traces to skip in
'action_update_participants' (which synchronizes traces): sub
addons (sms, whatsapp) is not taken into account;
* 'schedule_date' is not correct for user-based activities (e.g.
mail_open, mail_click, ...) when new activities are added to
a campaign. They should not have scheduled dates, as it depends
on user action. Date is correct for activities when participants
enter child activities but not when doing the synchronize;
* add some checks on participant state;
* globally try to improve some corner cases coverage;
Add some tests to improve coverage of bounce / fail behavior with
various activities, as we want to make it clearer how MA should
behave when dealing with issue. First step is to assert current
behavior and fix some odd bits.
Notably in some cases trace update is missing, notably with SMS
sending with does not call trace update method, which means some
triggers are not processed.
Various fixes are included in this branch, spotted by newly added tests.
See commits for more details.
Task-4224152: [marketing_automation] Performance / ScalabilityThe AI module now moves away from an embedding model that will soon be retired. It also refreshes existing AI data created with deprecated models, helping keep AI-powered features reliable without manual intervention.
Original PR description
The model gemini-embedding-001 will be deprecated soon, so this commit is: - Deprecating that model. - Introducing an autovacuum to recompute embeddings that were done using embedding models that have been deprecated. task-6004597
Resolved issues and error corrections
Invoice tax recalculations through Avatax now refresh the pre-tax base amount each time, instead of reusing an older cached value. This helps prevent incorrect invoice line totals when Avatax returns updated base amounts during recomputation.
Original PR description
Previously, when recomputing taxes via Avatax, `manual_tax_amounts` was cleared and repopulated from the fresh API response, but `manual_total_excluded_currency` was only set if it was None. This meant that after the first Avatax call, the pre-tax base amount was never refreshed from subsequent API responses, even though the tax amounts were. This inconsistency could cause stale pre-tax base amounts to persist on invoice lines across recomputations, even when Avatax returned a different base amount. By resetting `manual_total_excluded_currency` to `None` at the start of each recomputation, mirroring what is already done for `manual_tax_amounts`, we ensure that the pre-tax base is always taken from the current Avatax response rather than a previously cached value. opw-6235597 Forward-Port-Of: odoo/enterprise#123802
Fixed an issue where products using cost-based pricelists showed an outdated On Sale Price after changing the cost. The price now refreshes immediately, helping users see accurate sale pricing when managing product variants.
Original PR description
When we create a product variant and have a pricelist which is based on the cost price, and change the cost price, the on_sale_price doesn't update correctly. It gets delayed by one update because the product._origin isn't getting updated with the new onchanged value. Steps to Reproduce: 1.Create a pricelist and add a line with "formula" price type, and based on "cost", 2.Create a product variant, and add the pricelist just created. 3.Change the "Cost". The "On Sale Price" updates based on the value before. To fix the issue, we need to update the product._origin for standard_price just like the lst_price before computing the on_sale_price opw-5947995 Forward-Port-Of: odoo/enterprise#120420 Forward-Port-Of: odoo/enterprise#119470
Indian GST reports now better reflect legal requirements for import purchases. Imports of services are no longer shown in GSTR-2B, and GSTR-3B reporting has been aligned with the updated sections for imports of goods and services.
Original PR description
As per the law, import of services is not required to be shown in GSTR-2B. Therefore, the related report lines are removed in this commit. Additionally, GSTR-3B reporting is now handled according to the updated section changes for import of goods and services. task-6330737
The appointment calendar now uses the appointment's own timezone when deciding which month to show. This prevents available dates from disappearing or incorrectly showing no slots for bookings near month boundaries.
Original PR description
Steps to reproduce: 1. Install website_appointment 2. Create an appointment with `on specific dates` as Allow booking 3. Set Start time to 1 Jan 2027 2 AM to 31 Dec 2027 4 PM (2 AM is important here)…
Steps to reproduce: 1. Install website_appointment 2. Create an appointment with `on specific dates` as Allow booking 3. Set Start time to 1 Jan 2027 2 AM to 31 Dec 2027 4 PM (2 AM is important here) 4. Set timezone as `Asia/Kolkata` 5. Go to the website via the smart button 6. Navigate through the months in the calendar Issue: - Some months are not showing dates or showing ``` Sorry, we have no more slots available for this month. ``` Why? - The month used for calendar navigation is computed from the appointment `start_datetime`, which is stored in UTC. For appointments close to a month boundary, the UTC date may belong to the previous month (e.g., `2026-12-31 20:30 UTC` instead of `2027-01-01 02:00 Asia/Kolkata`). https://github.com/odoo/enterprise/blob/6b18215bfa98ef636b63f4fafbba1d25264f4883/appointment/controllers/appointment.py#L1061-L1066 As a result, the requested month offset is computed from the wrong month, causing the calendar to display an incorrect month. Solution: - Convert the appointment start_datetime from UTC to the appointment timezone before computing the requested month used for calendar navigation. opw-6224929
Sale Details reports are no longer incorrectly blocked or reformatted for point-of-sale sessions that were opened before Belgian blackbox signing was active. The change also prevents changing the linked blackbox device while a POS session is still open, reducing reporting inconsistencies.
Original PR description
The Sale Details report was blocked and reformatted for every session whose config has a blackbox, including sessions opened before the blackbox was used (whose orders were never signed by the FDM). Introduce a non-stored `use_blackbox` field on `pos.session` Also prevent changing `l10n_be_blackbox_be_id` on a POS config while it has an open session.
This fixes Belgian payroll rules so the 3000 deduction uses the correct values for the second and third quarters of 2026. It helps ensure payroll calculations remain compliant and accurate for affected employees during those periods.
The automatic bank reconciliation process now gives failed items one more attempt before removing them from processing. This helps avoid missed reconciliations caused by temporary system issues, improving reliability for accounting operations.
Original PR description
The auto reconcile cron drops the lines whenever they raise an error which is an issue for things like serialization errors. Now the code retries failed lines once before dropping them to make sure it's an issue with the lines. task-6273202
This fix ensures Saudi GOSI payroll contributions are calculated without unintended proration. It helps keep payroll amounts accurate for affected employees and reduces the risk of payroll accounting discrepancies.
Original PR description
task-id: 6380239
Regular employees can now open the Attendance Gantt view even when coworkers with fully flexible schedules have approved time off. This prevents an access error and keeps attendance planning visible without exposing restricted time-off records.
Original PR description
When a regular employee accesses the Attendance Gantt view, they encounter an AccessError if there are other employees with flexible schedules who have taken time off. ### **Steps to reproduce:** -…
When a regular employee accesses the Attendance Gantt view, they encounter an AccessError if there are other employees with flexible schedules who have taken time off. ### **Steps to reproduce:** - Install hr_holidays, hr_attendance with demo. - Create a time off and validate for an employee, and set the employee's contract to fully flexible - As demo user, go to the attendance app. ### **Error:** ``` odoo.exceptions.AccessError: Sorry, Marc Demo doesn't have 'read' access to: - Time Off (hr.leave) ``` ### **Root cause:** since [this commit](https://github.com/odoo/enterprise/pull/112482/changes/b326263d67dc0654a7d4b6d77dc4ad8de53bc1c1), `handle_flexible_leave_interval` accesses fields on `leave.holiday_id` at [1] to determine the bounds of flexible leave intervals. when the unavailability computation is performed by a regular employee, they may not have access to the corresponding `leave` record leading to access error. [1]- https://github.com/odoo/enterprise/blob/7a34c9a6a58df22fbef143d820a29106249e3af5/hr_holidays_gantt/models/resource_calendar.py#L17-L24 ### **Fix:** This commit allows regular employees to compute unavailability intervals for flexible employees. **opw-6243778**
This fix prevents VoIP call recordings made from Apple mobile devices from being saved as silent audio files. It improves reliability for users who rely on recorded phone calls for follow-up, compliance, or customer service review.
Original PR description
Before this commit, recording a VoIP phone call from an Apple mobile device generated a silent audio file. This issue happened because the configured 8000 `audioBitsPerSecond` value was too low. Apple mobile browsers strictly respect this value, while other browsers ignore it and default to a higher bitrate to 128000. Increasing `audioBitsPerSecond` to 32000 on WebKit browsers fixes the issue on Apple mobile devices. How to reproduce: - Set up a DIDWW user. - Enable call recording. - Make a call. - Open the call and play the recording. opw-6046534
This update adds the latest official Luxembourg salary index values for May 2025 and June 2026. It ensures employee contracts and related payroll calculations use the correct index instead of an outdated 2023 value, improving accuracy for Luxembourg payroll processing.
Original PR description
## Issue When creating or browsing an existing contract in a Luxembourgish company, the current index shown is the one from September 2023 (which was up-to-date until Mai 2025). If the contract is…
## Issue
When creating or browsing an existing contract in a Luxembourgish company, the current index shown is the one from September 2023 (which was up-to-date until Mai 2025). If the contract is created after Mai 2025, the "Index on Contract Signature" field is also wrong.
## Steps to reproduce
1. Install *Luxembourg - Payroll* (`l10n_lu_hr_payroll`)
2. Using a Luxembourgish company, create a new contract for an employee
- *Contract Start Date*: Any date after 05/01/2025 (Mai 1st 2025)
3. __The *Index on Contract Signature* shows `944.43`, which is the index from September 2023. It does not match with the most recent indices.__
## Cause
The two most recent indices are missing from the [`rule_parameter_lu_index`](https://github.com/odoo/enterprise/blob/885edbc270a86ab76e0a6eff4acb5767c0fe29d1/l10n_lu_hr_payroll/data/rule_parameters/general_rules_data.xml#L4-L58). These indices are:
- `968.04` from 2025-05-01 (Mai 1st 2025)
- `992.24` from 2026-06-01 (June 1st 2026)
These values were taken from [here](https://salary.lu/en/tools/social-parameters/indexation-of-salaries) and double-checked [here](https://lustat.statec.lu/?lc=en&tm=DF_C1201&pg=0&snb=1).
## Tests modification
Updating the latest index had an impact on the tests from the `l10n_lu_hr_payroll_account` (testing the salary rules). In fact, the current index (`l10n_lu_current_index`) is [used to compute the indexed wage](https://github.com/odoo/enterprise/blob/7892d035ddb968d67a3e8da0daf91292bd8fb499/l10n_lu_hr_payroll/models/hr_contract.py#L24-L33) (`l10n_lu_indexed_wage`), which is then used to compute most lines in the payslip (e.g., the `WAGE_SUPPLEMENT_70`).
https://github.com/odoo/enterprise/blob/7892d035ddb968d67a3e8da0daf91292bd8fb499/l10n_lu_hr_payroll/data/salary_rules/hr_salary_rule_data.xml#L70-L74
Since the latest index is not the same as when those tests were written, the values are not correct anymore. To prevent this, time was frozen to 01/01/2024 to use the expected index (944.43, from September 2023).
opw-6330790
Forward-Port-Of: odoo/enterprise#122147