Wednesday, January 21, 2026
46 changes · 19.0
Resolved issues and error corrections
This update fixes an issue where clicking links within the Odoo chat window on mobile devices caused the chat window to remain open and cover the new page. Now, the chat window automatically folds when a link is clicked, ensuring users can easily view the linked page without manually adjusting the chat window.
Original PR description
Clicking on an odoo link in the chat window will take the user to the related page in odoo. However, in mobile view, the chat window remains unfolded and covers the entire page, so the user can't see the newly opened page below the chat window unless they fold the chat window. This change fixes this by folding the chat window in mobile view when clicking an odoo link inside the chat window. task-4762503 Forward-Port-Of: odoo/odoo#244383 Forward-Port-Of: odoo/odoo#208440
This update resolves an issue where changing a tax lock date to a past date would trigger an error. The fix prevents the system from generating default external values when the lock date is set in the past, ensuring smoother operation and preventing unexpected errors related to date calculations.
Original PR description
To reproduce the issue, on a company in Luxembourg: 1) Set a tax lock date to November 30th 2) Attempt to change the tax lock date to November 15th ===> Lock date violation error. This happens because _generate_default_external_values still gets called in case the lock date is set back in the past (since _get_current_period_dates call in _create_default_report_external_values returns a tuple basically containing (former lock date + 1 day, new lock date)). Doing so, it tries generating a default external value with a value of 0 (because no data will ever be available in such an impossible date interval), but the previously set lock date prevents it, and raises the error. opw-5383010 Forward-Port-Of: odoo/enterprise#102756
This update enhances the security of user profile editing by utilizing a new internal helper function, '_can_edit_country()', to determine if a user is authorized to change their country setting. This change, implemented as a fix, ensures that profile editing aligns with security standards introduced in Odoo 18.4.
Original PR description
In 'save_edited_profile()', we check that the user can edit his country_id if he tries. As from saas-18.4, a new helper '_can_edit_country()' is available. This commit uses that helper to perform the check. Follow-up of #239789 Task-5331916 Forward-Port-Of: odoo/odoo#244694
This update fixes a potential issue where negative taxable income amounts appeared on payslips when state deductions exceeded employee gross income. The change ensures that taxable income defaults to zero in these scenarios, preventing incorrect financial reporting and improving payroll accuracy. This resolves a prior bug related to state tax calculations.
Original PR description
This commit simply defaults the computed taxable income amount to 0 in case the state deductions are greater than their gross income. Otherwise our payslips would imply that these employees are owed money by the state opw-5137280 Forward-Port-Of: odoo/enterprise#102599 Forward-Port-Of: odoo/enterprise#98114
This update fixes a technical issue where a new fiscal reform field was incorrectly used in the point-of-sale module. The change ensures the module aligns with legal requirements and automatically installed features. This correction was prompted by a customer and maintains consistent behavior with other fiscal reform modules.
Original PR description
`l10n_br_operation_type_pos_id` is a new field introduced in the fiscal reform [1] in saas-18.4. It's added in `l10n_br_edi_pos_fiscal_reform`, but is mistakenly used in `l10n_br_edi_pos`. Because the modules are legally required since the beginning of January and auto-installed it wasn't notice until now. This reverts the change to `l10n_br_edi_pos` and moves the logic to an override in `l10n_br_edi_pos_fiscal_reform`. Additionally, we only do it if the fiscal reform is enabled on the database with `l10n_br_is_icbs`, like we do for all other fiscal reform features. Thanks to ANDG for pointing it out. [1] odoo/enterprise#102835 Forward-Port-Of: odoo/enterprise#104671
This update removes unnecessary integer rounding from the monthly Italian VAT reports. The rounding was mistakenly carried over from annual reports, a consequence of a previous split in the reporting functionality. This ensures accurate VAT calculations for monthly reporting.
Original PR description
Integer rounding is only required on annual l10n_it VAT reports. It appears that it was incorrectly added to the monthly report when the two were split in [#193662](https://github.com/odoo/odoo/pull/193662). [opw-5292310](https://www.odoo.com/odoo/project.task/project.task/5292310) Forward-Port-Of: odoo/enterprise#104228 Forward-Port-Of: odoo/enterprise#103852
This update corrects a technical issue where performing an undo operation within the HTML editor would generate a traceback error. The fix ensures that undoing actions now functions smoothly without causing errors, improving the overall stability and usability of the editor. This resolves a minor bug that could potentially disrupt user workflows.
Original PR description
Current behavior before PR: - Inserting a /code block, then adding text above it and performing an undo would trigger a traceback. Desired behavior after PR is merged: - Undo now correctly removes the inserted character without causing any traceback. task-5445873
This update corrects an issue where product references were appearing in the names of products displayed on the website's product carousel. This change ensures that product names are clean and accurate, improving the user experience for customers browsing our online store. The fix was triggered by a specific scenario involving a product with a single value in its free text attribute.
Original PR description
**Issue**
When a product has a free text attribute with one value, the product reference appears in the name of the product on the product carousel.
**Expected behavior**
The product reference should not appear in the name of the product on the product carousel.
**Steps to reproduce**
1. Create a product to be sold online
2. Give it an internal reference
3. Add a free text attribute with one value
4. Set a product carousel on a website page
5. Disable "show variants" in the settings of the carousel
=> The product reference appears in the name of the product
**Note**
The issue happened only if the free text attribute has only one value, with more than one value, the product reference did not appear.
**Fix**
Updated the QWeb template to use the prepared clean title with data.get('display_name') instead of record.display_name
opw-5410822
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#242791A recent update to the delivery system caused an issue that was subsequently identified. This pull request reverts the problematic changes to restore the previous, correct behavior. The issue will be addressed in a future update.
Original PR description
Bug introdcued in: https://github.com/odoo/odoo/commit/6901863d30f524c160971c9f5c97846ffd1fa5f5 The fix was misleading because forcing the context in the unit test caused incorrect assumptions. Passing `default_carrier_id` in the context prevents the computed method from being called, breaking expected behavior. This revert restores the previous behavior as the fix is incorrect. The issue will be resolved in another PR. Forward-Port-Of: odoo/odoo#244774
This update resolves an issue that previously caused errors when adding new transcription snippets to records before they were saved. The change ensures that record IDs are correctly established, preventing these errors and improving the stability of the AI transcription component. This enhances the user experience by allowing users to consistently add and manage transcription snippets.
Original PR description
This PR fixes an issues where an exception would be thrown when inserting a transcription snippet on an unsaved record. It does so by removing the resId, resModel props and only retrieving them when actually needed (when opening the full composer to send the summary). Also whennever opening the full composer, we force a save on the record to ensure proper resId. task-5788331
This update corrects a minor issue in how overtime hours are recorded, ensuring more accurate calculations for employee balances and reporting. Previously, overtime was rounded to two decimal places, leading to potential inaccuracies when aggregating data. This change improves the reliability of overtime calculations, particularly for large teams and reporting needs.
Original PR description
### Current behavior: Overtime hours are stored with a two-decimal precision. This means a minute is stored as a minute and twelve seconds in the worst case, which would amplify The overtime given or taken on a particular attendance. This is problematic when aggregating the records for large datasets to compute the balance or for reporting ### Expected behavior: A minute should be stored closer to its real decimal value to minimize the error in aggregations. as a minute and 1.2 seconds opw-5422827 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a potential issue in the Nilvera accounting module where the default journal type was incorrectly set. The default has been changed from 'in_invoice' to 'purchase' to prevent incorrect document generation. This ensures Nilvera documents are created with the appropriate accounting settings.
Original PR description
…hing The default value of the journal type parameter was incorrectly set to a move type (`in_invoice`). Although all current callers explicitly pass the correct journal type, the default value has been corrected to `purchase` to avoid potential misuse. no task-id Forward-Port-Of: odoo/odoo#242865
This update prevents the API documentation endpoint from crashing when encountering models not currently defined in Odoo's code. The fix addresses a situation where outdated model definitions in the database would cause a server error. This ensures the documentation is consistently available.
Original PR description
When accessing the API documentation endpoint (`/doc`), the server could crash with an Internal Server Error if the database contained ir.model records for models that are not loaded in the current registry. Steps to reproduce: 1. Insert a record into `ir_model` with `model='ghost.model'` and `state='base'`. 2. Open `/doc`. 3. The server raises a `KeyError: 'ghost.model'`. Root Cause: The `/doc` endpoint iterates over all records in `ir.model`. For each record, it attempts to resolve the Python class using `self.env[ir_model.model]` to check access rights. If a model exists in the database with `state='base'`, Odoo expects it to be defined in the Python source code and does not generate it dynamically. If the corresponding Python class is missing (e.g., from an old module), it is never added to the registry, causing the lookup to fail with a `KeyError`. opw-5401782
This update resolves an issue that prevented the HR module from upgrading correctly after an overtime rule was deleted. The fix disables a constraint that caused errors during the upgrade process, ensuring smoother module updates and preventing potential disruptions to attendance tracking.
Original PR description
**Steps to reproduce** - Install `hr_work_entry_attendance` - Delete one of the overtime rules from the "Default Ruleset", e.g. "Employee Schedule Rule" - Upgrade the `hr` module - Traceback: `psycopg2.errors.CheckViolation: new row for relation "hr_attendance_overtime_rule" violates check constraint "hr_attendance_overtime_rule_if_paid_work_entry_type_defined"` **Cause** The `_if_paid_work_entry_type_defined` constraint added by the `hr_work_entry_attendance` module on overtime rule records will fail when re-creating an overtime rule record when upgrading another module than `hr_work_entry_attendance`, since the module is not loaded and we don't get a default value for the `work_entry_type_id` field. **Fix** Since the ORM cannot manage that, disable forcecreate for these records. Related: https://github.com/odoo/enterprise/commit/f935e62bae7f204ea3f6db8f08b173bdf011c0d2 opw-5428542
This update fixes an issue where document sharing links were incorrectly formatted, preventing users from accessing shared documents. The change moved the invitation link to the mail template, aligning with previous versions and ensuring correct link generation. This improves the user experience for document sharing within the system.
Original PR description
Bug === Since 22446368503fadc0e0bf459dd3c8ab8b8f6624b0 , we use a mail template to share access, but in e3e8d6a6b9423feae4dd88978065bd8799031b2b , we added the link in the standard notification process (because it was done in 18.0). Task-5242208
This update enhances the Odoo database's security by ensuring that queries against the PostgreSQL database always use the correct schema. This prevents potential data corruption and hidden bugs that could arise when multiple schemas are used simultaneously. It addresses a previously reported issue and a related task, strengthening overall database stability.
Original PR description
Safety measure to prevent hidden bugs and data corruption which can happen when multiple schema are used in PostgreSQL. Description of the issue/feature this PR addresses: Related to: - PR #243833 - OPW [opw-5495025](https://www.odoo.com/my/tasks/5495025) - issue reported earlier: #97891 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a problem where the status banner for digitized vendor bills disappeared when auto-posting was enabled. When auto-posting is used, the bill's status jumps directly to 'to_validate', potentially moving to 'done' if the validation process completes before the banner updates. This ensures the status banner accurately reflects the bill's processing stage.
Original PR description
The status banner widget expected the state to be equal to `waiting_validation` once the document was successfully digitized. But when auto-post is used on vendor bills, the state will skip directly to `to_validate` as the bill is posted right after the digitization. It can even be moved to `done` if the validation cron has time to run before the update of the banner. task-[5480954](https://www.odoo.com/odoo/49/tasks/5480954)
This update resolves a hidden bug that could occur when using multiple databases within PostgreSQL. The change ensures queries against the 'pg_class' table correctly reflect the current database schema, preventing inaccurate results and potential data discrepancies. This improves overall system stability and data reliability.
Original PR description
It prevents hidden bugs when multiple schemas are used in PostgreSQL This was mentioned in: - PR odoo/odoo#243967
This update optimizes the loading of live chat expertise data, preventing unnecessary information from being retrieved. Previously, data was fetched regardless of whether it was needed, causing performance slowdowns. Now, expertise data is only loaded when a live chat session is opened, improving responsiveness and efficiency.
Original PR description
Before this commit, the user's live chat expertise were always returned as part of `_init_store_data`. However, this led to a warning in portal tours because the expertises are inserted into the store while the live chat models are not loaded (they are not needed). We shouldn't return useless data. This commit fixes this issue by fetching the data when they will be needed (i.e. when the discuss app is opened with a live chat user). runbot-234137 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
This update completes a previous fix for the spreadsheet module. It ensures that all data upgrades are correctly applied on the user's computer (client-side), improving data consistency and accuracy within the spreadsheet functionality. This resolves a previous oversight and maintains the integrity of spreadsheet data.
Original PR description
Follow up of 682d6ec1ddb825674999e0db1fc0cc48c3be67c5 where I forgot to add the client-side data upgrade Task-5477426 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update enhances the website's accordion functionality by allowing users to easily navigate to specific sections within accordions. The changes automatically scroll to and expand the correct accordion item, improving the user experience and accessibility. This addresses a previous limitation in how accordions were handled.
Original PR description
*=html_builder This PR introduces the following changes: - Add `.accordion-item` selector in the `AnchorPlugin`. - Expands the list of titleEls selectors to include `.h1-fs, .h2-fs, .h3-fs, .h4-fs, .h5-fs, .h6-fs, .display-1-fs, .display-2-fs, .display-3-fs, .display-4-fs, .base-fs, .o_small-fs`. - Enhances the "AnchorSlide" interaction by adding the "handleAccordionAnchor" method, called in "animateClick" and "setup" to automatically scroll to and expand accordion items. The method uses the `show()` function from bootstrap `Collapse` component, which efficiently manages the expansion of required accordion item and collapse the rest. task-5065165
This update enables users to create returns for previously archived accounting periods without needing to reactivate or overwrite existing archived returns. This provides greater flexibility in managing returns and simplifies the accounting process. A new test case has been added to ensure the functionality works as expected.
Original PR description
Archived returns are ignored when manually creating returns, allowing a new return to be created for the same period without reactivating or overwriting the archived one. Also a test case has been added for the same task-5440965
This update fixes an issue where selecting a work order in the Overview would incorrectly prioritize it in the ShopFloor operations list. The fix uses the correct record identifier ('resId') instead of the internal 'id' to ensure accurate sorting. Additionally, the 'show case' workorder now remains at the top when using pagination on the first page.
Original PR description
Selecting an operation in the Overview makes it the 'show case' and first in the workcenter's operations list. However, acting on the workorder (adding a by-product for example) moves it to another position in the list. This because defineRelevantRecords wrongly uses record.'id' to sort recordsAlreadyInCache (internal data like 'datapoint_<n>' not present in the cache that contains record identifiers). Using the real record identifier 'resId' corrects the sorting operation. We also want the 'show case' workorder selected in the Overview to stay on top when using pagination (not for all pages, only the first one). task: 5028095
This update fixes a test that was intermittently failing due to how Odoo marked inbox messages as read. The change ensures the test waits for the initial message fetch, preventing a common failure scenario. This improves the reliability of the inbox read marking process.
Original PR description
The `Opening thread with needaction messages should mark all messages of thread as read` text composer test ensures that opening a channel marks the related inbox messages as read. However, this test can fail in a non-deterministic fashion. There are two flows that can mark inbox messages as read: fetching the messages or a manual request after opening the channel. The test expects the rpc to be issued, but if the messages are fetched before, it won't happen thus making the test fail. This commit awaits the initial fetch to prevent this issue. As a bonus, the second flow is also tested. runbot-238360 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
This update fixes an issue where the field matching feature in the spreadsheet editor was incorrectly displayed prematurely. Now, field matching options only appear after the user selects both a model and a field, aligning with the standard relational filter experience. This ensures a more intuitive and reliable workflow for users.
Original PR description
## Description Before this commit: - In the selection global filter side panel, field matching was shown immediately, even when the model and field were not selected. - Without a model, field matching cannot be configured correctly, so showing it early had no meaning. - This behavior was inconsistent with relational global filters. After this commit: - Field matching is displayed only after the user selects both model and field. - Once configured, users can set up field matching as expected, similar to the relational global filter side panel. Task: [5477251](https://www.odoo.com/odoo/project/2328/tasks/5477251)
This update addresses a technical issue preventing the correct import of JSONDecodeError from the Requests library. This was caused by a recent change in the Requests package itself. The fix ensures compatibility and prevents errors when using Requests within Odoo addons.
Original PR description
# Description of the issue/feature this PR addresses: Installing `requests==2.25.1` and using the following line of code: from requests.exceptions import JSONDecodeError Script to reproduce it…
# Description of the issue/feature this PR addresses:
Installing `requests==2.25.1` and using the following line of code:
from requests.exceptions import JSONDecodeError
Script to reproduce it
```bash
python3.10 -m pip install -q virtualenv
python3.10 -m virtualenv /tmp/requests_test
source /tmp/requests_test/bin/activate
pip install -q requests==2.25.1
python -c "from json import JSONDecodeError"
python -c "from requests.exceptions import JSONDecodeError"
# ImportError: cannot import name 'JSONDecodeError' from 'requests.exceptions' (/tmp/requests_test/lib/python3.10/site-packages/requests/exceptions.py)
```
<img width="1503" height="738" alt="Screenshot 2026-01-13 at 11 05 36 a m" src="https://github.com/user-attachments/assets/c81d04c3-111c-4fb4-9b7e-f09059b54d3a" />
# Current behavior before PR:
It raises the following error:
ImportError: cannot import name 'JSONDecodeError' from 'requests.exceptions' (python3.10/site-packages/requests/exceptions.py)
It was removed from the following commit in the `requests` package:
https://github.com/psf/requests/commit/db575eeedcfdb03bf31285afd3033e301df8b685
# Desired behavior after PR is merged:
This change fixes this error importing the original exception from `json` package
Also, fixing similar alias imports
Enterprise PR related:
- https://github.com/odoo/enterprise/pull/104202This update resolves an issue that occurred when users clicked the 'Code History' button within Server Actions. The error stemmed from a lack of timezone information in the user's calendar, causing a technical error. This fix ensures the button functions correctly regardless of the user's timezone settings.
Original PR description
This error occurs when clicking the `Code History` button in Server Action. Steps to reproduce: - Search `Server Actions` > Open any server action - Change `Code` and Save > Click `Code History` button Traceback: `AttributeError: 'bool' object has no attribute 'upper'` This error occurs when the `Code History` button is clicked and, at that point, the user’s timezone is `False` because it is not set in the user’s calendar. [1]- https://github.com/odoo/odoo/blob/54681272e9f00a171fe49f690979e2a8353ff5fb/odoo/addons/base/models/ir_actions.py#L515 sentry-7167683304 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a visual inconsistency in the Odoo website builder where the 'Option List' label was incorrectly centered. The change restores the standard alignment for labels in the builder sidebar, ensuring a consistent and professional appearance. This resolves a minor aesthetic issue that could have impacted user experience.
Original PR description
### Issue: The `hb-row-label` class shows inconsistent behavior in the builder sidebar. The 'Option List' label appears centered rather than following the standard alignment. In addition, the…
### Issue: The `hb-row-label` class shows inconsistent behavior in the builder sidebar. The 'Option List' label appears centered rather than following the standard alignment. In addition, the alignment of nested options within the builder sidebar is marginally misaligned. ### Steps to Reproduce: - Open the website and switch to edit mode. - Drop a Form snippet onto the page. - Add a new field and set its type to 'Multiple Checkbox'. - In the builder sidebar, notice that the 'Option List' label is centered. ### Reason: This [commit](https://github.com/odoo/odoo/commit/2c90e135a30b5810be0e2796154d85a918fbe303) changed the `align-self` property of the `hb-row-label` class from `baseline` to `center`. That change was intended to fix alignment issues for nested options inside popovers. However, since `hb-row-label` is also used globally, this caused misalignment in the builder sidebar. ### Fix: Apply a separate alignment rule for popover usage while keeping the default `hb-row-label` alignment set to baseline. This restores the correct label positioning in the builder sidebar (refer img 1) and preserves the improved alignment inside popover (refer img 2). ### Visual Changes: <img width="1866" height="622" alt="image" src="https://github.com/user-attachments/assets/b243fbf3-2f7f-4942-b1e4-7de7c5eafe0f" /> <img width="1843" height="688" alt="image" src="https://github.com/user-attachments/assets/562dfc33-43f9-45cd-b3ce-efec32e3cf45" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix addresses a technical error that occurred when generating DIAN invoices. A default empty document was causing a system crash. The update now allows for invoices without attachments, preventing the template from attempting to parse missing data and resolving the issue.
Original PR description
Since this fix: ba24b48 , a default empty document contains `<Note>No xml</Note>` was created when posting bills. However, the `l10n_co_dian.report_invoice_document` template attempts to parse this document for DIAN values. Because these values are missing from the empty document, a traceback occurs. In this commit, we fallback to standard template when the empty document exists. opw-5246912
This update corrects a visual issue where text within table cells appeared misaligned due to a default bottom margin applied to the last element in the cell. The fix removes this margin, ensuring consistent vertical alignment of content within tables on the website. This improves the overall appearance and usability of Odoo websites.
Original PR description
Problem: Table cells had extra space because the last element (e.g. a `<p>`) kept its bottom margin. This caused the cell content to appear misaligned vertically. Solution: Remove the bottom margin on the last element inside table cells. This is a backport of 3048f1a2447d1d5089defa055c858adb1e915c91. Steps to reproduce: - Website. - Add a table in the footer. - Add text in a cell. - Select "Paragraph" as block from the toolbar. - Align the cell content. - Observe the content is not vertically aligned. opw-5412426 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the Odoo system crashed when generating UUIDs in non-secure environments. The code has been updated to use a compatible alternative function, ensuring stability across all Odoo deployments. This change addresses a potential technical limitation without impacting core functionality.
Original PR description
### [FIX] web: allow 'uuid' in non-secure contexts Before this commit, the `uuid` string helper crashed when used in non- secure contexts. This was due to it using `crypto.randomUUID()`, which is only available in secure contexts. Although discouraged, it should be possible to run Odoo in these contexts, and as such the function has been changed to use `crypto.getRandomValues()`. There is no test, as the CI runs in secure contexts anyway, and the `uuid` function itself is already thoroughly tested. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a test failure related to how dates and times are displayed in Chrome. A recent change introduced a regular space instead of a non-breaking space, causing compatibility issues. The update ensures consistent date/time formatting across different Chrome versions.
Original PR description
Apparently somewhere in the datetime patterns the space between time and A/P mark has been updated from a narrow non-breaking space to a regular space. Make the code cross-version compatible.
This update fixes an issue where product names on VAT invoices were being incorrectly combined without spaces, making them unreadable. The change adds a space to separate the name and description, ensuring invoices comply with API specifications and maintain proper formatting for processing. This improves the accuracy and readability of VAT reports.
Original PR description
Before: SInvoice was stripping newlines from the `itemName` field. Since we were directly using `line.name` (which contains a `\n` between product name and description), the content ended up concatenated without any separation. After: Now we replace the newline with a space before sending the value, so the name and description remain readable once processed by SInvoice and set limit to 500 characters as per API specs. task-5498120 Forward-Port-Of: odoo/odoo#243994
This update resolves an issue where the website editor could fail due to timing problems when opening. By ensuring the editor waits for the iframe to fully load, the system now provides a more reliable and consistent editing experience. This prevents unexpected errors and improves user confidence.
Original PR description
Steps to reproduce: 1. Set network speed to 3G 2. Create website Page from the systry new menu 3. click on edit button You'll face the traceback. The website editor could try to open before the iframe finished loading, leading to non-deterministic behavior. This commit ensures the editor initializes only after the iframe load event, making the edit action consistent and reliable. Erlier fixed was not covering the all the cases. PR: https://github.com/odoo/odoo/pull/238054 runbot-233039 Forward-Port-Of: odoo/odoo#243256
This update resolves an issue where tables inserted within the To-Do module appeared after the existing text instead of before it. The fix streamlines the table insertion process by centralizing the logic within the DomPlugin, ensuring tables are correctly positioned and the cursor is placed in the expected location. This improves the overall user experience when creating tables within the HTML editor.
Original PR description
### Steps to Reproduce : - Open To-Do and type some text. - Place the cursor at the start of the block. - Insert a table. (e.g.: /table) - The table appears after the text instead of before it. ### Purpose of this PR: - Table insertion logic was previously duplicated inside TablePlugin, where it tried to manually split text and inline nodes before inserting the table. However, this responsibility is now correctly handled by `DomPlugin.insert()`, which already: - deletes the current selection if needed. - splits text and inline nodes safely. - handles block boundaries and unsplittable elements. - normalizes the DOM after insertion. - places the cursor at a valid position. task-5480759 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244567 Forward-Port-Of: odoo/odoo#243242
This update resolves a minor performance issue within Odoo's spreadsheet functionality. Specifically, it optimizes how ranges are handled, leading to faster loading and responsiveness when working with large spreadsheets in the quality control and sales management modules. This ensures a smoother user experience.
Original PR description
…s args See https://github.com/odoo/o-spreadsheet/commit/6533266efa Task: 5095364
This update resolves an issue where GS1 barcodes triggered a validation error, preventing users from scanning products correctly. The fix allows the system to gracefully handle GS1 barcodes that are misinterpreted as dates, ensuring consistent product scanning functionality within the Odoo Enterprise system.
Original PR description
Steps to reproduce: - Activate the GS1 nomenclature - Create a product with barcode: 15099590483921 - Scan the product from the Barcode app main menu Problem: A ValidationError is raised: "A GS1…
Steps to reproduce: - Activate the GS1 nomenclature - Create a product with barcode: 15099590483921 - Scan the product from the Barcode app main menu Problem: A ValidationError is raised: "A GS1 barcode nomenclature pattern was matched. However, the barcode failed to be converted to a valid date." Explanation: GS1 barcodes must follow a strict nomenclature based on well-defined rules. For example, a GS1 product barcode should start with the Application Identifier 01 followed by 14 digits. The GS1 parser processes the barcode rule by rule and applies the first matching rule. In this case, the barcode 15099590483921 is interpreted as a date because it starts with "15", which corresponds to a GS1 Application Identifier for a date. As a result, the parser attempts to convert the first six digits into a date and raises a ValidationError. Solution: Catch the ValidationError raised during GS1 date parsing in main_menu and explicitly reset parsed_results to False, allowing the normal main menu resolution logic to continue. This prevents GS1 parsing errors from blocking valid barcodes and ensures that product, picking, or location detection still works as expected. opw-5357611 Forward-Port-Of: odoo/enterprise#104641
This update fixes an issue where Odoo was creating duplicate vendor contacts when receiving invoices with slightly different VAT number formats (with or without dots). Now, invoices with the same VAT number, even with variations in formatting, will be correctly linked to the same contact, streamlining our accounting processes.
Original PR description
Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number Current behavior before PR: If you have two incoming vendor bills (over a period of time)…
Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number Current behavior before PR: If you have two incoming vendor bills (over a period of time) where the first bill has these details: - VAT number: `BE0477472701` - Name: `Odoo` And the second bill (e.g three months later) has these details: - VAT number: `BE0477.472.701` - Name: `Odoo S.A` Odoo will do something interesting and will create a second new contact. The reason is because the fallback on `name` from `res.partner` fails (since "Odoo S.A" is not equal to "Odoo". However, the `vat` number matching also fails! Since the VAT number "BE0477.472.701" is not identical to "BE0477472701". Throughout Odoo however VAT numbers are parsed and stored without dots in it. The function `_retrieve_partner_with_vat` however is an exception because the `vat` number here is sanitized for spaces but not for dots. Because of the combination of no exact match on neither `name` nor `vat` it now creates a second contact although the VAT number is technically the same. Desired behavior after PR is merged: Both an incoming vendor bill with `0477.472.701` and `0477472701` match to the same contact even if there are dots in it and if the name of the company is different. P.S: please find two sample XML's here: [sample_odoo_sa_bill.xml](https://github.com/user-attachments/files/24718225/sample_odoo_sa_bill.xml) [sample_odoo_bill.xml](https://github.com/user-attachments/files/24718226/sample_odoo_bill.xml) If you upload both back to back on a default V19 you will see two contacts. After this code change you will only see one contact where both bills are mapped to the same contacts. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244572
This update resolves a technical issue preventing users with the Romanian language pack installed for the l10n_ro_edi_stock module from accessing the settings app. The fix addresses a mismatch between an XPath used to update a view and translated text, ensuring proper functionality in the Romanian language.
Original PR description
**Issue**: When the module `l10n_ro_edi_stock` is installed and Romanian is the selected language, accessing the settings app causes a traceback. **Steps to reproduce**: - Install the module…
**Issue**: When the module `l10n_ro_edi_stock` is installed and Romanian is the selected language, accessing the settings app causes a traceback. **Steps to reproduce**: - Install the module `l10n_ro_edi_stock` - Select a Romanian company - In Profile > My Preferences > select Romanian language - Try to access the settings -> A traceback occurs **Cause**: The error is caused by this XPath: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/addons/l10n_ro_edi_stock/views/res_config_settings_views.xml#L9C13-L11C21 Specifically, the `'select the option'` part. The XPath tries to replace this line in the parent view: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/addons/l10n_ro_edi/views/res_config_settings_views.xml#L39 but fails to find it because the source text has already been translated at that point, so `'select the option'` no longer matches: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/odoo/tools/template_inheritance.py#L154 **Solution** Only rely on strings that are translation-invariant. opw-5490346 Forward-Port-Of: odoo/odoo#244313
This update ensures that optional product images are only shown when the system is configured to display them. Previously, images were always shown, even when disabled. Now, a placeholder is used if no image is available, providing a cleaner and more consistent user experience for optional products.
Original PR description
Before this commit: =================== - When the `Show product images` setting was disabled, the optional products UI still displayed product images. - If an optional product did not have an image, the UI displayed the image's alt text - Also when the product don't have image, the combo popup and product card just display the product name. After this commit: ================== - Optional product images are displayed only when the `Show product images` configuration is enabled. - If the optional product doesn't have an image, we will display an image placeholder instead of alt text. - If there is no product image, the combo popup and product card will display the image placeholder. Task: 5480181 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243222
This update corrects an issue where registration emails for events were displaying duplicate headers and footers. The fix removed a redundant email layout setting, ensuring a cleaner and more professional email experience for registered attendees. This improves email deliverability and user perception.
Original PR description
**Steps to reproduce:** - Go to Event module - Go to an open event - Register for the event - Go to the Attendees of the event - On the attendee record, click `Send by Email` - The received email shows twice the header and footer **Issue:** Encapsulating notification layout was applied with `default_email_layout_xmlid` but the main template used is `event_registration_mail_template_badge` which already has its own header and footer. **Fix:** Removed the `default_email_layout_xmlid` opw-5032767 Forward-Port-Of: odoo/odoo#236667
This update fixes a bug in the payroll system's name formatting for Swiss employees. Previously, last names were used before first names, which is now corrected to ensure accurate legal name reporting. The change also includes updated test data to reflect this improved formatting.
Original PR description
* Fix _compute_l10n_ch_legal_name method to correctly assign first_name and last_name from employee name (was previously reversed) * Update all SwissDEC test data to use correct "FirstName LastName" format instead of "LastName FirstName" to match the corrected computation logic task-5102851 Forward-Port-Of: odoo/enterprise#104067 Forward-Port-Of: odoo/enterprise#95252
This update fixes an issue where the cookie consent wasn't being saved after changing the 'I agree' button style in the website settings. The change ensures that when the button is styled with the primary button style, the consent is properly recorded, preventing the cookie bar from reappearing after accepting cookies.
Original PR description
Steps to reproduce: =================== 1. Enable the Cookies Bar in website settings. 2. Go to the website and enter Edit mode. 3. Select the Cookie Bar and change the button "I agree" style shape…
Steps to reproduce: =================== 1. Enable the Cookies Bar in website settings. 2. Go to the website and enter Edit mode. 3. Select the Cookie Bar and change the button "I agree" style shape to "Default" (this applies the `.btn-primary` class). & Save 4. Accept the cookies & refresh -> The cookie bar appears again because the consent was not saved. Cause: ====== The `CookiesBar` widget inherits from the generic `Popup` widget. The `Popup` class defines a default behavior for elements with the `.btn-primary` class: clicking them triggers `onBtnPrimaryClick`, which closes the popup. By default, the cookie bar button uses `.btn-outline-primary`, avoiding this behavior. However, when the user changes the style to "Default", the button receives the `.btn-primary` class. Consequently, the parent `Popup` handler is triggered. It closes the modal prematurely, interrupting the `CookiesBar`'s specific logic (specifically `onAcceptClick`),So onHideModal won't be called inside the function, and as a result, the user's consent cookie is never written. Solution: ========= Override the event to avoid side effects on hide. opw-5484578 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243562
This update resolves a technical issue that was preventing the employee version timeline from automatically saving in the Odoo system. The fix involved replacing dynamic date usage with a more reliable testing method (freeze_time). This ensures the timeline updates correctly and consistently, improving the user experience.
Original PR description
As runbot faketimes test fail because the usage of dynamic dates now the test uses freeze_time Task#5717031 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244540
This update fixes an issue where the IoT driver was incorrectly adding duplicate IDs, slowing down performance when actions took longer than 6 seconds. The change now ensures IDs are only added to the cache when actions complete successfully, improving overall system responsiveness and reliability.
Original PR description
If an action takes a long time to execute (>6s), then we don't add the unique id during this time as the action didn't finish. As it exceeds 6 seconds, we also send one through websocket, that isn't filtered as duplicate as the action id isn't set yet in the `_recent_action_ids` cache. To avoid this, we add the action id to the cache, then execute the action and remove the id from the cache if there is an exception. Forward-Port-Of: odoo/odoo#244953
This update enhances the reliability of connections to our IoT devices. By using the device's IP address instead of its domain name when Location Name Association (LNA) is active, we've eliminated potential issues caused by DNS resolution delays. This ensures smoother and more consistent data transmission from the IoT boxes.
Original PR description
In order to avoid DNS resolution issues, we now parse the domain to get the IP of the IoT Box if LNA is enabled. Forward-Port-Of: odoo/odoo#244968