Saturday, August 22, 2026
27 changes · master
Resolved issues and error corrections
This fix prevents approved employee leave records from having their work entry type recalculated later. Only draft leave requests are updated, helping preserve payroll-related information once leave has been validated.
Original PR description
We should recompute the work entry type of only draft leaves. 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#283512
Fixed an issue where scheduling a meeting from an activity could open the calendar without the expected linked record details. This ensures users see the correct default information when moving from activities to calendar events, reducing confusion and manual re-entry.
Original PR description
Prior to this commit, scheduling a meeting from the activity schedule wizard would fail to open the calendar with the correct default values (like the linked res_model). This occurred because a recent change introduced a context-cleaning step during activity creation to prevent any pollution for unassigned role activities. While this is a good defensive guard, this permanently stripped context from the returned recordset, causing downstream actions to lose context keys like `default_res_model`. This commit restores the original context on the returned activity recordset, ensuring subsequent actions receive the correct default parameters. Task-6482365 Forward-Port-Of: odoo/odoo#283586
Fixed an issue where clicking the cashier status icon in certain Belgian Blackbox Point of Sale setups could trigger an error. This improves reliability for cashiers when employee login is disabled.
Original PR description
Steps: ----------- - Install pos_blackbox_be. - Configure a PoS with Blackbox Belgium enabled and `Log in with Employees` disabled. - Open a PoS session and click exactly on the session status circle on the cashier icon. Issue: ----------- - A traceback is raised with the following error: `this.cashierSelector is not a function`. Cause: ----------- - Installing pos_blackbox_be makes the cashier icon appear clickable by adding the `pe-auto` class to the cashier icon's session status circle, even when `Log in with Employees` is disabled. In this configuration, the cashier selector is unavailable, causing the click handler to fail. Fix: ----------- - Add a dedicated onClick handler to the CashierName button. - Return early when `module_pos_hr` is not enabled before calling `selectCashier`, ensuring that `selectCashier` is called only when the `module_pos_hr` configuration is enabled. Task-6369404 Forward-Port-Of: odoo/odoo#282656
The Accounting journal entry screen now shows clear labels on the reversal smart button. Users can more easily tell whether they are viewing original entries with reversals or the reversal entry itself, reducing confusion during accounting reviews.
Original PR description
Issue: - The reversal smart button was displayed without a label for journal entries. Fix: - Show 'Reversal Entries' for original journal entries and 'Journal Entry' for their reversal entries. Impact: - The reversal smart button now displays the correct label for journal entries and their reversals. task-[6472384](https://www.odoo.com/odoo/project/967/tasks/6472384) Forward-Port-Of: odoo/odoo#283756
This fix prevents a secondary database error from hiding the real issue when email notifications are updated at the same time by concurrent processes. It helps email sending failures be handled and diagnosed correctly, improving reliability in the Mail app under load.
Original PR description
When updating mail notifications during `mail.mail._send()`, a `SerializationFailure` raised while flushing the notification recordset leaves the current transaction in an aborted state. As `_send()`…
When updating mail notifications during `mail.mail._send()`,
a `SerializationFailure` raised while flushing the notification recordset leaves the current transaction in an aborted state.
As `_send()` continues handling the exception, accessing fields:
- https://github.com/odoo/odoo/blob/127f1316540ec6cc6880ea3515e6923ba3903bc7/addons/mail/models/mail_mail.py#L816
So, any subsequent SQL query fails with
`InFailedSqlTransaction`, masking the original concurrency error.
Avoid accesing to `mail.message_id` with aborted cursor, preserving the original `SerializationFailure`.
A regression test is added to simulate a concurrency failure during
`flush_recordset()` and verify that the cursor is no longer used dirty
The logger for the unittest without the fix is the following:
```log
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "odoo/addons/mail/models/mail_mail.py", line 719, in _send
notifs.flush_recordset(['notification_status', 'failure_type', 'failure_reason'])
File "<string>", line 3, in flush_recordset
File "unittest/mock.py", line 1139, in __call__
return self._mock_call(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "unittest/mock.py", line 1143, in _mock_call
return self._execute_mock_call(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "unittest/mock.py", line 1204, in _execute_mock_call
result = effect(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^
File "odoo/addons/test_mail/tests/test_message_post_concurrent.py", line 93, in mocked_mail_notification_flush_recordset
return original_flush_recordset(self, *vals, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "odoo/odoo/models.py", line 6788, in flush_recordset
self._flush(fnames)
File "odoo/odoo/models.py", line 6852, in _flush
model.browse(some_ids)._write_multi(vals_list)
File "odoo/odoo/models.py", line 4938, in _write_multi
self.env.execute_query(SQL(
File "odoo/odoo/api.py", line 993, in execute_query
self.cr.execute(query)
File "odoo/odoo/sql_db.py", line 371, in execute
res = self._obj.execute(query, params)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.errors.SerializationFailure: could not serialize access due to concurrent update
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "odoo/addons/test_mail/tests/test_message_post_concurrent.py", line 107, in test_mail_send_dirty_cursor
mails.send()
File "odoo/addons/mail/models/mail_mail.py", line 652, in send
self.browse(batch_ids)._send(
File "odoo/addons/mail/models/mail_mail.py", line 818, in _send
mail.id, mail.message_id)
^^^^^^^^^^^^^^^
File "odoo/odoo/fields.py", line 1309, in __get__
self.compute_value(recs)
File "odoo/odoo/fields.py", line 1491, in compute_value
records._compute_field_value(self)
File "odoo/odoo/models.py", line 5302, in _compute_field_value
fields.determine(field.compute, self)
File "odoo/odoo/fields.py", line 113, in determine
return needle(records, *args)
^^^^^^^^^^^^^^^^^^^^^^
File "odoo/odoo/fields.py", line 710, in _compute_related
record[self.name] = self._process_related(value[self.related_field.name], record.env)
~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^
File "odoo/odoo/models.py", line 7083, in __getitem__
return self._fields[key].__get__(self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "odoo/odoo/fields.py", line 1272, in __get__
recs._fetch_field(self)
File "odoo/odoo/models.py", line 4120, in _fetch_field
self.fetch(fnames)
File "odoo/addons/mail/models/mail_message.py", line 756, in fetch
return super().fetch(field_names)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "odoo/odoo/models.py", line 4158, in fetch
fetched = self._fetch_query(query, fields_to_fetch)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "odoo/odoo/models.py", line 4245, in _fetch_query
rows = self.env.execute_query(query.select(*sql_terms))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "odoo/odoo/api.py", line 993, in execute_query
self.cr.execute(query)
File "odoo/odoo/sql_db.py", line 371, in execute
res = self._obj.execute(query, params)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.errors.InFailedSqlTransaction: current transaction is aborted, commands ignored until end of transaction block
```
Real error in production:
```log
2023-04-15 10:43:14,978 106451 ERROR my_db odoo.sql_db: bad query: UPDATE "mail_notification" SET "failure_reason" = "__tmp"."failure_reason"::text, "failure_type" = "__tmp"."failure_type"::VARCHAR, "notification_status" = "__tmp"."notification_status"::VARCHAR FROM (VALUES (4426629, 'Error without exception. Probably due to concurrent access update of notification records. Please see with an administrator.', 'unknown', 'exception')) AS "__tmp"("id", "failure_reason", "failure_type", "notification_status") WHERE "mail_notification"."id" = "__tmp"."id" ERROR: could not serialize access due to concurrent update
```
```log
2023-04-14 10:43:14,978 106451 ERROR my_db odoo.sql_db: bad query: UPDATE "mail_mail" SET "failure_reason"='Error without exception. Probably due do sending an email without computed recipients.',"headers"='{''X-SMTPAPI'': ''{"ip_pool": "Transactional"}'', ''X-Odoo-Objects'': ''sale.order-1436960''}',"state"='exception',"write_uid"=1,"write_date"=(now() at time zone 'UTC') WHERE id IN (2548540)
ERROR: current transaction is aborted, commands ignored until end of transaction block
```
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
# UPDATE 2026-07-22
The reviewer requested to remove the large docstring
For record, the docstring was
```python
"""Reproduces a concurrency scenario where `mail_mail._send()` fails with a PSQL SerializationFailure after
flushing `mail.notification` records. After such a failure, the cursor is left in an aborted
(`InFailedSqlTransaction`) state, so any further SQL access (e.g. reading `mail.message_id` like
https://github.com/odoo/odoo/blob/127f1316540ec6cc68/addons/mail/models/mail_mail.py#L816)
would raise a new error masking the original SerializationFailure.
Setup:
- Uses a separate `cursor()` to create and commit a message with its `mail.mail` and `mail.notification`
records, so they are visible to a second, concurrent transaction.
Concurrency simulation:
- `MailNotification.flush_recordset` is patched so that, right before the real flush runs, a second cursor
updates the same `mail.notification` records (`failure_reason`). This forces PSQL to raise a
SerializationFailure when the original transaction tries to flush those rows.
Assertions:
- `SerializationFailure` is raised confirming the concurrency conflict.
- `mail_mail._send()` logs the expected error message containing the mail `id` and `message-id`
Cleanup: created records are unlinked in `finally`
"""
```
# UPDATE 2026-07-23
The reviewer requested to remove the unittest
For record, the unittest was
```diff
diff --git a/addons/test_mail/tests/test_message_post.py b/addons/test_mail/tests/test_message_post.py
index 53dd5b9eec52..46a3958a5bff 100644
--- a/addons/test_mail/tests/test_message_post.py
+++ b/addons/test_mail/tests/test_message_post.py
@@ -7,17 +7,21 @@ from datetime import datetime, timedelta
from freezegun import freeze_time
from itertools import product
from markupsafe import escape, Markup
+from psycopg2.errorcodes import SERIALIZATION_FAILURE as SERIALIZATION_FAILURE_CODE
+from psycopg2.errors import SerializationFailure
from unittest.mock import patch
-from odoo import tools
+from odoo import SUPERUSER_ID, api, tools
from odoo.addons.base.tests.test_ir_cron import CronMixinCase
-from odoo.addons.mail.tests.common import mail_new_test_user, MailCommon
+from odoo.addons.mail.models.mail_notification import MailNotification
+from odoo.addons.mail.tests.common import mail_new_test_user, MailCommon, MockEmail
from odoo.addons.test_mail.data.test_mail_data import MAIL_TEMPLATE_PLAINTEXT
from odoo.addons.test_mail.models.test_mail_models import MailTestSimple
from odoo.addons.test_mail.tests.common import TestRecipients
from odoo.api import call_kw
from odoo.exceptions import AccessError
-from odoo.tests import tagged
+from odoo.modules.registry import Registry
+from odoo.tests import TransactionCase, get_db_name, tagged
from odoo.tools import mute_logger, formataddr
from odoo.tests.common import users
@@ -2244,3 +2248,49 @@ class TestMessagePostLang(MailCommon, TestRecipients):
self.assertIn('html lang="es_ES"', email['body'])
else:
self.assertIn('html lang="en_US"', email['body'])
+
+
+@tagged('database_breaking')
+class TestMessagePostConcurrent(MockEmail, TransactionCase):
+ """Mail concurrency edge cases that require real, separately committed transactions
+ instead of the usual rollback-based TransactionCase isolation.
+ """
+
+ def test_mail_send_dirty_cursor(self):
+ """Reproduces SerializationFailure `mail_mail._send()` fails,
+ the cursor is left in an aborted state, so any further SQL access would raise a new error
+ (e.g. reading `mail.message_id` like
+ https://github.com/odoo/odoo/blob/127f1316540ec6cc68/addons/mail/models/mail_mail.py#L816)
+ """
+ original_flush_recordset = MailNotification.flush_recordset
+
+ def mocked_mail_notification_flush_recordset(self, *args, **kwargs):
+ with Registry(get_db_name()).cursor() as cr:
+ cr.execute('UPDATE mail_notification SET failure_reason = %s WHERE id IN %s', ('Forced Concurrent Update', tuple(self.ids)))
+ return original_flush_recordset(self, *args, **kwargs)
+
+ recs2unlink = []
+ with Registry(get_db_name()).cursor() as cr:
+ env = api.Environment(cr, SUPERUSER_ID, {})
+ partner = env.ref('base.user_admin').partner_id
+ try:
+ message = partner.message_post(body='Hello', message_type='comment', partner_ids=[partner.id], mail_auto_delete=False, force_send=False)
+ notifs = env['mail.notification'].search([('notification_type', '=', 'email'), ('mail_mail_id', 'in', message.mail_ids.ids)])
+ self.assertTrue(notifs)
+ mails = message.mail_ids
+ recs2unlink.extend([notifs, mails, message])
+ cr.commit()
+
+ mails = self.env[mails._name].browse(mails.ids)
+ with (
+ mute_logger('odoo.sql_db'), self.assertRaises(SerializationFailure) as exc, self.mock_mail_gateway(),
+ patch(f'{MailNotification.__module__}.{MailNotification.__name__}.flush_recordset', autospec=True, side_effect=mocked_mail_notification_flush_recordset),
+ self.assertLogs('odoo.addons.mail.models.mail_mail', level='ERROR') as log_capture,
+ ):
+ mails.send()
+ finally:
+ for rec2unlink in recs2unlink:
+ env[rec2unlink._name].browse(rec2unlink.ids).unlink()
+
+ self.assertEqual(exc.exception.pgcode, SERIALIZATION_FAILURE_CODE)
+ self.assertIn(f'Exception while processing mail with ID {mails.id} and Msg-Id \'{mails.message_id}\'.', [record.message for record in log_capture.records])
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#279897
Forward-Port-Of: odoo/odoo#274089This fixes an issue in the HTML editor where a color set on an outer table could incorrectly overwrite the colors of tables nested inside it. Users editing rich content with nested tables will see more accurate formatting and fewer unexpected color changes.
Original PR description
Problem: When a `table` with a `color`/`backgroundColor` contains a nested `table`, `distributeTableColorsToAllCells` propagates the outer table's color to every `td` in the subtree, including cells…
Problem:
When a `table` with a `color`/`backgroundColor` contains a nested `table`, `distributeTableColorsToAllCells` propagates the outer table's color to every `td` in the subtree, including cells belonging to the inner table. The inner table's own color is then discarded since its `td`s already have a value.
Cause:
`table.querySelectorAll("td")` returns every `td` in the entire subtree, not just the table's own direct cells.
Solution:
Scope the selected `td`s to `td.closest("table") === table`, so a table's color is only distributed to its own cells.
Steps to reproduce:
1. Add a `background-color` to an outer `table`.
2. Nest a `table` with a different `background-color` inside one of its cells.
3. Load/normalize the content in the editor.
4. Observe both tables' cells carry the outer table's color.
opw-6438972
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#283373
Forward-Port-Of: odoo/odoo#281413This fix updates an internal image test to work reliably with the Pillow version included in Ubuntu Jammy. It helps keep automated checks stable across supported environments without changing user-facing behavior.
Original PR description
`Image.Palette.ADAPTIVE` is not available in the Pillow version provided by Ubuntu Jammy, causing the animated GIF test to fail. Use `Image.ADAPTIVE` instead, which is compatible with both older and newer Pillow versions. 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#282388 Forward-Port-Of: odoo/odoo#282223
Searching messages in Discuss now handles search text with repeated spaces correctly. This prevents an error that could interrupt users when looking through conversations and keeps message highlighting working as expected.
Original PR description
**Steps to reproduce:**
- Go to Discuss app
- Open a conversation
- Click on the Search Messages button
- Enter a word, then a lot of spaces
- `RangeError: Maximum call stack size exceeded`
**Issue:**
During highlighting, if the search term contains multiple spaces, `searchTerm.split(" ")` produces empty terms `""`. Then the empty regex will match on every character, creating a lot of highlight `<span>` elements and eventually causing the error on `element.replaceChildren(...newNode);`.
**Fix:**
Filter out empty terms before processing.
opw-6446173
Forward-Port-Of: odoo/odoo#282059Regular sales users can now see the three-dot menu on product cards in the Product Catalog. This restores access to actions they were already allowed to use elsewhere, reducing unnecessary administrator dependency.
Original PR description
**Steps to Reproduce:** 1. Give the logged in user "Sales / User: Own Documents Only" access rights 2. Open the Product Catalog (from a Sales Order line) 3. The three-dot menu on a product card is not visible when you hover over it 4. Change user rights with "Sales Administrator" access rights, the three-dot menu appears as expected **Issue:** The three-dot menu on the Product Catalog kanban card is restricted to the Sales Administrator group, even though the actions it exposes (edit product, availability, etc) are already accessible to regular Sales users through other menus/views. **Why this happens:** The view `product.view.kanban.catalog.inherit.sale` sets the `groups` attribute to `sales_team.group_sale_manager`, restricting the menu behind Administrator rights instead of the base Sales access group opw-6416629 Forward-Port-Of: odoo/odoo#279400
The Point of Sale combo setup now correctly keeps separate choices for the same product when customers select different side options. This prevents extra duplicate order lines, making restaurant orders clearer and reducing cashier corrections.
Original PR description
Steps: --- - Open the Burger combo choice. - Set the maximum quantity to 2. - Open the restaurant. - Add a cheese burger with Belgian fresh homemade fries. - Add another cheese burger with sweet potato fries. - Add Coca-Cola. - Click Apply. Issue: --- - A new cheese burger line is created even though a cheese burger line already exists. Cause: --- - When the same product has different configurations but belongs to the same `combo_item`, the last configuration overrides the previous one due to using the same key. Fix: --- - Differentiate configurations by appending `lineUuid` to the configuration key. - Ensure each product configuration is handled independently when computing included and extra combo items. task-5480195 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#282988 Forward-Port-Of: odoo/odoo#243954
When users choose the withholding-only option in the payment wizard, Odoo now shows only the appropriate miscellaneous journals. This prevents confusion from an automatic journal change that users could not later adjust correctly.
Original PR description
Previously, when the user selected the 'withhold only' option in the payment wizard, the journal was automatically changed to a miscellaneous journal. However, when the user tried to change the journal, no miscellaneous journals were available. With this commit, only miscellaneous journals are available when 'withhold only' is selected. task-6461688 Forward-Port-Of: odoo/odoo#281697
Fixes an issue in the Italian localization where debit carryover from a prior VAT closing could appear in the January monthly VAT report section reserved for credit carryover. This helps companies produce more accurate VAT reports and avoid misclassification in Italian tax reporting.
Original PR description
With a l10n_it company: - Create an invoice for december, create the tax return closing entry for this period. On the monthly VAT Report of january the carryover is declared in section VP9 which is supposed to store credit carry over not debit. opw-6354509 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#279471
Store pickup locations are no longer shown as selectable delivery addresses when customers review or edit their checkout contact details. This prevents confusion and keeps the address list limited to customer-created delivery addresses.
Original PR description
Steps to produce: --- - Install `website_sale_collect` module. - Create and publish a product. - Add it to the cart and proceed to checkout. - Fill in the address and confirm. - Select a `pick-up in…
Steps to produce: --- - Install `website_sale_collect` module. - Create and publish a product. - Add it to the cart and proceed to checkout. - Fill in the address and confirm. - Select a `pick-up in store` delivery method. - Click the edit icon on the contact details. - Confirm without making any changes. Issue: --- - The pick-up point address appears as a selectable delivery address in the contact details list, which it should not. Root cause: --- - When a pick-up point is selected, `set_pickup_location` calls `_address_from_json` ([1]), which creates a child `res.partner` record with `type='delivery'` and sets `pickup_delivery_method_id` to identify it as a pick-up point address. Later, when the user returns to the address page, `_prepare_address_data` calls `_get_delivery_address_domain` ([2]) from `portal`. This method returns all child partners with `type='delivery'` without distinguishing between user-created delivery addresses and the auto-generated pick-up point addresses As a result, the pick-up point address incorrectly appears in the checkout address list. Solution: --- - As specified in [task], partners created through this flow should be archived. However, in the referenced [commit], the `active=False` flag was removed when creating the partner, causing newly created partners to remain active. Override `_get_delivery_address_domain` to exclude pick-up point addresses. Since auto-generated pick-up point addresses always have `pickup_delivery_method_id` set, they are filtered out from the checkout address list, while manually created delivery addresses remain unaffected. [1]https://github.com/odoo/odoo/blob/fb6298e50a7c8ded2800254e8715336eeb37deb5/addons/website_sale_stock/models/res_partner.py#L16-L72 [2]https://github.com/odoo/odoo/blob/fb6298e50a7c8ded2800254e8715336eeb37deb5/addons/portal/models/res_partner.py#L51-L55 [task]: https://www.odoo.com/odoo/project/49/tasks/3645144 [commit]: https://github.com/odoo/odoo/commit/fb74a371407ee19c6b1a3ab9f5a7b314978cb5cb opw-6356778 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#283314 Forward-Port-Of: odoo/odoo#276148
The SMS Marketing screen no longer shows the Insert Field option when a message cannot be edited. This prevents users from triggering an error while viewing campaigns that are already sent or being sent.
Original PR description
Steps to reproduce ---------------------------------------- 1. Install the SMS Marketing module (mass_mailing_sms). 2. Open any SMS Marketing record in the "Sent" or "Sending" stage. 3. Click on the…
Steps to reproduce ---------------------------------------- 1. Install the SMS Marketing module (mass_mailing_sms). 2. Open any SMS Marketing record in the "Sent" or "Sending" stage. 3. Click on the "Insert Field" button. Observation ---------------------------------------- Traceback Occurs: ``` TypeError: Cannot read properties of null (reading 'getRootNode') ``` Issue ---------------------------------------- The SMS widget displays the "Insert Field" button even when the SMS message field is readonly. The button relies on the textarea reference to open the dynamic fields popover, but the textarea is only rendered in editable mode. The readonly behavior of the text field can be seen here: https://github.com/odoo/odoo/blob/ccce9fcc79edcfb1f310b49a16de8235d987b74b/addons/web/static/src/views/fields/text/text_field.xml#L5-L7 However, the SMS widget still renders the "Insert Field" button without checking whether the message field is readonly: https://github.com/odoo/odoo/blob/ccce9fcc79edcfb1f310b49a16de8235d987b/addons/sms/static/src/components/sms_widget/fields_sms_widget.xml#L6 As a result, clicking the button in readonly mode tries to access an unavailable textarea reference to open the dynamic fields popover, causing a traceback. Solution ---------------------------------------- Hide the "Insert Field" button when the SMS message field is readonly, preventing the dynamic fields popover from being opened when the textarea reference is unavailable. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#283446 Forward-Port-Of: odoo/odoo#282845
Clicking a table of contents entry now scrolls the page so the selected heading is easier to see, rather than leaving it barely visible at the edge of the screen. This makes navigation within HTML content feel more reliable and helps users quickly find the section they selected.
Original PR description
When clicking on a title in the TOC, we auto-scroll to that section of the HTML, allowing users to read that part. Since [1], scrollIntoView is replaced to consider top-aligned sticky elements. As a result, instead of scrolling to make it comfortable to read the section, it stops as soon as the title is visible. Unless you are really attentive at the bottom of the screen, it can look like the scrolling did not work. This commit computes the appropriate offset to make the TOC heading more visible after scrolling. [1]: https://github.com/odoo/odoo/commit/f5cf8565e7d09edd3a29fd95537381fb70d75785 Task-6394193 Forward-Port-Of: odoo/odoo#278304
Fixes a calendar display issue where weekday labels could repeat incorrectly for users in time zones with daylight saving changes at midnight. This ensures day, week, and month calendar views show the correct sequence of weekdays, reducing confusion when scheduling around those dates.
Original PR description
Current behaviour: In the Calendar view (day/week/month scale), when the user's timezone observes a DST transition that starts exactly at local midnight (e.g. Africa/Cairo, since 2023), the day…
Current behaviour: In the Calendar view (day/week/month scale), when the user's timezone observes a DST transition that starts exactly at local midnight (e.g. Africa/Cairo, since 2023), the day column right after the transition gets the wrong weekday name, duplicating the previous day's name. For ex. it renders "... THU THU FRI ..." instead of "... THU FRI SAT ...", for the week surrounding April 30th 2027. To fix this we add 1 hour to the Date before reading its weekday/day from it, mirroring the workaround FullCalendar itself adopted for this same bug. It has no effect on any ordinary day (adding 1h to a correct local midnight stays within the same calendar day), and it cannot overshoot into the next day since no real-world DST gap exceeds that margin. Note: This is a known bug (https://github.com/fullcalendar/fullcalendar/issues/7633), fixed in FullCalendar v6.1.17, a major version ahead of the v4.4.0, so the fix can't be applied directly without a full library upgrade. opw-6370140 Forward-Port-Of: odoo/odoo#280253 Forward-Port-Of: odoo/odoo#279343
The profile viewer now displays the profile name even when only one profile is open. This makes it easier for users working across multiple browser tabs to identify the right profile at a glance.
Original PR description
The name of the profile is only displayed when the viewer has multiple profiles open. It's not displayed when opening a single profile. If you have many of them open in different browser tabs, the name would help knowing which is which. ## Before <img width="527" height="77" alt="image" src="https://github.com/user-attachments/assets/26706115-dc99-40af-82b1-29e017051403" /> ## After <img width="527" height="77" alt="image" src="https://github.com/user-attachments/assets/46fd85d9-3558-4b64-8fdf-52bf372f4c65" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#283180
Printer pairing now correctly checks the printer status after an internal method name changed. This helps IoT printer setup work reliably and removes duplicate checks that were no longer needed.
Original PR description
In odoo/odoo#244530, the method `print_status` in the linux printer driver was renamed to `status`, however it was not changed in the connection manager. This commit fixes the issue, and also removes redundant checks for the printer type (as these are already performed in the `status` method). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#283521
Manufacturing orders no longer show unnecessary consumption warnings for service or combo components. This prevents confusing alerts when validating production orders that include non-physical items, since those items are not consumed like goods.
Original PR description
Issue: Consumption Warnings were appearing for services in manufacturing orders, but services are not consumed therefore the warning makes no sense. Steps to reproduce: Create a bill of materials with at least 1 service type component line Create a manufacturing order for that product Validate the manufacturing order Why: Consumption warning was appearing because we have no amount of quantity of products of type service / combo. Since these types are not supposed to have a quantity in the same way goods do, this check does not make sense for products other than goods and therefore we should remove the check for products other than `'consu'` opw-6420932 Forward-Port-Of: odoo/odoo#278745
This fixes an internal database connection cleanup issue when a separate read-only replica database is configured. It helps prevent replica connections from being left open, improving reliability and resource management without changing user-facing workflows.
Original PR description
close_db matched readonly connections against the primary DSN. When db_replica_* differs, those connections were left open. 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#282671
Spreadsheet-related automated tests were adjusted to match recent icon changes. This helps keep quality checks reliable after the spreadsheet update, with no expected impact on daily users.
Original PR description
See https://github.com/odoo/odoo/pull/283915
This fixes a test instability in Peru electronic invoicing caused by small spelling differences from different library versions. It helps keep automated validation reliable across supported Python environments without changing business behavior.
Original PR description
### Issue: `test_invoice_down_payment_with_withholding_tax` fails on RunBot when using `num2words==0.5.10` (Python < 3.12) The expected XML contains `DIECISÉIS` but older versions of `num2words` generate `DIECISEIS` without the accent ### Cause: The accent on `DIECISÉIS` was added in `num2words` PR #443, between versions `0.5.10` and `0.5.13` RunBot uses different versions depending on the Python version: `num2words==0.5.10` for Python < 3.12 (Jammy / Bookworm) `num2words==0.5.13` for Python >= 3.12 ### Steps to reproduce: - Run the test with `num2words==0.5.10` Before the fix, the test fails on the `cbc:Note` comparison runbot-945461 Forward-Port-Of: odoo/enterprise#127356
Adds automated coverage to ensure Italian VAT report carryover values are handled correctly. This helps prevent regressions in tax reporting for Italian localization users.
Original PR description
Add test for https://github.com/odoo/odoo/pull/279471 opw-6354509 Forward-Port-Of: odoo/enterprise#127429
Restaurant preparation display cards now show the assigned course name, such as Main Course, instead of only a course number when course allocation is enabled. This makes kitchen order information clearer and helps staff identify preparation stages more easily.
Original PR description
Before this commit: ====================== Prep cards showed the course index, like T1 - C2, even when course allocation was enabled. After this commit: ==================== Prep cards show the allocated course name, like T1 - Main Course, when course allocation is enabled. Task-6421309 Forward-Port-Of: odoo/enterprise#125744
Odoo now avoids syncing orders for TikTok shops that have not completed authorization. This prevents scheduled order imports from failing when a shop connection is still pending, keeping TikTok sales synchronization stable for authorized shops.
Original PR description
Currently, an error occurs when orders are being fetched from shops with pending authorization. Steps to replicate: - Install `sale_tiktok`. - Open Sales > Configuration > Shops (Under the title…
Currently, an error occurs when orders are being fetched from shops with pending authorization.
Steps to replicate:
- Install `sale_tiktok`.
- Open Sales > Configuration > Shops (Under the title tiktok shops).
- Click `Connect New Shop` > Give values for `App key, App secret, Service ID`.
- Click `Connect Shop & Authorize` and then Return back to Odoo.
- Run the Scheduled Action `TikTok Shop: sync orders`.
Error:
```
File '/home/odoo/src/enterprise/saas-19.4/sale_tiktok/utils.py', line 171, in make_tiktok_api_request
if now > shop.access_token_expire_datetime - timedelta(minutes=5):
TypeError: unsupported operand type(s) for -: 'bool' and 'datetime.timedelta'
ValueError: TypeError('unsupported operand type(s) for -: 'bool' and 'datetime.timedelta'') while evaluating
'model._sync_orders()'
```
Cause:
- Since the shop has not yet been authorized with TikTok, the `access_token_expire_datetime` field is not set. This field is only populated after the shop is successfully authorized (see [this]).
- Later, when the `TikTok Shop: sync orders` cron runs, the flow reaches [here], where we checks whether the access token is expired and needs to be refreshed. At this point, `access_token_expire_datetime` is still False because the shop has not been authorized yet.
Solution:
- The orders should only be fetched from those shops that are authorized with TikTok.
- Used the `access_token` field to determine whether a shop is authorized, as it is only populated after the authorization flow is successfully completed.
[this]: https://github.com/odoo/enterprise/blob/593409ca160863d3e985f3cf5e2aadda1d450b41/sale_tiktok/controllers/onboarding.py#L52-L54
[here]: https://github.com/odoo/enterprise/blob/593409ca160863d3e985f3cf5e2aadda1d450b41/sale_tiktok/utils.py#L171
sentry-7631179329
Forward-Port-Of: odoo/enterprise#127148This fixes an issue where users could not search for Twitter/X accounts by name when adding mentions to a social post. The mention search now uses the correct user lookup behavior, making it easier to compose posts accurately.
Original PR description
Bug === We cannot search user by name when mentioning in a post for Twitter. In cdc2bd4bff93e5081858c4f7e2e08061131f6e2d we changed the endpoint to search users, but in f77c3a673129aeafbd32ded95cd207dd878901e4 we used the method like if it was the old code). Task-6425391 Forward-Port-Of: odoo/enterprise#125803
Opening spreadsheet version history now uses the correct type of database access when contributor details need to be updated. This avoids an unnecessary retry behind the scenes, making the action more reliable and efficient for users.
Original PR description
The get_spreadsheet_history method is marked as readonly, causing RPC requests to use a read-only transaction. However, retrieving the metadata of a document spreadsheet updates its spreadsheet contributors. Opening the version history consequently attempts an UPDATE in a read-only transaction and forces the request to be retried with a read-write cursor. Remove the readonly decorator so the request uses a read-write cursor directly. Task-6176364 Forward-Port-Of: odoo/enterprise#126626