Daily updates from Odoo
Thursday, June 4, 2026
121 changes
20 changes
Resolved issues and error corrections
This update resolves an issue where changes made to form fields within a translation dialog were unexpectedly saved, even if the user didn't click 'OK' to confirm. The fix ensures that changes are only applied when the user explicitly saves the translation, improving data consistency and preventing unintended modifications. This improves the user experience and reduces potential errors.
Original PR description
[FIX] website: stop saving an attribute translation on close Steps to see the issue: - Drop a form on your page - Add a placeholder on one of the inputs - Save your changes, and switch to another language - Start translating - Click on the input with the placeholder - Make some changes to the placeholder, but don't click "Ok" - Close the dialog => The changes are still applied. task-5190459 Forward-Port-Of: odoo/odoo#264052
This update fixes an issue where the cursor position was incorrect after moving content within the HTML editor. Now, when moving a table or paragraph, the cursor automatically adjusts to remain within the newly positioned content, ensuring a smoother and more intuitive editing experience. This improves usability and prevents confusion for users.
Original PR description
#### Description of the issue/feature this PR addresses: - MoveNode restores the cursor at the container end position - After moving a table, the cursor ends outside the table body #### Desired behavior after PR is merged: - Preserve the selection if it was inside the moved node - Otherwise place the cursor at the start of the moved node #### Steps to reproduce: - Create a table in the editor - Move the table using Movenode - Drop the table and check the cursor position - The cursor ends outside the moved table body - Select some text in a paragraph - Move that paragraph using Movenode - The selection is placed at the end of the moved node task-6215743 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267844 Forward-Port-Of: odoo/odoo#264264
This update optimizes the styling of Odoo's Kanban dropdowns, specifically addressing slow CSS performance. By simplifying the CSS rules and adjusting how borders are displayed based on screen size, this change improves the responsiveness and speed of the Kanban interface.
Original PR description
This commit removes several expensive CSS selectors. After reviewing all usages, we found that `.o_kanban_card_manage_settings` always contains `div` elements with `col-*` classes as direct children. We also found that the border behavior depends on the available screen width rather than the bottom sheet itself: it is only needed when the elements are displayed side by side and should be removed when they are stacked vertically. An ´!important´ declaration was also added to compensate for the reduced selector specificity. 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#267979
This update fixes a previous limitation where channel owners without system admin privileges couldn't promote members to admin roles. The change ensures that channel owners can now correctly assign admin access, improving channel management capabilities. This resolves a technical issue impacting channel governance.
Original PR description
`canSetAdmin` was checking the target member role instead of the current user's role. Because of that, a channel owner who was not a system admin could not promote another member to admin. task-6250058 Forward-Port-Of: odoo/odoo#267999 Forward-Port-Of: odoo/odoo#266615
This update fixes an inconsistency in the HTML editor's toolbar. Previously, the toolbar remained active when selecting text within protected blocks like Code or Table of Contents, leading to confusing behavior. Now, the toolbar automatically closes when selecting text within these blocks, ensuring a smoother and more intuitive editing experience.
Original PR description
Problem: The toolbar is disabled when selecting text inside Code or Table of Content blocks, but it remains active when selecting the block itself through the “⋮⋮” handle, leading to inconsistent behavior. Cause: `_updateToolbar` does not check whether `targetedNodes` contains only protected nodes. In such cases, the toolbar should be closed. Solution: When `targetedNodes` contains only protected nodes, prevent the toolbar from opening. Steps to reproduce: - Insert a Table of Content block. - Click on the “⋮⋮” handle while hovering the block. - Observe that the toolbar opens, while it should remain closed. task-6250028 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266661
This update ensures that file uploads initiated through the link popover are immediately canceled when the user discards the popover. Previously, uploads continued in the background even after the discard button was pressed, leading to potential issues with data integrity. This change improves the user experience by preventing unexpected uploads.
Original PR description
**Current behavior before PR:** Steps to reproduce the issue: - Go to Todo, In the network tab switch to "Slow 4G" so that file upload can take few seconds to upload. - Upload a file using link popover. - While the file upload is in progress, hit the discard button of the link popover. - Notice that the upload continues in the background and when it completes successfully, link is inserted. **Desired behavior after PR is merged:** Discarding the link popover during file upload should cancel the upload request and prevent inserting the link. task-6199113 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267695 Forward-Port-Of: odoo/odoo#263463
This update corrects a technical problem affecting how the `pdp_verification_display_state` field is calculated. The change replaces a problematic setting with a new method (`depends_context`) to ensure proper functionality within the partner merge wizard, preventing errors.
Original PR description
The computed field `pdp_verification_display_state` uses the `company_dependent` field. This causes an issue with the partner merge wizard in saas-18.2+. This commit fixes it by using the `depends_context` instead. runbot.build.error-939449 Forward-Port-Of: odoo/odoo#267481
This update resolves an issue where demo mode incorrectly required authentication and two-factor authentication (totp). It also corrects a technical error related to how documents were processed, ensuring proper handling regardless of whether the user is a Peppol User or a PDP. This enhancement improves the stability and usability of the demo environment.
Original PR description
And don't force the totp in demo mode Also, fix the mocking of the send_documents when sending documents with a Peppol User and not a PDP one. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267893 Forward-Port-Of: odoo/odoo#267461
This update corrects a flaw in how Odoo tracks device support status. Previously, changes weren't reliably reflected in the database when a device switched between supported and unsupported states. Now, device status changes are tracked separately, ensuring accurate database updates and preventing issues with device recognition.
Original PR description
When a device is marked unsupported (e.g. FDM after power outage) and becomes supported with the same identifier (e.g. FDM after the client restarts it after the power outage), the changed was not taken into account because we used to track changes in a set of supported + unsupported. We now track changes in supported and unsupported separately to make sure the db is informed of the changes. Forward-Port-Of: odoo/odoo#267967
This fix resolves an issue where creating new survey records would sometimes fail due to an error in how the system handles empty lists. The code now guards against this scenario, ensuring data can be saved correctly. This prevents disruptions to the recruitment process.
Original PR description
To reproduce error. 1) make a new interview record 2) make sure user has interview group but not survey group 3) try to access/make an interview record. convert_to_cache returns none when it is…
To reproduce error.
1) make a new interview record
2) make sure user has interview group but not survey group 3) try to access/make an interview record.
convert_to_cache returns none when it is passed an empty list see link below:
https://github.com/odoo/odoo/blob/b16aaff17a65987c958c3285157ef1e4443e864f/odoo/orm/fields_misc.py#L71
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/saas-19.3/odoo/http/router.py", line 279, in __call__
response = serve_db(request)
^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.3/odoo/http/router.py", line 443, in serve_db
raise _update_served_exception(request, exc)
File "/home/odoo/src/odoo/saas-19.3/odoo/http/router.py", line 441, in serve_db
return retrying(serve_func, env=request.env)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.3/odoo/http/retrying.py", line 52, in retrying
result = func()
^^^^^^
File "/home/odoo/src/odoo/saas-19.3/odoo/http/router.py", line 593, in serve_ir_http
response = request.dispatcher.dispatch(rule.endpoint, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.3/odoo/http/dispatcher.py", line 311, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.3/odoo/addons/base/models/ir_http.py", line 415, in _dispatch
result = endpoint(**request.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.3/odoo/http/routing_map.py", line 207, in route_wrapper
result = endpoint(self, *args, **params_ok)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.3/addons/web/controllers/dataset.py", line 32, in call_kw
return call_kw(request.env[model], method, args, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.3/odoo/service/model.py", line 55, in call_kw
result = method(recs, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.3/addons/web/models/models.py", line 2084, in onchange
snapshot1 = RecordSnapshot(record, fields_spec)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.3/addons/web/models/models.py", line 2170, in __init__
self.fetch(name)
File "/home/odoo/src/odoo/saas-19.3/addons/web/models/models.py", line 2185, in fetch
self[field_name] = self.record[field_name]
~~~~~~~~~~~^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.3/odoo/orm/models.py", line 6130, in __getitem__
return self._fields[key].__get__(self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.3/odoo/orm/fields.py", line 1815, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/saas-19.3/odoo/orm/fields.py", line 1986, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/saas-19.3/addons/mail/models/mail_thread.py", line 502, in _compute_field_value
return super()._compute_field_value(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.3/odoo/orm/models.py", line 4340, in _compute_field_value
determine(field.compute, self)
File "/home/odoo/src/odoo/saas-19.3/odoo/orm/fields.py", line 82, in determine
return needle(*args)
^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.3/addons/hr_recruitment_survey/models/survey_survey.py", line 19, in _compute_allowed_survey_types
survey.allowed_survey_types = [*survey.allowed_survey_types, 'recruitment']
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: Value after * must be an iterable, not bool
```
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-prThis update corrects a technical issue where message authors were sometimes incorrectly identified. The fix ensures that message authors are accurately linked to either partners or guests based on the message's model, improving the reliability of communication tracking. This resolves a potential inconsistency in how message authorship is recorded.
Original PR description
A message's author is identified by one of two fields depending on its model: `author_id` (for partners) or `author_guest_id` (for guests). Previously in `changeThread`, the value of `thread.effectiveSelf` (which can be either a Partner or a Guest) was provided as the `author_id` regardless of its actual model. This commit explicitly uses `store.self_partner` as the `author_id` and `store.self_guest` as the `author_guest_id` to resolve the occasional mismatch. Forward-Port-Of: odoo/odoo#267828 Forward-Port-Of: odoo/odoo#267464
This update resolves an issue where a misleading error was triggered when setting intrastat codes on product templates. The fix ensures the error only appears when creating templates with dynamic attributes and no variants, aligning with how intrastat codes are correctly stored on product variants. This improves data accuracy and prevents unnecessary alerts.
Original PR description
Problem: When saving an intrastat code on a product template with no variants, an error should be raised because intrastat codes are stored on the product variants. However, the error gets raised when creating a product template with intrastat code set because the variants get created after the product template is created, so it doesn't find any variant although the default variant will be created right after saving the product template. Solution: The constraint should only be triggered when saving the intrastat code on a product template with dynamic attributes and no variants. Since dynamic attributes are the only ones that can lead to a product template with no variants, we can check if the product template has dynamic attributes and no variants before raising the error. Forward-Port-Of: odoo/enterprise#118986
This update fixes an issue where broken link trackers were appearing in the system. The changes now require valid alphanumeric codes for link trackers and disable editing the target link after creation, preventing further problems and ensuring data integrity.
Original PR description
1. Remove the possibility to create link tracker with an empty code. Empty code tracker do not work, but still appear in the tracker list. Only accept alphanumerical chars in the tracker code. 2. Set the target link input as disabled after generating the tracker, since editing the target link at this point would have no impact. task-4531974 Forward-Port-Of: odoo/odoo#266733
This update resolves an issue where PDF documents received via email were incorrectly displayed with a duplicate iframe preview. The fix ensures that the document preview accurately shows the PDF content, addressing a potential confusion for users. This was previously addressed in 19.0 and is now reinforced.
Original PR description
**Steps to reproduce:** - Install documents_account - Set up alias to catch incoming mails - Receive a mail with xml attachement which can be previewed as pdf - Go to Documents app - Click on the…
**Steps to reproduce:** - Install documents_account - Set up alias to catch incoming mails - Receive a mail with xml attachement which can be previewed as pdf - Go to Documents app - Click on the document preview - Preview is split in two iframes, both with the same content (pdf) **Issue:** Due to the `isPdf` patch the attachment can match multiple types for the preview (pdf and text) as both getter return `true`. ``` <iframe t-if="state.file.isPdf" ... <iframe t-if="state.file.isText" ... ``` It also seems that xml received by mail are imported as text, which is why the issue doesn't happen when manually uploading the same xml file. **Fix:** Ensure that if the document is matching `isPdf`, it doesn't trigger the second iframe with `isText`. Also it seems fixed in 19.0 as the text iframe is replaced by this xpath: `<xpath expr="//iframe[@t-if='state.file.isText']" position="replace">` which was added for https://github.com/odoo/enterprise/commit/de614ee5e9a087d49939c65c0118ae6164c7b31b related patch: https://github.com/odoo/enterprise/commit/ffcdd2275c8bf564e15151ccbcaf3965ed968450 opw-6018536 Forward-Port-Of: odoo/enterprise#118863 Forward-Port-Of: odoo/enterprise#112041
This update fixes an issue where tracking information in emails was displayed in the wrong order. The change reverses the order of tracking values to match how they are stored in the database, ensuring that the most important tracking details are shown first. This improves the clarity and accuracy of email notifications.
Original PR description
Tracking values are given in a reverse ordering, as DB model reads them by id DESC. Most important one is given last, see 'mail_tracking' module. We therefore have to reverse the list given to the QWeb template.
This update addresses a potential issue with how Odoo updates modules, specifically related to button actions. By adding a short timeout and a rollback mechanism, the system is now more reliable when updating modules and handling user error translations, ensuring a smoother experience for users.
Original PR description
Add a small lock timeout when updating modules just like it is done in master (19.3). Also add rollback so that translation of user errors work (in case we need to fetch the language from the database). runbot-234930 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267698
This update corrects a technical problem that was only appearing in the community version of Odoo's stock module. The issue involved incorrect links to stock packages, which has now been resolved. This ensures accurate stock tracking and reporting.
Original PR description
Reproducible only in community **Observation** outermost_result_package_id is a enterprise variable in stock_barcode: https://github.com/odoo/enterprise/blob/c5bbcaeed513817fdda1f3f42f4c9b2440264174/stock_barcode/models/stock_move_line.py#L27 It's computed from result_package_id.outermost_package_id: https://github.com/odoo/enterprise/blob/c5bbcaeed513817fdda1f3f42f4c9b2440264174/stock_barcode/models/stock_move_line.py#L29-L33 That variable is available in stock community : https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock/models/stock_package.py#L48 runbot-241085 Forward-Port-Of: odoo/odoo#267653
This update disables the '@' mention feature for visitors in live chat conversations. Previously, visitors could trigger irrelevant suggestions, creating unnecessary noise. This change ensures a cleaner and more focused chat experience for all users.
Original PR description
**Description of the issue this PR addresses:** ---------------------------------------------- Visitors in livechat can trigger partner mention suggestions by typing the @ delimiter in the composer.…
**Description of the issue this PR addresses:** ---------------------------------------------- Visitors in livechat can trigger partner mention suggestions by typing the @ delimiter in the composer. However, visitors can only mention themselves or odoobot, which does not provide meaningful functionality in the context of a livechat conversation. **Current behavior before PR:** ---------------------------------------------- - Visitors can type @ in the livechat composer and trigger partner mention suggestions. - The suggestions only include the visitor themselves or odoobot. **Desired behavior after PR is merged:** ---------------------------------------------- - The @ delimiter is disabled for visitors in livechat threads. - Partner mention suggestions are no longer triggered for visitors. - Internal users (operators) can still use @ mentions normally. Task-5119068 ---------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267788 Forward-Port-Of: odoo/odoo#253551
A recent test within the HR Holidays module was failing due to an error in how it checked for related records. This commit corrected the test by using a different method to identify records, preventing installation issues when other modules are installed alongside HR Holidays. This ensures smoother module installations and prevents potential disruptions.
Original PR description
Before this commit, the line https://github.com/odoo/odoo/blob/saas-19.1/addons/hr_holidays/tests/test_holidays_mail.py#L69 used `.id` on a many to many recordset which failed when the recordset had multiple records. This test led to an error when installing other modules with demo data like `test_l10n_be_hr_payroll_account` and the test was run with demo data. This commit uses the `in` operator instead of `==` and avoids `employee_ids.id` to avoid the error. Runbot error: https://runbot.odoo.com/odoo/error/241106 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266677
This update fixes a visual issue where Polish and Vietnamese characters displayed inconsistently on Android Edge browsers. The fix ensures proper font rendering by providing additional font subsets to browsers that don't fully support Unicode ranges, maintaining consistent character appearance across different devices and browsers.
Original PR description
Scenario: - paste "język việt" (polish + vietnamese) in a page - change website font to not be "Noto Sans", for example: Raleway - open the page on Edge Browser on Android Result: polish and…
Scenario: - paste "język việt" (polish + vietnamese) in a page - change website font to not be "Noto Sans", for example: Raleway - open the page on Edge Browser on Android Result: polish and vietnamese characters are using different font and are visually different than latin character. Cause: google fonts is serving for nearly all browsers font configuration with woff2 files and unicode-range so the user only loads the part of the font that will be used on the website. For Edge browser on android, based on the user-agent chrome is serving only a TTF file without unicode-range because it is thinking that unicode-range is not supported. These files only contain basic latin characters, so extended latin and vietnamese characters are being rendered with fallback "Odoo Unicode Support Noto" that has a different weight and style for the same weight. Fix: For the browser not supporting unicode-range (desktop edge before 2020, Edge on android, …), in addition to latin we ask google fonts to provide([1]) latin-extended and vietnamese subsets in TTF/WOFF files if available. For other subset (hebrew, arabic, cyrillic, …) the intent is to fallback on "Odoo Unicode Support Noto" since they should usually not be mixed with latin characters. Note: Edge on android in reality support unicode range, so this would be solved if google fonts just served the unicode range font configuration for that user-agent. [1]: https://developers.google.com/fonts/docs/getting_started#specifying_script_subsets opw-4642242 Forward-Port-Of: odoo/odoo#267798
18 changes
Resolved issues and error corrections
This update optimizes the styling of Odoo's Kanban dropdowns, specifically addressing slow CSS performance. By simplifying the CSS selectors used, the system now loads faster and responds more efficiently, leading to a smoother user experience.
Original PR description
This commit removes several expensive CSS selectors. After reviewing all usages, we found that `.o_kanban_card_manage_settings` always contains `div` elements with `col-*` classes as direct children. We also found that the border behavior depends on the available screen width rather than the bottom sheet itself: it is only needed when the elements are displayed side by side and should be removed when they are stacked vertically. An ´!important´ declaration was also added to compensate for the reduced selector specificity. 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#267979
This update ensures that the subject displayed in the chatter reflects any changes made to the message subject within the composer. Previously, updates to the composer's subject weren't automatically reflected in the chatter, leading to inconsistencies. This improvement provides a more accurate and up-to-date view of message subjects.
Original PR description
If the user updates the subject in the composer, the suggested subject in the chatter should reflect the latest message. task-5944635
This update fixes an inconsistency in the HTML editor's toolbar. Previously, the toolbar remained active when selecting text within protected blocks like Code or Table of Contents, but now it's correctly disabled in these scenarios, ensuring a more reliable and intuitive user experience. This improves the editor's stability and usability.
Original PR description
Problem: The toolbar is disabled when selecting text inside Code or Table of Content blocks, but it remains active when selecting the block itself through the “⋮⋮” handle, leading to inconsistent behavior. Cause: `_updateToolbar` does not check whether `targetedNodes` contains only protected nodes. In such cases, the toolbar should be closed. Solution: When `targetedNodes` contains only protected nodes, prevent the toolbar from opening. Steps to reproduce: - Insert a Table of Content block. - Click on the “⋮⋮” handle while hovering the block. - Observe that the toolbar opens, while it should remain closed. task-6250028 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266661
This update resolves an issue where changes to attribute translations within a dialog were unexpectedly saved, even after the dialog was closed. The fix ensures that modifications are only applied when the user explicitly confirms their changes, improving data consistency and preventing unintended updates. This improves the user experience and data integrity.
Original PR description
[FIX] website: stop saving an attribute translation on close Steps to see the issue: - Drop a form on your page - Add a placeholder on one of the inputs - Save your changes, and switch to another language - Start translating - Click on the input with the placeholder - Make some changes to the placeholder, but don't click "Ok" - Close the dialog => The changes are still applied. task-5190459 Forward-Port-Of: odoo/odoo#264052
This update corrects a technical problem affecting how the `pdp_verification_display_state` field is calculated. The change replaces an outdated method with a more reliable approach, ensuring proper functionality within the partner merge wizard. This resolves a previous error that impacted the system's ability to correctly process partner data.
Original PR description
The computed field `pdp_verification_display_state` uses the `company_dependent` field. This causes an issue with the partner merge wizard in saas-18.2+. This commit fixes it by using the `depends_context` instead. runbot.build.error-939449 Forward-Port-Of: odoo/odoo#267481
This update resolves an issue preventing proper demo mode operation by bypassing unnecessary authentication steps and removing forced two-factor authentication. Additionally, the system now correctly handles document sending for both Peppol Users and PDPs, ensuring accurate data processing during demonstrations. This improves the reliability and usability of the French PDP demo environment.
Original PR description
And don't force the totp in demo mode Also, fix the mocking of the send_documents when sending documents with a Peppol User and not a PDP one. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267893 Forward-Port-Of: odoo/odoo#267461
This update addresses a potential issue with how Odoo updates its modules. By implementing a small timeout and rollback mechanism, the system now handles module updates more reliably, preventing disruptions and ensuring translations for user error messages are correctly applied. This enhances the overall stability and user experience.
Original PR description
Add a small lock timeout when updating modules just like it is done in master (19.3). Also add rollback so that translation of user errors work (in case we need to fetch the language from the database). runbot-234930 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267698
This update resolves an issue preventing refunds in the Colombian Point of Sale (PoS) system. The fix corrects outdated code referencing an older function name, ensuring refunds can now be processed without errors. This improves the functionality for Colombian businesses using the Odoo Enterprise system.
Original PR description
**Steps to reproduce:** - Setup a columbian company, DIAN should be in demo mode - Go to the PoS and make a sale with a columbian customer - Refund it - A traceback appears **Why the fix:** Some legacy code was left untouched when we changed the old **get_partner()** to the new **getPartner()** so we got a traceback as this function does not exist anymore. We also change the **set_partner(partner)** to **setPartner(partner)** as it was also forgotten. opw-6231856 Forward-Port-Of: odoo/enterprise#118478 Forward-Port-Of: odoo/enterprise#118054
This update resolves an issue where message authors were incorrectly identified, leading to potential inconsistencies in communication records. The change ensures that the correct 'author_id' or 'author_guest_id' is used based on the message's model, improving the accuracy of message attribution.
Original PR description
A message's author is identified by one of two fields depending on its model: `author_id` (for partners) or `author_guest_id` (for guests). Previously in `changeThread`, the value of `thread.effectiveSelf` (which can be either a Partner or a Guest) was provided as the `author_id` regardless of its actual model. This commit explicitly uses `store.self_partner` as the `author_id` and `store.self_guest` as the `author_guest_id` to resolve the occasional mismatch. Forward-Port-Of: odoo/odoo#267828 Forward-Port-Of: odoo/odoo#267464
This update ensures that errors related to intrastat codes are only triggered when creating product templates with dynamic attributes and no variants. Previously, the validation was incorrectly raised, causing issues when setting intrastat codes. This change improves data accuracy and prevents unnecessary errors during product template creation.
Original PR description
Problem: When saving an intrastat code on a product template with no variants, an error should be raised because intrastat codes are stored on the product variants. However, the error gets raised when creating a product template with intrastat code set because the variants get created after the product template is created, so it doesn't find any variant although the default variant will be created right after saving the product template. Solution: The constraint should only be triggered when saving the intrastat code on a product template with dynamic attributes and no variants. Since dynamic attributes are the only ones that can lead to a product template with no variants, we can check if the product template has dynamic attributes and no variants before raising the error. Forward-Port-Of: odoo/enterprise#118986
This update adds a new keyboard shortcut (Alt+Shift+R) to quickly open the timesheet systray. This streamlines the process for employees to record their time, reducing the need to navigate through menus. This change improves user efficiency and ease of use.
Original PR description
This commit adds an `ALT + SHIFT + R` shortcut to open the timesheet systray. task-6197777
This pull request addresses a bug that was only appearing in the community version of Odoo's stock module. The issue stemmed from an inconsistent link to package information, which has now been corrected. This ensures accurate stock barcode generation across all Odoo environments.
Original PR description
Reproducible only in community **Observation** outermost_result_package_id is a enterprise variable in stock_barcode: https://github.com/odoo/enterprise/blob/c5bbcaeed513817fdda1f3f42f4c9b2440264174/stock_barcode/models/stock_move_line.py#L27 It's computed from result_package_id.outermost_package_id: https://github.com/odoo/enterprise/blob/c5bbcaeed513817fdda1f3f42f4c9b2440264174/stock_barcode/models/stock_move_line.py#L29-L33 That variable is available in stock community : https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock/models/stock_package.py#L48 runbot-241085 Forward-Port-Of: odoo/odoo#267653
This update modifies how global discounts are handled in our invoices to align with UBL (Universal Business Language) standards. Previously, discounts were represented as negative invoice lines, which is now changed to 'allowances'. This ensures our invoices are correctly formatted for international trade and compliance.
Original PR description
Export global discounts as Allowances instead of negative invoice lines to comply with UBL specifications. task-5900496 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267435 Forward-Port-Of: odoo/odoo#261029
This update fixes an issue where the project template dropdown in demo mode displayed poorly, with cramped spacing and text touching the edges of the container. The fix removes a styling element that caused this, ensuring a cleaner and more readable experience for all users, regardless of their user role.
Original PR description
Steps to reproduce: == - Login as demo/onboarding user - Open Project app - Click on New - Observe the template dropdown list Issue: == The template dropdown items are rendered with collapsed row height and poor vertical spacing in demo mode, making the list hard to read. Cause: == The template dropdown items utilized the `pe-0` utility class, which removed the padding at the end of the element. For non-admin users this caused the template name to touch the right edge of the container. Fix: == Removed the `pe-0` from the `DropdownItem` to restore standard right-side padding, and ensure consistent and readable row heights for both Admin and Demo users. task-5338191 Forward-Port-Of: odoo/odoo#242983
This update disables the '@' mention feature for visitors in live chat conversations. Previously, visitors could trigger irrelevant suggestions, creating unnecessary noise. This change ensures a cleaner and more focused chat experience for all users.
Original PR description
**Description of the issue this PR addresses:** ---------------------------------------------- Visitors in livechat can trigger partner mention suggestions by typing the @ delimiter in the composer.…
**Description of the issue this PR addresses:** ---------------------------------------------- Visitors in livechat can trigger partner mention suggestions by typing the @ delimiter in the composer. However, visitors can only mention themselves or odoobot, which does not provide meaningful functionality in the context of a livechat conversation. **Current behavior before PR:** ---------------------------------------------- - Visitors can type @ in the livechat composer and trigger partner mention suggestions. - The suggestions only include the visitor themselves or odoobot. **Desired behavior after PR is merged:** ---------------------------------------------- - The @ delimiter is disabled for visitors in livechat threads. - Partner mention suggestions are no longer triggered for visitors. - Internal users (operators) can still use @ mentions normally. Task-5119068 ---------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267788 Forward-Port-Of: odoo/odoo#253551
This update fixes an issue where a recurring activity was being unnecessarily recreated after being marked as 'done'. By adding a check to ensure the activity hasn't already been completed, we prevent redundant tasks and improve the efficiency of our fleet management system. This ensures accurate scheduling and reduces potential errors.
Original PR description
When a next activity is set to done, the record is archived. So once the next activity set on the contract is set to done, the cron will re-create it the next day as it won't see it. So we add active_test=False, to be sure that one has not already been set to done --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update optimizes the website's performance by replacing a complex selector with a simpler one. This change reduces the time it takes for the website to recalculate styles, particularly when users are interacting with large tables or resizing the window. Ultimately, this results in a faster and more responsive user experience.
Original PR description
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#268106 Forward-Port-Of: odoo/odoo#267969
This update fixes a visual issue where Polish and Vietnamese characters displayed inconsistently on Android Edge browsers. The fix ensures proper font rendering by providing additional font subsets to browsers that don't support Unicode ranges, maintaining consistent character appearance across different devices and browsers.
Original PR description
Scenario: - paste "język việt" (polish + vietnamese) in a page - change website font to not be "Noto Sans", for example: Raleway - open the page on Edge Browser on Android Result: polish and…
Scenario: - paste "język việt" (polish + vietnamese) in a page - change website font to not be "Noto Sans", for example: Raleway - open the page on Edge Browser on Android Result: polish and vietnamese characters are using different font and are visually different than latin character. Cause: google fonts is serving for nearly all browsers font configuration with woff2 files and unicode-range so the user only loads the part of the font that will be used on the website. For Edge browser on android, based on the user-agent chrome is serving only a TTF file without unicode-range because it is thinking that unicode-range is not supported. These files only contain basic latin characters, so extended latin and vietnamese characters are being rendered with fallback "Odoo Unicode Support Noto" that has a different weight and style for the same weight. Fix: For the browser not supporting unicode-range (desktop edge before 2020, Edge on android, …), in addition to latin we ask google fonts to provide([1]) latin-extended and vietnamese subsets in TTF/WOFF files if available. For other subset (hebrew, arabic, cyrillic, …) the intent is to fallback on "Odoo Unicode Support Noto" since they should usually not be mixed with latin characters. Note: Edge on android in reality support unicode range, so this would be solved if google fonts just served the unicode range font configuration for that user-agent. [1]: https://developers.google.com/fonts/docs/getting_started#specifying_script_subsets opw-4642242 Forward-Port-Of: odoo/odoo#267798
19 changes
Resolved issues and error corrections
This update fixes a technical problem in Odoo related to how ordered sets are copied in Python 3.14. The change ensures that the set copy operation is performed reliably, preventing errors that could impact data consistency. This improves the stability of the system.
Original PR description
In Python 3.14, iterating over weak references (like `transaction.envs`) can trigger a `RuntimeError: dictionary changed size during iteration`. This happens mostly because the Garbage Collector can remove a weakref while `OrderedSet.copy()` is rebuilding the set via `dict.fromkeys()`. Instead of re-initializing the set by iterating over its elements, we now directly use the dictionary's native `.copy()` method. This atomic operation prevents the GC from modifying the size of the underlying `_map` during the copy. Forward-Port-Of: odoo/odoo#267947
This update ensures all date displays in the Point of Sale module consistently use Odoo's standard date format. Previously, receipts and reports used device-specific date formats, leading to potential inconsistencies. This change improves clarity and accuracy for users.
Original PR description
Why this commit: --- There are two instances in version 17.0 where dates use toLocaleString(), which relies on the device's local format instead of the Odoo-configured format. Since Odoo already…
Why this commit: --- There are two instances in version 17.0 where dates use toLocaleString(), which relies on the device's local format instead of the Odoo-configured format. Since Odoo already defines a standard date format, all toLocaleString() usages in pos should be replaced to ensure consistency. Starting from version 17.0, cash in/out receipts and the sales report use the local device time format. This commit updates those references and aligns them with the Odoo-configured date format. During forwardporting the fix in version 19.0 needs to be added to [base.js](https://github.com/odoo/odoo/blob/0352c5e8543b75083cf555c3d5b4f164f949b465/addons/point_of_sale/static/src/app/models/related_models/base.js#L64-L69). As formatDateOrTime function is used in the [reciept header](https://github.com/odoo/odoo/blob/0352c5e8543b75083cf555c3d5b4f164f949b465/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.xml#L13) printing date on all reciepts. After this commit: --- <img width="947" height="982" alt="image" src="https://github.com/user-attachments/assets/2d9e4199-75dd-40ea-aeb1-27401c9022f3" /> All date references consistently use the Odoo-configured date format. OPW: 6087341 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266770 Forward-Port-Of: odoo/odoo#259112
This update fixes an issue where the cursor position was incorrect after moving content within the HTML editor. Now, when moving a table or paragraph, the cursor automatically adjusts to the beginning of the moved content, preserving the user's selection and ensuring a smoother editing experience.
Original PR description
#### Description of the issue/feature this PR addresses: - MoveNode restores the cursor at the container end position - After moving a table, the cursor ends outside the table body #### Desired behavior after PR is merged: - Preserve the selection if it was inside the moved node - Otherwise place the cursor at the start of the moved node #### Steps to reproduce: - Create a table in the editor - Move the table using Movenode - Drop the table and check the cursor position - The cursor ends outside the moved table body - Select some text in a paragraph - Move that paragraph using Movenode - The selection is placed at the end of the moved node task-6215743 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267549 Forward-Port-Of: odoo/odoo#264264
This update optimizes the styling of Kanban dropdowns, specifically addressing slow loading times. By simplifying the CSS, we've significantly improved the responsiveness and speed of this key feature. This change focuses on performance and user experience.
Original PR description
This commit removes several expensive CSS selectors. After reviewing all usages, we found that `.o_kanban_card_manage_settings` always contains `div` elements with `col-*` classes as direct children. We also found that the border behavior depends on the available screen width rather than the bottom sheet itself: it is only needed when the elements are displayed side by side and should be removed when they are stacked vertically. An ´!important´ declaration was also added to compensate for the reduced selector specificity. 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#267979
This update optimizes the website's styling process, making it faster and more efficient. By switching from a complex selector to a simpler class on the body, the system now recalculates styles more quickly, particularly when dealing with large tables or during website resizing. This results in a smoother user experience.
Original PR description
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#267969
This update resolves an issue where the HTML editor toolbar remained active when selecting text within Code or Table of Content blocks. The fix ensures the toolbar is disabled when selecting protected content, providing a more consistent and intuitive user experience. This improves editor stability and usability.
Original PR description
Problem: The toolbar is disabled when selecting text inside Code or Table of Content blocks, but it remains active when selecting the block itself through the “⋮⋮” handle, leading to inconsistent behavior. Cause: `_updateToolbar` does not check whether `targetedNodes` contains only protected nodes. In such cases, the toolbar should be closed. Solution: When `targetedNodes` contains only protected nodes, prevent the toolbar from opening. Steps to reproduce: - Insert a Table of Content block. - Click on the “⋮⋮” handle while hovering the block. - Observe that the toolbar opens, while it should remain closed. task-6250028 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266661
This update prevents unwanted translation changes from being saved to the system when a translation dialog is closed without confirming the updates. Previously, edits made to placeholder text within the dialog would persist across language selections. This ensures data consistency and prevents unexpected behavior for users.
Original PR description
[FIX] website: stop saving an attribute translation on close Steps to see the issue: - Drop a form on your page - Add a placeholder on one of the inputs - Save your changes, and switch to another language - Start translating - Click on the input with the placeholder - Make some changes to the placeholder, but don't click "Ok" - Close the dialog => The changes are still applied. task-5190459 Forward-Port-Of: odoo/odoo#264052
This update resolves an issue where negative line items in Mexican CFDI invoices were incorrectly distributed. The change addresses a conflict introduced by new features and removes a previous check that was no longer relevant. This ensures accurate CFDI invoice generation.
Original PR description
In MX CFDI, negative lines are not allowed so they are distributed over other lines. But because this PR introduces some other `special_type` like `global_discount` and `down_payment`, it becomes useless to check `base_line['special_type'] == False`. Fix for https://github.com/odoo/odoo/pull/267435 task-5900496 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/enterprise#119254
This update corrects a technical problem affecting how the `pdp_verification_display_state` field is calculated. The change replaces a problematic setting with a new method, ensuring proper functionality within the partner merge wizard and preventing potential errors. This ensures accurate data processing for French-specific features.
Original PR description
The computed field `pdp_verification_display_state` uses the `company_dependent` field. This causes an issue with the partner merge wizard in saas-18.2+. This commit fixes it by using the `depends_context` instead. runbot.build.error-939449 Forward-Port-Of: odoo/odoo#267481
This update addresses a minor issue with how Odoo updates modules, resulting in faster and more reliable updates. The change mirrors a recent update in the main Odoo version (19.3) and includes a rollback mechanism to ensure correct translation of user error messages. This improves the overall user experience and stability.
Original PR description
Add a small lock timeout when updating modules just like it is done in master (19.3). Also add rollback so that translation of user errors work (in case we need to fetch the language from the database). runbot-234930 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267698
This update resolves an issue where Mollie payments failed when customers didn't provide a fully populated billing address. Mollie now requires all necessary address fields (street, postal code, city, and country) to process payments, ensuring compliance with Mollie's requirements and preventing payment failures.
Original PR description
Steps to reproduce: 1. Setup a Mollie online payment method. 2. Make a payment with a customer that has an incomplete* billing address. Expected behaviour: The payment request is initiated. Actual behaviour: Mollie rejects the payment request. *: Mollie will either accept no billing address, or a full address (must include street, postal code, city and country). If only some of these fields are present, Mollie will reject the payment request. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a visual issue where alert content was misaligned within the Odoo portal. The change was a result of a previous alignment adjustment, and the original styling causing the misalignment has been removed. This ensures alerts display correctly for all users.
Original PR description
The alert content is misaligned these changes are side effects of commit[1], the `h5` and `p` in the alert have margin that creates whitespace in the alert. Commit[2] addressed a misalignment issue and alignment issue due to nested `row` but these became irrelevant with commit[1]. This is why we remove the styling. task-5262108 [1]: odoo/odoo@513931a5e540f22f37e317f80fd131701cbbc8f0 [2]: odoo/odoo@d64dbaadcb1bef27d89a89e9d42bdb38890c73e0 | Before | After | |--------|--------| | <img width="1029" height="523" alt="image" src="https://github.com/user-attachments/assets/ff3f827b-652a-4a84-ad7e-205200cf3256" />| <img width="1022" height="486" alt="image" src="https://github.com/user-attachments/assets/b86163d8-bedd-4cb6-a950-ba36a6b401ee" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a flaw in the interval inversion function, ensuring accurate results across a wider range of scenarios. The fix addresses inconsistencies in how intervals were handled, particularly at the edges of the specified limits. This improves the reliability of calculations related to time ranges and date intervals.
Original PR description
The [commit] introduced the method for inverting the interval inside the given limits. The method was failing for the following edge cases: ```python >>> invert_intervals([(1, 2), (4, 5)], 0, 10) result - [(2, 4), (5, 10)] expected - [(0, 1), (2, 4), (5, 10)]? >>> invert_intervals([(-2, -1)], 0, 10) result - [(0, 10)] expected - same >>> invert_intervals([(11, 12)], 0, 10) result - [] expected - [(0, 10)] >>> invert_intervals([(-1, 1), (2, 5), (8, 12)], 0, 10) result - [(1, 2), (5, 8)] expected - same >>> invert_intervals([(2, 5), (8, 12)], 0, 10) result - [(5, 8)] expected - [(0, 2), (5, 8)] >>> invert_intervals([(2, 5), (11, 12)], 0, 10) result - [] expected - [(0, 2), (5, 10)] ``` This commit fixes the function to correctly handle all the cases. The test cases are also added to test all the edge cases. [commit]: https://github.com/odoo/enterprise/commit/53450065be0c3ec9d648d4fd39ec3a9a912bd06c Forward-Port-Of: odoo/odoo#267917
This update corrects a technical problem in the stock barcode module that was only reproducible within the community version of Odoo. The fix ensures accurate linking between stock packages, preventing errors related to unavailable links. This improves the reliability of barcode scanning and product tracking.
Original PR description
Reproducible only in community **Observation** outermost_result_package_id is a enterprise variable in stock_barcode: https://github.com/odoo/enterprise/blob/c5bbcaeed513817fdda1f3f42f4c9b2440264174/stock_barcode/models/stock_move_line.py#L27 It's computed from result_package_id.outermost_package_id: https://github.com/odoo/enterprise/blob/c5bbcaeed513817fdda1f3f42f4c9b2440264174/stock_barcode/models/stock_move_line.py#L29-L33 That variable is available in stock community : https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock/models/stock_package.py#L48 runbot-241085 Forward-Port-Of: odoo/odoo#267653
This update fixes an issue where excessively long addresses during credit card payments via Authorize.net would cause errors. The system now automatically truncates address fields to comply with the Authorize.net API's length restrictions, ensuring smoother payment processing. This improves payment reliability and prevents potential transaction failures.
Original PR description
Steps to reproduce: - install payment_authorize module; - complete a credit card payment using Authorize.net with more than 60 characters on any other field than first name, last name or company; - confirm the payment. Issue: An error message appears. Cause: The Authorize.net API define the max length of information. It is possible that some information exceeds the maximum length. (https://apitest.authorize.net/xml/v1/schema/AnetApiSchema.xsd) Solution: Truncate information if the number of character is too large. opw-6141441 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262154
This update fixes a reporting issue where service sales from European companies to Northern Ireland were incorrectly included in the EC Sales List report. The change ensures that only goods and triangular transactions are reported, aligning with regulations. The update was specifically tested and implemented for the Belgium localization.
Original PR description
…in EC Sales List The services sales done from a european company to a Northern Ireland company should not be included in the EC Sales List Report. It should however be the case for goods and triangular transactions. test is added in Belgium localization because only localizations have handlers using tax tags instead of taxes, and services/goods/triangular sales distinction can be made with these. task-6007931 Forward-Port-Of: odoo/enterprise#117754 Forward-Port-Of: odoo/enterprise#110007
This update resolves an issue where setting a non-numeric value for the 'next check number' in the accounting module would cause an error. The change ensures the system validates the input as a number before attempting conversion, preventing the error and allowing users to correctly set check number sequences.
Original PR description
Currently, an error occurs when a user sets a non-numeric value as the journal's next check number. **Steps to Reproduce:** - Install the `account_check_printing` module with demo data. - Go to…
Currently, an error occurs when a user sets a non-numeric value as the journal's next check number. **Steps to Reproduce:** - Install the `account_check_printing` module with demo data. - Go to `Invoicing` > `Configuration` > `Accounting` > `Journals`. - Open the `bank journal`. - In the `Outgoing Payments` tab > Enable `Manual Numbering`. - Set the `next check number` to a `non-numeric` value `(e.g. FA1234)` and `save`. `ValueError: invalid literal for int() with base 10: 'FA1234'` After [this commit], the next check number is converted to an integer without first validating that it contains only numeric characters [1]. Since the value can be non-numeric, converting it directly to an integer raises the error. This commit ensures that the next check number is converted to an integer only after verifying that it contains numeric characters only. [this commit]: https://github.com/odoo/odoo/commit/cc2004404462ecb523f7877569ce6a06b05341b4 [1]- https://github.com/odoo/odoo/blob/00dd75f345d7f5ddb04cecf52eca07e5a22c7d3c/addons/account_check_printing/models/account_journal.py#L57-L61 sentry-7498755988 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266280
This update resolves an issue where Instagram videos wouldn't display correctly as background images in Odoo's website builder. The problem stemmed from an unnecessary addition of a URL parameter that Instagram's code rejected. This change removes that addition, ensuring Instagram videos now function as expected.
Original PR description
Steps to reproduce: =================== 1. Edit a page, add a Cover/Banner block. 2. Set its background to a video, paste an Instagram URL 3. Save and open the published page. => Instagram embed is…
Steps to reproduce: =================== 1. Edit a page, add a Cover/Banner block. 2. Set its background to a video, paste an Instagram URL 3. Save and open the published page. => Instagram embed is broken (iframe shows nothing / error). Cause: ======= Background videos broke for Instagram because the BackgroundVideo interaction unconditionally appends "&enablejsapi=1" to the iframe URL on start. Instagram embed URLs have no query string (`//www.instagram.com/p/<id>/embed/`), so the append produces `//www.instagram.com/p/<id>/embed/&enablejsapi=1` the `&` ends up in the path and Instagram refuses to render. The unconditional append is itself a regression from the public-widget → interaction refactor in [2]. The original code in 18.0 only added the param when `isYoutubeVideo && isMobileEnv`, as a workaround for old YouTube records that lacked it. Since [1], `enablejsapi=1` is already injected server-side in `html_editor/tools.py` / `web_editor/tools.py` when building YouTube autoplay embed URLs, so any YouTube background saved via the media dialog from 17.0 onward already has it. The JS append is redundant for YouTube and harmful for Instagram. Solution: ========= remove the unconditional append of `&enablejsapi=1` in the BackgroundVideo interaction [1]: https://github.com/odoo/odoo/commit/ca60af9dadc25adbc9eb159870ce1233a2886492 [2]: https://github.com/odoo/odoo/commit/b9b3a605e0f4 opw-6233081 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267016
This update corrects a technical issue preventing invoices with long product names, descriptions, or notes from being correctly processed for Romanian E-Factura submissions. The system now enforces character limits (100, 200, and 300 characters respectively) to ensure compliance with Romanian regulations. This resolves rejection errors and allows for proper E-Factura generation.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_ro_edi - Switch to a Romanian localization (e.g. RO Company) - Configure Romanian E-Factura - Create an invoice with a product having a name…
**Steps to reproduce:** - Install Accounting and l10n_ro_edi - Switch to a Romanian localization (e.g. RO Company) - Configure Romanian E-Factura - Create an invoice with a product having a name longer than 100 chars - Confirm the invoice - Send E-Factura to SPV - Fetch E-Factura status **Issue:** The invoice is rejected with the following error: "[BR-RO-L100]-The allowed maximum number of characters for the Item name (BT-153) is 100." **Similar issue with the product description:** "[BR-RO-L200]-The allowed maximum number of characters for the Item description (BT-154) is 200." **Similar issue with the note (i.e. Terms and Conditions):** "[BR-RO-L300]-The allowed maximum number of characters for the Invoice note (BT-22) is 300." **Solution:** Truncate the name of the product to 100 chars in the electronic invoice, the description of the product to 200 and the note to 300. opw-5964904 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267850 Forward-Port-Of: odoo/odoo#265811
3 changes
Resolved issues and error corrections
This update fixes a bug where users were unexpectedly locked out of list views after attempting to edit a row. The fix ensures the system correctly exits edit mode when a user clicks away, preventing this frustrating interruption. This improves the overall user experience and data entry efficiency.
Original PR description
Problem: When a user selects a row, attempts to edit a cell, and then clicks away without saving, the view becomes unusable. The selected row remains highlighted, and the system prevents the selection of other lines. The user is locked out until they click the "Save" or "Discard" buttons. Cause: The UI becomes stuck in edit mode. The `onGlobalClick` event handler within `documents_list_renderer` was missing the method call to exit edit mode. Solution: Updated `onGlobalClick` to correctly trigger the method to leave edit mode. task-6059836 Forward-Port-Of: odoo/enterprise#119008 Forward-Port-Of: odoo/enterprise#113000
This update corrects a calculation error in the executive summary report, specifically within the date range calculations. Previously, the report was undercounting the number of days in a period, leading to inaccurate metrics like Average Debtor Days. This change ensures the report accurately reflects the period length, improving the reliability of key business data.
Original PR description
`_report_custom_engine_executive_summary_ndays` returned `date_to - date_from`, which is the gap between the two dates, not the count of days they span. For example April 2026-04-01 to 2026-04-30 will returned 29 instead of 30, making Average Debtor Days incorrect. Add +1 so the day count is inclusive of both endpoints, matching the rest of the report's date handling. opw-6215362 Forward-Port-Of: odoo/enterprise#118953
This update fixes an issue where the Balance Sheet report's XLSX export was incorrectly including all accounts instead of the one selected in the date filter. The fix removes a filtering step that was unintentionally introduced, ensuring the export accurately reflects the user's chosen account. This improves the reliability of financial reporting.
Original PR description
Steps: - Open Balance Sheet report and unfold lines - Open the General Ledger from a line with an account - On GL report, change date filter - Export XLSX report -> We export all accounts instead of the one selected in the search bar Cause: Since f8dceec74e44ffe4aef67655be8811c96da91eba we filter out the filter if a default account is defined in the context which is the case in the `caret_option_open_general_ledger` method Fix: Remove the filtering as the behavior that was fixed by the mentioned commit does not happen anymore. opw-6234427 Forward-Port-Of: odoo/enterprise#119156
13 changes
Resolved issues and error corrections
This update fixes an issue where the cursor position was incorrect after moving content within the HTML editor. Now, when moving a table or paragraph, the cursor automatically adjusts to the start of the moved content, preserving the user's selection and ensuring a smoother editing experience.
Original PR description
#### Description of the issue/feature this PR addresses: - MoveNode restores the cursor at the container end position - After moving a table, the cursor ends outside the table body #### Desired behavior after PR is merged: - Preserve the selection if it was inside the moved node - Otherwise place the cursor at the start of the moved node #### Steps to reproduce: - Create a table in the editor - Move the table using Movenode - Drop the table and check the cursor position - The cursor ends outside the moved table body - Select some text in a paragraph - Move that paragraph using Movenode - The selection is placed at the end of the moved node task-6215743 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266419 Forward-Port-Of: odoo/odoo#264264
This update fixes a technical problem in Odoo's internal tools that could occasionally cause errors when copying data sets. The change utilizes a more reliable method for copying dictionaries, preventing issues related to Python's garbage collection process. This ensures data integrity and stability.
Original PR description
In Python 3.14, iterating over weak references (like `transaction.envs`) can trigger a `RuntimeError: dictionary changed size during iteration`. This happens mostly because the Garbage Collector can remove a weakref while `OrderedSet.copy()` is rebuilding the set via `dict.fromkeys()`. Instead of re-initializing the set by iterating over its elements, we now directly use the dictionary's native `.copy()` method. This atomic operation prevents the GC from modifying the size of the underlying `_map` during the copy. Forward-Port-Of: odoo/odoo#267947
This update resolves a technical issue flagged by Pylint, a code analysis tool, within the tests for our French localization module (l10n_fr_pdp). The fix ensures our code meets quality standards and prevents potential errors during development. This ensures the continued stability and reliability of the French-specific features.
Original PR description
```
FAIL: TestPyLint.test_pylint
Traceback (most recent call last):
File "/data/build/odoo/odoo/addons/test_lint/tests/test_pylint.py", line 109, in test_pylint
self.fail(f"pylint test failed:\n\n{r.stdout}\n{r.stderr}".strip())
~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: pylint test failed:
************* Module l10n_fr_pdp.tests.test_partner
function already defined line 134 (E0102) at odoo/addons/l10n_fr_pdp/tests/test_partner.py:152
--------------------------------------------------------------------
Your code has been rated at 10.00/10 (previous run: 10.00/10, +0.00)
```
runbot.build.error-939452
Forward-Port-Of: odoo/odoo#267472This update resolves an issue preventing accurate order data synchronization from Point of Sale systems. The fix corrects a typo and updates the system to check for 'done' invoicing status instead of 'invoiced,' ensuring reliable data transfer between POS and the core Odoo system. This improves the overall accuracy of order information.
Original PR description
In this commit: - Update `read_pos_data` to check `done` state for invoicing instead of `invoiced` state - Load `account.move` model instead of `account_move` (fix typo) Task-5887318 Forward-Port-Of: odoo/enterprise#105839
This update fixes an issue where the Balance Sheet report's XLSX export was incorrectly including all accounts instead of the selected one when changing date filters. The fix removes a filtering step that was unintentionally introduced, ensuring the report accurately reflects the user's chosen account selection.
Original PR description
Steps: - Open Balance Sheet report and unfold lines - Open the General Ledger from a line with an account - On GL report, change date filter - Export XLSX report -> We export all accounts instead of the one selected in the search bar Cause: Since f8dceec74e44ffe4aef67655be8811c96da91eba we filter out the filter if a default account is defined in the context which is the case in the `caret_option_open_general_ledger` method Fix: Remove the filtering as the behavior that was fixed by the mentioned commit does not happen anymore. opw-6234427 Forward-Port-Of: odoo/enterprise#119156
This update resolves a visual bug where color selections within the HTML editor's collapsed mode weren't consistently applying. The fix adjusts how the selection is positioned, preventing the browser from reverting the color and ensuring accurate color application when editing text.
Original PR description
Steps to Reproduce: - Apply color on a collapsed selection in mobile - Type some text - Change color from the color picker Description of the issue: - The color picker closes, but the selected color is not applied. Cause: - The color was being applied correctly, but the selection was positioned at offset 0 of the newly created font node. As a result, the browser normalized the selection back to the previous font node, making it appear as though the color was not applied. Solution: - When applying color on a collapsed selection, set the selection offset to 1 instead of 0. This prevents browser normalization and keeps the cursor inside the newly created font tag, ensuring the color is applied correctly. task-6201171 Forward-Port-Of: odoo/odoo#265438
This update corrects a calculation error in the executive summary report, specifically related to the period length. Previously, the report was incorrectly calculating the number of days between dates, leading to inaccurate metrics like Average Debtor Days. This fix ensures the report accurately reflects the actual period length, improving the reliability of key business insights.
Original PR description
`_report_custom_engine_executive_summary_ndays` returned `date_to - date_from`, which is the gap between the two dates, not the count of days they span. For example April 2026-04-01 to 2026-04-30 will returned 29 instead of 30, making Average Debtor Days incorrect. Add +1 so the day count is inclusive of both endpoints, matching the rest of the report's date handling. opw-6215362 Forward-Port-Of: odoo/enterprise#118953
This update resolves an issue where enabling the 'Sales Credit Limit' setting in the Accounting module would trigger an access error when creating new users. The problem stemmed from a default value being incorrectly applied to a restricted field due to inheritance from the 'partner' model. This fix ensures proper access controls are enforced during user creation.
Original PR description
# How to reproduce - Install the Accounting module - In the settings, enable "Sales Credit Limit" - Remove the Accounting access rights of the current user - Try to create a new user # The issue An…
# How to reproduce - Install the Accounting module - In the settings, enable "Sales Credit Limit" - Remove the Accounting access rights of the current user - Try to create a new user # The issue An access error is raised on the field `credit_limit` # Cause Enabling the "Sales Credit Limit" setting will create an `ir.default` for the `credit_limit` field. This field is restricted to a specific group : https://github.com/odoo/odoo/blob/e3b0ca11d99b2ef819cdad68b169112cd73668b6/addons/account/models/partner.py#L515-L518 When creating a record, we check field permissions before adding default values, so the creation of the user is fine. However, since `res.users` inherits from `res.partners`, a new partner will also be created, but this time with the default values in `vals_list`, which will trigger an access right error. # Proposed solution Back port of this commit : https://github.com/odoo/odoo/pull/267193 Access right checks when creating a record were introduced in 18.3 by : https://github.com/odoo/odoo/commit/15132342960df76fcefd3284a9eff2d4d3273150 opw-6240494 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a technical detail in the Odoo Enterprise spreadsheet functionality. A recent change in the underlying spreadsheet library required updating the names of certain properties used by the composer interface. This ensures the spreadsheet component continues to function correctly and reliably.
Original PR description
Since https://github.com/odoo/o-spreadsheet/pull/6063, the props name for cellCorner have been changed to use kebab-case.
This update prevents Odoo from crashing when the Barcode Lookup API returns a broken image URL. Previously, an invalid URL would cause an error. Now, the system safely ignores these errors, ensuring the 'Get Pictures from Barcode Lookup' action continues to function without interruption.
Original PR description
[FIX] product_barcodelookup: avoid crash on invalid image URLs **Steps to Reproduce:** - Install Sales module. - Configure a valid Barcode Lookup API key. - Create a product without an image. - Set a…
[FIX] product_barcodelookup: avoid crash on invalid image URLs
**Steps to Reproduce:**
- Install Sales module.
- Configure a valid Barcode Lookup API key.
- Create a product without an image.
- Set a barcode whose returned image URL is broken or returns HTTP 404
(e.g. `8426904171073`).
- Select the product and trigger the server action:
`Action -> Get Pictures from Barcode Lookup`
Issue:
**During image fetching:**
- Barcode Lookup API successfully returns product data and image URLs.
- `_get_image_from_url()` attempts to download the image.
- The image URL responds with HTTP 404.
- `barcode_lookup_request()` returns a dict for non-200 responses.
- `_get_image_from_url()` assumes the response is always a `requests.Response`
object and directly accesses: `response.status_code`
- This causes: `AttributeError: 'dict' object has no attribute 'status_code'`
**Root Cause:**
- `barcode_lookup_request()` returns inconsistent response types:
- `requests.Response` for successful requests
- `dict` for failed requests
- _get_image_from_url() does not handle the dict response before accessing
response attributes.
**Solution:**
- Make barcode_lookup_request() always return a One Response
object.
- Move the response validation to the callers instead of returning custom
dict objects.
**Result:**
- No RPC crash when image URLs are invalid or return 404.
- Broken image URLs are safely ignored.
**OPW-6200749**
Forward-Port-Of: odoo/enterprise#116925This update resolves an issue where the system incorrectly blocked sending invoices to 0225 Peppol EAS partners. Previously, this was only allowed when the French localization module (`l10n_fr_pdp`) was installed. Now, it's enabled by default, resolving a previous demo data installation problem and ensuring broader Peppol integration.
Original PR description
Previously we blocked the 0225 peppol_eas when `l10n_fr_pdp` is not installed. But you should still be able to send to 0225 partners with just peppol. Since the PDP module is auto installed with the French localization and we block the 0225 EAS server side on the peppol (non-PDP) server it should be fine to just allow it for everyone. It also caused an issue when installing the demo data for the `hair_salon` industry in a French company on trial. opw-6268629 Forward-Port-Of: odoo/odoo#267993
This update resolves two key issues related to HR document attachments. Previously, attachments were created in the root employee folder, which was inconvenient. Now, attachments are correctly created within the appropriate HR document folders for leave and contracts. This ensures attachments are organized and easily accessible.
Original PR description
Before this commit, when adding an attachment to a leave or a employee version the mixin was configured to create the document in the root folder of Employees which was not very convenient. In addition, when creating a Sick leave with an attachment, no document was ever created. This commit fix both those bugs. Task-6095811
This update resolves an issue where setting a non-numeric value for the 'next check number' in bank journals would cause an error. The change ensures the system validates that the number is numeric before attempting to convert it, preventing the error and allowing users to correctly set check numbers.
Original PR description
Currently, an error occurs when a user sets a non-numeric value as the journal's next check number. **Steps to Reproduce:** - Install the `account_check_printing` module with demo data. - Go to…
Currently, an error occurs when a user sets a non-numeric value as the journal's next check number. **Steps to Reproduce:** - Install the `account_check_printing` module with demo data. - Go to `Invoicing` > `Configuration` > `Accounting` > `Journals`. - Open the `bank journal`. - In the `Outgoing Payments` tab > Enable `Manual Numbering`. - Set the `next check number` to a `non-numeric` value `(e.g. FA1234)` and `save`. `ValueError: invalid literal for int() with base 10: 'FA1234'` After [this commit], the next check number is converted to an integer without first validating that it contains only numeric characters [1]. Since the value can be non-numeric, converting it directly to an integer raises the error. This commit ensures that the next check number is converted to an integer only after verifying that it contains numeric characters only. [this commit]: https://github.com/odoo/odoo/commit/cc2004404462ecb523f7877569ce6a06b05341b4 [1]- https://github.com/odoo/odoo/blob/00dd75f345d7f5ddb04cecf52eca07e5a22c7d3c/addons/account_check_printing/models/account_journal.py#L57-L61 sentry-7498755988 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266280
4 changes
Resolved issues and error corrections
This update fixes an issue where the General Ledger and Balance Sheet reports were incorrectly exporting all accounts instead of the selected one when changing date filters. The fix removes unnecessary filtering logic, ensuring the report accurately reflects the user's chosen account. This improves report accuracy and usability.
Original PR description
Steps: - Open Balance Sheet report and unfold lines - Open the General Ledger from a line with an account - On GL report, change date filter - Export XLSX report -> We export all accounts instead of the one selected in the search bar Cause: Since f8dceec74e44ffe4aef67655be8811c96da91eba we filter out the filter if a default account is defined in the context which is the case in the `caret_option_open_general_ledger` method Fix: Remove the filtering as the behavior that was fixed by the mentioned commit does not happen anymore. opw-6234427 Forward-Port-Of: odoo/enterprise#119156
This update fixes a calculation error in the executive summary report that was underreporting the length of time periods. Previously, the report was calculating the gap between dates instead of the number of days. This change ensures the report accurately reflects the period length, specifically for metrics like Average Debtor Days, leading to more reliable reporting.
Original PR description
`_report_custom_engine_executive_summary_ndays` returned `date_to - date_from`, which is the gap between the two dates, not the count of days they span. For example April 2026-04-01 to 2026-04-30 will returned 29 instead of 30, making Average Debtor Days incorrect. Add +1 so the day count is inclusive of both endpoints, matching the rest of the report's date handling. opw-6215362 Forward-Port-Of: odoo/enterprise#118953
This update addresses an issue where manual operations were incorrectly being matched during account reconciliation. This reversion restores the previous system behavior, ensuring accurate reconciliation processes. It's a technical fix to improve the reliability of our accounting system.
Original PR description
This reverts commit 038f527793757c3148b775af1657c5a70a5abc66. opw-6230807 Forward-Port-Of: odoo/enterprise#118169
This update fixes an issue where the ICP export generated inconsistent XML reports by using values from multiple company contexts. The change ensures a single, reliable company context is used for identifier values, improving the accuracy and clarity of the exported data. This enhances the reliability of the ICP reporting process.
Original PR description
Description of the issue this commit addresses: The ICP export could mix values from different company contexts. In some cases, the main identifier and the fiscal entity division value did not come from the same source, which could create confusing or inconsistent XML output. --- Desired behavior after this commit is merged: This commit makes the ICP export use one consistent company context for identifier values, reuses precomputed values when available, and avoids overwriting them with unrelated defaults. --- task-6065382 Forward-Port-Of: odoo/enterprise#119152 Forward-Port-Of: odoo/enterprise#112995
13 changes
Resolved issues and error corrections
This update fixes a readability issue in appointment email templates when dark mode is enabled. The team adjusted background colors and simplified template code to ensure content is clearly visible for all users. This improves the overall user experience and consistency across Odoo.
Original PR description
This PR fixes and improves the display of the mail templates and also cleans their code. For this, several commits are needed: - Commit 1 sets the mails' background color to white because a dark custom color has been specified. Before this change, the content was not readable when the dark mode was enabled since the background and the font had similar colors. - Commit 2 adds default values to avoid displaying variables that users cannot understand inside the editor and replaces some t-attf-style by style, as they contain no variable. Community PR: https://github.com/odoo/odoo/pull/249102 Task-5886471
This update resolves an issue where users without sign permissions were unable to access records with sign request activities, resulting in an access error. The fix uses 'sudo' to ensure access and prevents actions that trigger the error, improving the sign request workflow for all users.
Original PR description
**Steps to reproduce** - Have user A with Sign admin rights and user B without Sign rights. - With user A, create a sign request activity on a record that user B can access. Send the signature…
**Steps to reproduce** - Have user A with Sign admin rights and user B without Sign rights. - With user A, create a sign request activity on a record that user B can access. Send the signature request. - With user B, try to access the record. -> AccessError when trying to fetch the chatter. **Cause** By default, users get access to all the activities associated to records they have access to (see `_search` of `mail.activity`). This is an issue since some of the fields added in `_store_activity_fields` for the sign request activity display might not be accessible for a user with access to the activity. **Change** Use `sudo` to be able to display the activity, even if the user doesn't have access to the sign request. Also, in that case, `can_write` should be `False` in order to hide the action buttons of the activity, which trigger access errors when trying to make operations on the sign request. Another related change is to create the activity for the user creating the sign request, this avoids falling back on the `user_id` of the record associated with the activity and makes sure the activity's user has access to the sign request. opw-6157455 Forward-Port-Of: odoo/enterprise#118555 Forward-Port-Of: odoo/enterprise#116540
This update adds a direct link within the Timesheets Assistant to its official documentation. This makes it easier for users to quickly find answers to their questions and understand how to use the Timesheets Assistant effectively. It’s a small change designed to improve user support and knowledge.
Original PR description
This commit adds documentation link in Timesheets Assistant to redirect the user to the documentation of Timesheets Assistant. task-6095833 Forward-Port-Of: odoo/enterprise#119022 Forward-Port-Of: odoo/enterprise#118754
This update resolves an issue where the system incorrectly flagged incoterm requirements for export invoices containing service products. Previously, the system demanded incoterm information even for services, which is not required by tax regulations. This change ensures accurate invoice export to the tax agency.
Original PR description
With l10n_gt_edi: - Create an invoice with a partner without a country (in l10n_gt this is considered an export invoice) and a service product. When trying to export the invoice to the tax agency, the following alert is triggered: Incoterm is required on export invoice with goods product but it's currently missing However, service products do not require incoterm configuration. opw-6170409 Forward-Port-Of: odoo/enterprise#115833
This update corrects a misunderstanding in the payment flow for orders with a price of zero. Previously, paying a sum through the 'customer account' method incorrectly treated it as a return. The fix now hides the 'pay_later' payment method when the order price is zero, aligning with business requirements and preventing incorrect accounting.
Original PR description
Step to reproduce: - install "pos_settle_due" - create a pos order, set order price = 0, select a customer - go to payment page, select "customer account" as payment method - here you can set any…
Step to reproduce: - install "pos_settle_due" - create a pos order, set order price = 0, select a customer - go to payment page, select "customer account" as payment method - here you can set any amount to pay, ex 100$ - fulfill the order. Observation: - the order amount is 0, if we pay 100$ using customer account, it is considered as change (which means we returned it to customer) - As per PO, this flow doesn't make sense Issue: - customer has 100$ due for this order, but he won't be able to settle this as fetch order to settle with amount != 0, after commit [1] - [1] https://github.com/odoo/enterprise/commit/12af23d5382e972facfaa999e4c5ab30c97e8d1f https://github.com/odoo/enterprise/blob/951e5f42884c898bc14d9c32ae6a8f08c31ff06d/pos_settle_due/static/src/app/screens/partner_list/partner_line/partner_line.js#L35 Fix: - we hide payment method of type "pay_later" in case of 0 price order opw-6123699 Forward-Port-Of: odoo/enterprise#118864 Forward-Port-Of: odoo/enterprise#116556
This update optimizes the styling of the Odoo Enterprise home menu by replacing inefficient CSS selectors with CSS variables. This change improves page loading speed and overall performance, leading to a smoother user experience. The update ensures the home menu remains responsive and fast.
Original PR description
Avoid selectors after `:hover` and `:active`, as they can impact performance. CSS variables are now used instead. Replace hex color values with "0 0 0" RGB syntax to ensure compatibility with CSS variable usage. Forward-Port-Of: odoo/enterprise#119082
This update resolves two minor bugs in the point-of-sale test suite. Specifically, it corrects how test results are evaluated and handles potential type mismatches, ensuring the tests accurately reflect the functionality of the POS system. This improves the reliability of the testing process.
Original PR description
..., l10n_es_pos, l10n_jo_edi_pos, l10n_br_edi_pos
---
Fix two bugs in the checkTicketData() test helper:
- Replace falsy check `!statement` with `!statement.length` to
correctly handle empty NodeList results from querySelectorAll,
as an empty NodeList is still truthy.
- Replace loose equality `ruleFound == rule.negation` with strict
equality `ruleFound === (rule.negation || false)` to avoid
unintended type coercion when `rule.negation` is undefined.
---
Task: https://www.odoo.com/odoo/project/1737/tasks/6147566
Forward-Port-Of: odoo/enterprise#118557
Forward-Port-Of: odoo/enterprise#114581This update resolves an issue caused by a recent change in the HR schedule layout. The update adjusts the view structure to ensure schedules display correctly within the new group layout. This improves the overall usability of the HR schedule feature.
Original PR description
Fixes the view breakdown caused by migrating the schedule separator to a group layout in the base hr view. Task: 6267822
This update allows users to efficiently edit analytics distribution data directly within asset records, mirroring the functionality available for journal items. This enhancement streamlines the process of analyzing asset performance and provides a more consistent user experience across Odoo Enterprise.
Original PR description
This commit fixes the multi-edit of analytics distribution field in assets form view. The multi-edit option was added to the analytics distribution widget, same as in the journal items. task-6218188 Forward-Port-Of: odoo/enterprise#119054 Forward-Port-Of: odoo/enterprise#118042
This update fixes a technical issue that prevented the system from correctly processing payrolls with previously recorded negative amounts. The fix involved correcting references to these amounts and removing unnecessary code, ensuring accurate paycheck calculations and preventing errors.
Original PR description
Steps to produce: - create a previous payslip with negative amount - create a payslip for current month - click on the warning to apply negative amount - you get an error or a traceback because it's referencing an input which is removed from the system and migrated to other input Fix: - corrected the reference to negative net - removed content of the method `_generate_payslip` as it's not used and referencing removed inputs task-id: 6240163 Forward-Port-Of: odoo/enterprise#119143 Forward-Port-Of: odoo/enterprise#118144
This update resolves an issue where the Timesheet Assistant was incorrectly matching events to projects with disabled timesheets. The changes ensure the assistant only considers projects with active timesheets, improving data accuracy and preventing irrelevant suggestions. This update was implemented across the entire system.
Original PR description
Currently, the Timesheet Assistant (ActivityWatch) can match events to projects or tasks that have timesheets disabled, either via Custom Rules or Historical Memory.
This commit resolves the issue across the entire pipeline:
- Backend: Updated `resolve_assistant_models_targets` to efficiently filter out records where `allow_timesheets` is False using a search domain.
- Frontend: Updated the `loadData` JS pipeline to intercept and wipe any project/task IDs rejected by the backend, ensuring they cleanly fall back into a single "Unmatched" group.
- Views: Added the `[('allow_timesheets', '=', True)]` domain to `project_id` and `task_id` fields in `aw.rule` views to prevent users from creating invalid rules.
Task: 6267401This update resolves a technical error that prevented users from accessing the assistant frequency view within the Odoo Enterprise application. The issue stemmed from a missing context variable, which caused an error when the view attempted to display optional settings. The fix adds a necessary context variable and a test to ensure this functionality remains stable.
Original PR description
Steps: 1- install timesheet_grid 2- navigate to assistant > configuration > local assistant rules => TypeError: Cannot read properties of undefined (reading 'list_optional_show') Source: After commit https://github.com/odoo/odoo/commit/764e7c2a951eb775e7aa2579f4e0774e382a385b, context.list_optional_show was added, but context is undefined in the assistant frequency viewer Solution: add context as an empty object add a test to detect regressions on openinig the frequency viewer task-6251619
This update resolves an issue where the Executive Summary report would fail when the date range option was disabled. The fix ensures the report uses the fiscal year's start date instead, preventing a calculation error and ensuring the report always displays correctly. This improves the report's reliability for users.
Original PR description
## Steps to Reproduce: 1. Install the Accounting module. 2. Go to Accounting > Reporting > Executive Summary. 3. Activate debug mode. 4. Click on the gear icon at the top. 5. In the "Options" tab,…
## Steps to Reproduce: 1. Install the Accounting module. 2. Go to Accounting > Reporting > Executive Summary. 3. Activate debug mode. 4. Click on the gear icon at the top. 5. In the "Options" tab, disable the "Date Range". 6. Open the report again. ## Error: `TypeError - unsupported operand type(s) for -: 'datetime.date' and 'NoneType'` ## Cause: At [1], when the "Date range" option is disabled in the summary report, `date_from` becomes None. The NDays expression still computes `date_to - date_from` at [2], which raises a TypeError because subtraction between a datetime and NoneType is not supported. ## Fix: This commit takes the fiscal-year's start date, when the date-range feature is disabled. [1] - https://github.com/odoo/enterprise/blob/a9cadd93b849375edfcc7fd04612d9eb8787043b/account_reports/models/account_report.py#L564-L570 [2] - https://github.com/odoo/enterprise/blob/a9cadd93b849375edfcc7fd04612d9eb8787043b/account_reports/models/executive_summary_report.py#L15-L16 sentry-7455506965 Forward-Port-Of: odoo/enterprise#119162 Forward-Port-Of: odoo/enterprise#116888
4 changes
Resolved issues and error corrections
This update fixes a bug that prevented quality checks on manufacturing MOs when an invalid measure was entered. The change reflects a recent update to the system's MO structure, ensuring stability and proper functionality for quality control processes. It utilizes the first lot/serial from the MO when available.
Original PR description
## Steps to reproduce: - Install the `quality_mrp` module. - Create a new product. - Create a Quality Point with: Type: Measure, Control per: Product/Operation Operations: Manufacturing - Create and confirm MO for the product. - Update the Quality Point: Remove the 'manufacturing' operation type and add 'receipts' type. Change Control per to 'Quantity'. - Open the MO and start a quality check. - Enter an invalid measure and try to validate it. ## Error: `AttributeError - 'mrp.production' object has no attribute 'lot_producing_id'` ## Cause: Since commit https://github.com/odoo/odoo/commit/4bb4e08066449177f89382718ceadd840ce90d0e, the `lot_producing_id` field on MO was replaced by the Many2many field `lot_producing_ids`. Invalid references to the removed field lead to an error. ## Fix: This commit uses the first lot/serial from the MO. Note: Multiple produced lots are only possible for serial-tracked products. sentry-7511513479
This update fixes an issue where negative line items in the MX CFDI tax reporting were incorrectly distributed. The change addresses a conflict introduced by new features like discounts and down payments, which made the previous method of checking line types obsolete. This ensures accurate tax reporting for Mexican businesses using the CFDI format.
Original PR description
In MX CFDI, negative lines are not allowed so they are distributed over other lines. But because this PR introduces some other `special_type` like `global_discount` and `down_payment`, it becomes useless to check `base_line['special_type'] == False`. Fix for https://github.com/odoo/odoo/pull/267435 task-5900496 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/enterprise#119254
This update fixes an error in the executive summary report that was incorrectly calculating the period length. Previously, it was measuring the gap between dates instead of the number of days, leading to inaccurate metrics like Average Debtor Days. This change ensures the report accurately reflects the period's length, improving the reliability of key business insights.
Original PR description
`_report_custom_engine_executive_summary_ndays` returned `date_to - date_from`, which is the gap between the two dates, not the count of days they span. For example April 2026-04-01 to 2026-04-30 will returned 29 instead of 30, making Average Debtor Days incorrect. Add +1 so the day count is inclusive of both endpoints, matching the rest of the report's date handling. opw-6215362 Forward-Port-Of: odoo/enterprise#118953
A recent test failure in the website rental product functionality was caused by inconsistent timezone settings. This update has standardized all timezone data to UTC within the test environment, resolving the issue and ensuring reliable test results. This ensures accurate product display and functionality for rental products.
Original PR description
The test_add_accessory_rental_product test failed on the runbot due to a timezone ambiguity where two of them were used. I changed the website timezone to UTC in the test data definition to uniform them. Runbot error: 233282
6 changes
Resolved issues and error corrections
This update resolves an issue where spreadsheet formulas in the Account module were sending company IDs as strings, leading to server errors. The change ensures company IDs are converted to numbers, handling both numeric and null values correctly for accurate calculations. This improves spreadsheet stability and reliability.
Original PR description
Current behavior before PR: - The `ODOO.CREDIT`, `ODOO.DEBIT`, and `ODOO.BALANCE` formulas passed `companyId.value` directly to the server without converting it to a number. - If a user passed company_id as a string (e.g., '1' from a cell), it was sent to the server as a string, causing a server error. Desired behavior after PR is merged: - `companyId` is converted using toNumber() before being passed to the getter and the server, so '1' becomes 1. - null is preserved as-is (no company filter) while any non-null value is safely cast to an integer. Task: [6240005](https://www.odoo.com/odoo/project/2328/tasks/6240005) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266009
This update fixes an issue where the 'Out of Office until...' date displayed in the Discuss chat was incorrect when users were in negative timezones. The fix ensures the date is always shown in UTC, resolving a display discrepancy and improving the accuracy of leave information for employees and managers.
Original PR description
Issue: ---------------------------------------- When in a negative timezone, the "Out of Office until..." text in discuss shows the day before. Steps to reproduce:…
Issue: ---------------------------------------- When in a negative timezone, the "Out of Office until..." text in discuss shows the day before. Steps to reproduce: ---------------------------------------- - Change the timezone of the user to "America/Toronto" for example - Have an employee currently on leave until tomorrow - Open discuss to chat with this employee - The "Out of Office until..." shows today's date Cause: ---------------------------------------- When calling `toLocaleString()` without a timezone specified in the options, the date is converted to local time (in the browser's timezone). Here `persona.out_of_office_date_end` is just a date, `deserializeDateTime()` converts it to a timestamp, so the same day at 0am. Then if the timezone is negative, the timestamp becomes an hour the previous day when calling `toLocaleString()`. The format we give `DateTime.DATE_MED` doesn't include hours, so we just display the previous date. Solution: ---------------------------------------- Add `timeZone:"UTC"` in the options to avoid the timezone conversion. opw-6252040 Forward-Port-Of: odoo/odoo#267479
This update resolves an error that occurred when users clicked the 'translate' button in the CRM module. Specifically, the issue stemmed from how the system handled record saving in different view types, leading to a technical error. This fix ensures the translate button functions correctly across all scenarios.
Original PR description
Currently, an error occurs when the user clicks on the translate button. **Steps to Reproduce:** - Install the `CRM` module. - Go to `settings` and in `Languages` add 1 more language. - Go to `CRM` >…
Currently, an error occurs when the user clicks on the translate button. **Steps to Reproduce:** - Install the `CRM` module. - Go to `settings` and in `Languages` add 1 more language. - Go to `CRM` > `Configuration` > `Pipeline` > `Tags`. - Click `New` and, in the `Name` field click the `translate button` on the right. **Behavior in 18.0** When the tag name is not set, the translation dialog opens immediately. If a tag name is entered, the translation dialog shows the translated value on the second click. **Behavior in saas-19.1** `AssertionError: Invalid falsy real id` Error: After this [recent commit], when the user clicks on the translate button, if the record has a root record, the root record is saved before opening the translation dialog. However, in the case of an editable DynamicList view, the record does not have a root record so saving the record returns a promise instead of the resolved value [1]. Because of this promise, the condition fails [2], and the translation dialog is opened with a falsy ID since the record is not yet saved [3]. In saas-19.1, this issue raises Invalid falsy real id error after [this commit](https://github.com/odoo/odoo/commit/4290724a4c8c57fba4f4d3d688d38f65dadcc38f). This commit ensures that await is used so the resolved value is returned after the record is saved before opening the translation dialog. [recent commit]: https://github.com/odoo/odoo/commit/5245ec39a12e7d3a10fcc4c2c92b0f7dbf52d3be [1]: https://github.com/odoo/odoo/blob/9e3fc9568fcebcb1de6486d2ab7134e8a12087b7/addons/web/static/src/views/fields/translation_button.js#L23 [2]: https://github.com/odoo/odoo/blob/9e3fc9568fcebcb1de6486d2ab7134e8a12087b7/addons/web/static/src/views/fields/translation_button.js#L24-L26 [3]: https://github.com/odoo/odoo/blob/9e3fc9568fcebcb1de6486d2ab7134e8a12087b7/addons/web/static/src/views/fields/translation_button.js#L29-L41 sentry-7384270487 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a potential error in the PDP reporting flows that could occur when new or incomplete flow records are created. The fix ensures the system handles missing due dates gracefully, preventing crashes during form creation. This improves the stability and reliability of the reporting process.
Original PR description
PDP reporting flows compute their period status from the due period dates. On a new or incomplete flow record, those dates can still be empty during form/onchange initialization. The compute then tried to compare today's date with `False`, which could crash generic form creation. This patch makes the compute handle missing period dates before doing date comparisons. runbot.build.error-939459
This update resolves an issue where users were prevented from uploading documents to requests linked to records they didn't have full access to. By adding a '.sudo()' function during the attachment creation process, users can now upload documents regardless of their specific access rights, improving workflow efficiency.
Original PR description
Issue: Users are currently blocked from uploading requested documents if the request is linked to a record they do not have access to (e.g., User A links Record X to a request assigned to User B, but User B lacks read/write access to Record X). The system throws an error because the user cannot create an attachment for that record. Fix: Add .sudo() on the attachment creation process. task-6107099
This update corrects a previous issue where website orders automatically generated CFDI invoices, which was unnecessary and potentially problematic. Now, invoices are only created for website orders when the customer provides all required information, aligning with standard e-commerce practices. This ensures a smoother and more accurate order process.
Original PR description
There is no reason why we would always cfdi to public when creating orders from the e-commerce. When the customer give all their info, the invoice should not be cfdi to public. opw-6180766 Forward-Port-Of: odoo/enterprise#116061