Monday, July 14, 2025
12 changes · saas-18.3
Resolved issues and error corrections
This update prevents important activity categories such as calls, meetings, approvals, leave follow-ups, contracts, and tax closing tasks from being removed or incorrectly tied to one business area. It also makes activity creation more reliable across apps, reducing crashes and missed follow-ups in workflows that depend on these activities.
Original PR description
Master data protection ====================== In general, be defensive with activity types: avoid crash when activity type has been removed, try to gracefully recover from non existing data, protect…
Master data protection
======================
In general, be defensive with activity types: avoid crash when activity
type has been removed, try to gracefully recover from non existing
data, protect types linked to business code that should not be unlinked
or changed from model.
Introduce a generic way to mark some activity types as master data
* model is fixed and should not be modified, because it is linked
to specific flows e.g. todo should be generic;
* data should not be unlinked, because it is used in automated flows
like plans, business code, ... and cannot easily be replaced;
Mail: make "Call", "Meeting" and "Todo" activity types master data users
cannot remove as they are required in various flows: fleet, plans,
voip, ... Also force their model to be False (aka be cross model).
Mail: make "Warning" and "Upload document" activity types in addition
to "Call" and "Todo", always cross model. As they are used in various
apps it should not be specific to a model.
Hr holidays: prevent from modifying leave activity types, as they are
used in business flows and in automated code.
Fleet: prevent from modifying contract activity type (same reason).
Account Online Synchornization: make "Bank Synchronization" master
data as business behavior dependso on it. Also fix model used for
the type.
Account reports: make "Tax Closing" master data as business flow
depends on it.
Approvals: make "Approval" master data as business flow depends on it
and it is not easy to remove it in their usage.
Hr Payroll: make "Leaves to defer" master data as business flow
depends on it.
Voip: make "Call" activity type master data users cannot remove as it
is required in various flows of VOIP. Also force its model to be False
as it is used in various models and should not suddenly be limited to
a given model. Done in community, as activity is defined in 'mail'.
Studio: make "Approval" master data as approval flow depends on it.
Calendar: fix activities creation
=========================
Current event creation tries to create activities. However code coming
from https://github.com/odoo/odoo/pull/72043 seems quite broken: it tries to find if the
target model accepts activities, but does not by browsing the wrong
model with wrong ids ... which globally turns off activity creation.
This fix rewrites a bit code creating activities when creating an event so
that
* check activity support on the right model;
* it uses the right model on activity type: otherwise you may end up with
models that do not match between record and activity type;
* remove useless (or wrong) code trying to browse 'model ids' on a given
model;
* we now correctly check for activity inheritance using 'is_mail_activity'
field on IrModel;
Task-3777606
Forward-Port-Of: odoo/odoo#218184
Forward-Port-Of: odoo/odoo#156731Website footer updates now handle expected footer-format issues without hiding serious database conflicts. This helps prevent failed update processes and allows automatic retry handling when concurrent changes occur.
Original PR description
Updating website footer views sometimes fails with "could not serialize access due to concurrent update" errors due to concurrent database writes, causing transaction aborts and breaking the update…
Updating website footer views sometimes fails with "could not serialize access due to concurrent update" errors due to concurrent database writes, causing transaction aborts and breaking the update process. Error: `InFailedSqlTransaction: current transaction is aborted, commands ignored until end of transaction block` The issue arises because the exception block at [1] catches and silently suppresses all exceptions, including critical `serialization errors`. These serialization errors cause the current database transaction to fail. However, since the exception is caught and not properly handled or propagated, execution continues within the context of the failed transaction. As a result, subsequent operations fail with an `InFailedSqlTransaction` error. This commit addresses the issue by specifically handling the `etree.XMLSyntaxError` raised by `etree.fromstring(view_id.arch_db)`. The error is safely caught and logged with an appropriate message. Additionally, it adds logging when the `configurator_footer_links` element is not found in the view and prevents further execution in that case. All other exceptions, including database-related errors, are no longer caught at this level; instead, they are allowed to propagate and are handled at the request level, where automatic retries are triggered. handled at the request level, where automatic retries are triggered. [1]:- https://github.com/odoo/odoo/blob/5cc57cc0ca8ee17060905b692727ed965e197f61/addons/website/models/website.py#L722-L725 sentry-5665538920
Point of Sale receipts now better support Belgian blackbox requirements by clearly showing whether a ticket is valid and whether the order is a refund. Duplicate receipt details such as blackbox date and company street are removed because they are already shown elsewhere, making receipts clearer for staff and customers.
Original PR description
Since this revmap of the POS receipt (https://github.com/odoo/odoo/pull/201105), we have to make some changes on the receipt when using `pos_blackbox_be`: - Display if the ticket is valid or not (Pro Format) & increase its size. - Display if the order was a refund or not. - No need to display the `blackbox_date` since we now have the `date_order` inside `/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.xml``. - No need to display the `order.company.street` since the whole adress is now displayed inside `/point_of_sale/static/src/app/screens/receipt_screen/receipt/order_receipt.xml`. task-id: 4848882 enterprise PR: https://github.com/odoo/enterprise/pull/87759 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When delivery costs are invoiced based on the actual cost after shipment, the checkout no longer presents that delivery option as free. Customers now see a disclaimer explaining that the final delivery cost will be calculated after delivery, reducing confusion and setting clearer expectations.
Original PR description
Issue: If the delivery invoice policy was set to "real" (meaning that we'll invoice the real delivery cost, after delivery), the delivery was shown as being free on eCommerce (since we don't know the cost yet). Fix: Show a disclaimer indicating that the cost will be computed after delivery. opw-4779059 Forward-Port-Of: odoo/odoo#218378
This fix restores a database index used when attachments reference an original file, which prevents slow checks during deletion. It should make deleting attachments much faster on very large databases, reducing delays for users and administrators.
Original PR description
On a DB with 15M+ attachments, deleting a single attachment takes several seconds. Most of the time is spent on the circular `original_id` foreign key.
We add back the index which was removed in [1]
```
Delete on ir_attachment (cost=0.43..8.45 rows=0 width=0) (actual time=0.274..0.274 rows=0 loops=1)
-> Index Scan using ir_attachment_pkey on ir_attachment (cost=0.43..8.45 rows=1 width=6) (actual time=0.252..0.253 rows=1 loops=1)
Index Cond: (id = 82807)
Planning Time: 0.049 ms
Trigger for constraint ir_attachment_original_id_fkey: time=2330.796 calls=1
```
[1] https://github.com/odoo/odoo/commit/eedf37d6e286b995c47b946be1a6b66817094eff
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#218120Deleting bank statement lines after applying a reconciliation model now keeps the model linked by restoring it to the suspense line. This prevents reconciliation setup from being lost and helps accounting users maintain consistent bank matching behavior.
Original PR description
Before this commit when applying a reco model, the reco model is on the lines of the move except the liquidity line which means that when we delete the lines the reco models is lost. Now when deleting a line, if the statement line had a reco model, we place it back on the suspense. Also correcting some demo data where they added the reconcile model on the liquidity but since the reco model will be added at the creation of the reco model, that's not needed. task: 4908501
This update prevents important activity types used by automated business processes from being deleted or changed in ways that could break workflows. It also adds safeguards so apps recover more gracefully if activity configuration data is missing, and reduces unnecessary VOIP update notifications.
Original PR description
Master data protection ====================== In general, be defensive with activity types: avoid crash when activity type has been removed, try to gracefully recover from non existing data, protect…
Rental combo products now correctly show available booking dates when stock limits are enabled. This prevents customers from seeing every date as unavailable and helps keep online rental sales working as expected.
Original PR description
Issue: - Create a rental product (with a rental pricing), - Make it storable and don't allow out-of-stock orders, - Now make it a combo product, - Add a rental combo choice (to be able to save it), - Go to the product's page on eCommerce, - Issue: all dates are unavailable. Cause: The date range picker only relies on `allow_out_of_stock_order` to know whether to compute rental availabilities (but not on `is_storable`). Fix: Also rely on `is_storable` to know whether to compute rental availabilities. opw-4846084 Forward-Port-Of: odoo/enterprise#90084
Bank reconciliation now works correctly when analytic accounting details are synchronized with journal entries. This prevents processing loops and helps ensure accounting data stays consistent during reconciliation.
Original PR description
Since a recent fix[^1], the analytic distribution on journal entries is updated with any update made on analytic items. In order to avoid loops and do things in the right order, a context key was added. However, the reconciliation widget was also manipulating analytic items, so it needed to use the context key as well. opw-4936028 opw-4933629 opw-4935236 opw-4933456 opw-4933652 opw-4935789 opw-4938570 opw-4938388 opw-4935709 opw-4940233 opw-4938849 [^1]: https://github.com/odoo/odoo/commit/8194c6e2bfedc9437964090b1a498c3e8cff225c Forward-Port-Of: odoo/enterprise#90175
Belgian payroll reporting has been updated to match the DmfA requirements for the second quarter of 2025. This helps Belgian employers keep payroll declarations compliant with the latest official reporting rules.
Original PR description
Forward-Port-Of: odoo/enterprise#90016
The Belgian POS blackbox receipt now better matches certification requirements after recent receipt layout changes. It clearly shows whether a ticket is valid and whether an order is a refund, while removing duplicate date and address details already shown elsewhere.
Original PR description
Since this revmap of the POS receipt (https://github.com/odoo/odoo/pull/201105), we have to make some changes on the receipt when using `pos_blackbox_be`: - Display if the ticket is valid or not (Pro Format) & increase its size. - Display if the order was a refund or not. - No need to display the `blackbox_date` since we now have the `date_order` inside `/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.xml``. - No need to display the `order.company.street` since the whole adress is now displayed inside `/point_of_sale/static/src/app/screens/receipt_screen/receipt/order_receipt.xml`. task-id: 4848882 community PR: https://github.com/odoo/odoo/pull/214394
Fixed an issue that caused an error when creating an Anniversary Discount campaign in Marketing Automation. This ensures eCommerce marketing campaigns can be created reliably and keeps the campaign targeting rules clearer and easier to maintain.
Original PR description
We had a traceback when trying to create an Anniversary Discount marketing campaing
due to the domain's construction.
Steps to reproduce:
-------------------
* Go to Marketing Automation app
* Go to eCommerce tab --> anniversary discount
* Click " Create Campaign"
> Observation:
File "/data/build/enterprise/marketing_automation/models/marketing_activity.py", line 142, in _compute_inherited_domain
literal_eval(activity.campaign_id.domain or '[]')])
Why the fix:
------------
The problematic line was introduced in this REV: 1aa05c89f3371981922e3dc52d8334104aa425b9.
The domain was originally built in this IMP: cf2124f4f20a805077502587f9a8be0af0a753c3.
The domain was intended to be used dynamically, but after the revision, that usage changed—so the domain needed to be rebuilt.
We've simplified the domain to eliminate overlapping conditions, ensuring the same logic and result, but with improved readability.
opw-4857722
Forward-Port-Of: odoo/enterprise#89375Master data protection
======================
In general, be defensive with activity types: avoid crash when activity
type has been removed, try to gracefully recover from non existing
data, protect types linked to business code that should not be unlinked
or changed from model.
Introduce a generic way to mark some activity types as master data
* model is fixed and should not be modified, because it is linked
to specific flows e.g. todo should be generic;
* data should not be unlinked, because it is used in automated flows
like plans, business code, ... and cannot easily be replaced;
Mail: make "Call", "Meeting" and "Todo" activity types master data users
cannot remove as they are required in various flows: fleet, plans,
voip, ... Also force their model to be False (aka be cross model).
Mail: make "Warning" and "Upload document" activity types in addition
to "Call" and "Todo", always cross model. As they are used in various
apps it should not be specific to a model.
Hr holidays: prevent from modifying leave activity types, as they are
used in business flows and in automated code.
Fleet: prevent from modifying contract activity type (same reason).
Account Online Synchornization: make "Bank Synchronization" master
data as business behavior dependso on it. Also fix model used for
the type.
Account reports: make "Tax Closing" master data as business flow
depends on it.
Approvals: make "Approval" master data as business flow depends on it
and it is not easy to remove it in their usage.
Hr Payroll: make "Leaves to defer" master data as business flow
depends on it.
Voip: make "Call" activity type master data users cannot remove as it
is required in various flows of VOIP. Also force its model to be False
as it is used in various models and should not suddenly be limited to
a given model. Done in community, as activity is defined in 'mail'.
Studio: make "Approval" master data as approval flow depends on it.
Calendar: fix activities creation
=========================
Current event creation tries to create activities. However code coming
from https://github.com/odoo/odoo/pull/72043 seems quite broken: it tries to find if the
target model accepts activities, but does not by browsing the wrong
model with wrong ids ... which globally turns off activity creation.
This fix rewrites a bit code creating activities when creating an event so
that
* check activity support on the right model;
* it uses the right model on activity type: otherwise you may end up with
models that do not match between record and activity type;
* remove useless (or wrong) code trying to browse 'model ids' on a given
model;
* we now correctly check for activity inheritance using 'is_mail_activity'
field on IrModel;
Task-3777606
Forward-Port-Of: odoo/enterprise#89881
Forward-Port-Of: odoo/enterprise#58164