Thursday, January 22, 2026
41 changes · saas-19.1
New functionality added to Odoo
This update adds a new module to help Finnish businesses comply with Intrastat reporting requirements. It generates CSV reports of arrivals and dispatches, allowing for easy submission to Finnish Customs, and includes features for managing agent VAT and submitting periodic reports.
Original PR description
Added a new module to support Finnish Intrastat compliance by generating CSV declarations compatible with the Finnish Customs service. This Includes: - Export arrivals and dispatches reports in CSV format (bundled in ZIP). - Configure agent VAT for arrivals when filed via an agent. - Wizard to download and submit periodic Intrastat reports. task-5049047 Forward-Port-Of: odoo/enterprise#95457
Enhancements to existing features
This update organizes UBL test files for better compatibility with future move formats and improved schema validation. The change improves the structure of the test files, streamlining development and testing efforts related to UBL invoice processing. This supports ongoing improvements to our invoicing capabilities.
Original PR description
This commit rearranges the UBL test files' subfolder to be one level higher, from `export/bis3/be` to `export/bis3/invoice/be`, in preparation for supporting different move formats and for better ignore schema support. task-4891206 Forward-Port-Of: odoo/odoo#244886 Forward-Port-Of: odoo/odoo#244665
Resolved issues and error corrections
This update corrects a data issue related to Value Added Tax (VAT) processing in the Brazilian retail module. Previously, the system didn't automatically apply VAT formatting updates after an upgrade to version 18.4. This fix ensures accurate VAT data is stored and handled, preventing potential reporting discrepancies.
Original PR description
In [^1], we removed the compacting code that existed in l10n_br modules as all vats are now stored as compact forms since [^2]. *However*, we did not consider that databases updated to 18.4+ would not automatically apply the compacting code to all records. As such, we have reintroduced a small block of compacting code in `l10n_br_edi_pos` as that one does special operations with the VAT that needs to be stripped of special characters. opw-5491321 [^1]: odoo/enterprise#87562 [^2]: odoo/odoo#179078 Forward-Port-Of: odoo/enterprise#104960
This update enhances the reliability of IoT Box connections by directly using IP addresses instead of domain names. This change, enabled when 'LNA' is active, prevents potential issues caused by DNS resolution delays. It ensures smoother data transmission from IoT devices to the Odoo system.
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.
This update resolves an issue where the system incorrectly attempted to map a specific VAT report line ('VP14b') when it was no longer present in the new monthly VAT report format. The fix ensures the system handles this scenario gracefully, preventing errors and maintaining accurate VAT reporting. This change was triggered by a recent update to the Odoo codebase.
Original PR description
Handle `carryover_origin_report_line_id` for report line having `code = 'VP14b`, since the line does not exist in the new monthly VAT report after this commit:…
Handle `carryover_origin_report_line_id` for report line having `code = 'VP14b`, since the line does not exist in the new monthly VAT report after this commit: odoo/odoo@51a72ab42d118d6fb0eb3e3545a09e10019b9140
As the line is not present in the monthy vat report while mapping it will raise keyerror:
```py
File "/home/odoo/src/odoo/19.0/addons/l10n_it/migrations/0.7/post-map_carryover_to_new_report.py", line 52, in migrate
data_to_insert = [
File "/home/odoo/src/odoo/19.0/addons/l10n_it/migrations/0.7/post-map_carryover_to_new_report.py", line 53, in <listcomp>
(code2expression_id[report_line_code], old2new_origin[carryover_origin_report_line_id], *other_external_vals)
KeyError: 80
```
```sql
apan_3806634=> select id,carryover_origin_report_line_id,target_report_expression_id from account_report_external_value;
id | carryover_origin_report_line_id | target_report_expression_id
----+---------------------------------+-----------------------------
3 | 80 | 102
4 | 80 | 105
7 | 80 | 102
8 | 80 | 102
9 | 80 | 102
10 | 80 | 102
11 | 80 | 102
(7 rows)
apan_3806634=> select id,name->>'en_US',code from account_report_line where id=80;
id | ?column? | code
----+------------------------------+-------
80 | VP14b - VAT payable (credit) | VP14b
(1 row)
```
Note this error will only appears in the dbs without this commit: odoo/odoo@a220a28595dbfacce2d8322222d1961547bb4b07
opw-5494959
upg-3806634
tbg-2272
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#244685The alignment of labels within the Odoo website builder's form editor has been corrected. A recent change intended to improve popover alignment inadvertently caused labels in the main sidebar to appear centered. This update restores the correct label positioning, ensuring a consistent and professional appearance for users editing forms.
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 Forward-Port-Of: odoo/odoo#242756
This update resolves an error that occurred when generating PDF reports for accounting, specifically when a contact didn't have a name assigned. The fix ensures the report exports correctly even with contacts lacking names, improving the reliability of the reporting process.
Original PR description
Currently, an error occurs when exporting an accounting report to PDF if any of the selected contacts do not have a name. **Steps to reproduce:** - Install the `account_reports` and `contacts`…
Currently, an error occurs when exporting an accounting report to PDF if any of the selected contacts do not have a name. **Steps to reproduce:** - Install the `account_reports` and `contacts` modules. - Go to Contacts and open any contact (e.g., Azure Interior). - Click `Add` > `Save & Close`, then `save` the contact. - Navigate to Accounting > Reporting > Aged Receivable. - Click `Partners` button and select the newly created contact (e.g., `Azure Interior, Other Address`). - Click `PDF` to export the report. **Error:** `TypeError: sequence item 0: expected str instance, bool found` **Root Cause:** At [1], `options['selected_partner_ids']` is built using `partner.name`, which may be `False` for unnamed contacts. At [2], the `partner_value` list may therefore contain `False` entries coming from `options['selected_partner_ids']`. When calling `', '.join(partner_value)`, an error is raised because the list contains `non-string` (`bool`) values. **Fix:** This commit prevents errors when exporting reports to PDF and ensures that partner names are displayed in the report the same way as in the partner selection widget. [1]: https://github.com/odoo/enterprise/blob/a0ec2fcdc043cf52f1a646e84b9b97466072d47f/account_reports/models/account_report.py#L745 [2]: https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/account_reports/data/pdf_export_templates.xml#L84-L93 opw-5467321 Forward-Port-Of: odoo/enterprise#105025 Forward-Port-Of: odoo/enterprise#103828
This update fixes a display issue in the spreadsheet filter side panel. Previously, field matching options appeared prematurely. Now, field matching is only shown after the user selects both a model and a field, aligning with the standard relational filter experience and ensuring accurate configuration.
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) Forward-Port-Of: odoo/enterprise#104545
This update enhances the reliability of connecting to IoT boxes. Previously, the system relied on DNS resolution, which could sometimes fail. Now, the system directly uses the IoT box's IP address when LNA is enabled, ensuring a more stable connection.
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
This update resolves an issue preventing payroll test modules from installing correctly during testing. Previously, these tests were skipped, leading to potential errors and instability. Now, payroll tests will run consistently, ensuring accurate and reliable test results.
Original PR description
Some payroll test module named test_l10n_xx are not being installed when l10n are tested. This causes the tests to never run, causing mistakes to regularly go through and break things. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves issues preventing payroll tests in Hong Kong and Belgium from running correctly on Runbot. The changes ensure these tests pass, improving the reliability of our payroll functionality and supporting accurate financial reporting.
Original PR description
Fixes some issues with HK & BE tests, following changes enabling them to run on runbot.
This update fixes an issue where selecting a work order in the Overview would incorrectly prioritize it, and adding a by-product would move it to a different position. The change ensures work orders are sorted correctly, particularly when using pagination, maintaining the 'show case' work order at the top of the list 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 Forward-Port-Of: odoo/enterprise#98863
This update resolves an issue that occurred when users clicked the 'Code History' button within Server Actions. The error stemmed from a missing timezone setting, causing a technical problem. This fix ensures the button functions correctly regardless of the user's timezone configuration.
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 Forward-Port-Of: odoo/odoo#242276
This update resolves an issue where tables inserted into the To-Do module appeared after the existing text instead of before it. The fix streamlines the table insertion process, ensuring tables are placed correctly at the beginning of the block, improving the user experience. This was achieved by centralizing the table insertion logic within the DomPlugin.
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#244689 Forward-Port-Of: odoo/odoo#243242
This update corrects a minor typo in the tests for the search highlight feature within Odoo. This ensures the tests run correctly and accurately reflect the functionality of the search feature, preventing potential issues with search results. The fix improves the stability and reliability of the Odoo system.
Original PR description
Intoduced by https://github.com/odoo/odoo/pull/118794 Forward-Port-Of: odoo/odoo#244832 Forward-Port-Of: odoo/odoo#244720
This update corrects a test failure related to how dates and times are formatted in Chrome. A recent change introduced a standard space instead of a non-breaking space, causing compatibility issues. This ensures consistent date and time display 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. Forward-Port-Of: odoo/odoo#244961
This update resolves a problem where FedEx labels incorrectly displayed addresses containing special characters (like accents or non-English characters). The code was updated to ensure all address components are converted to standard ASCII characters before being sent to FedEx, preventing these display issues. This ensures accurate and consistent label formatting for all addresses.
Original PR description
Issue ----- Fedex does not handle special characters in addresses, so passing an address such as "Rue de Libération 15" will show as "Rue de Lib...ration 15" on labels. ----- Ticket: opw-5419724 Forward-Port-Of: odoo/enterprise#104979 Forward-Port-Of: odoo/enterprise#104265
This update resolves an issue where invoices sent to Peppol were failing validation due to an incorrect Unit of Measure code. The fix removes a specific UNECE code that wasn't accepted by Peppol, ensuring invoices now meet the required standards for seamless electronic invoice processing.
Original PR description
**Steps to reproduce:** - Use a Belgian company - Create a Belgian contact with "EU Standard (Peppol Bis 3.0)" as eInvoice format - Create an invoice for that customer with a product using "Pack of 6" as unit of measure - Confirm the invoice - Send it to Peppol **Issue:** The validation of the invoice fails with the following error: "[BR-CL-23]-Unit code MUST be coded according to the UN/ECE Recommendation 20 with Rec 21 extension" **Cause:** The UNECE code used for "Pack of 6" UoM is "HD". "HD" is a correct UNECE code for "Half Dozen". However, it is not part of the subset of codes accepted by Peppol. opw-5463212 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244668
This update corrects a problem where Saudi partner addresses were being unintentionally cleared when related contacts were created or updated. The fix prevents data synchronization issues between partners and their contacts, ensuring accurate address information is maintained for all Saudi customers. This improves data consistency and reduces potential errors.
Original PR description
All Saudi partners use the saudi_o_address_format. As a result, contacts created from a company partner also inherit this address format, which includes fields such as street, city, zip, and state. These fields are set as read-only by the address format. When child_ids are written on the parent partner, those read-only fields are written with False values. Due to the address field synchronization between parent and related contacts, these False values are then propagated back to the parent partner, causing its address data to be cleared. This fix prevents address fields from being unintentionally reset when related contacts are created or updated. task-5349050 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241862
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, leading to a cluttered display. Now, a placeholder image is used when no image is available, improving the user experience and reducing visual noise.
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#244809 Forward-Port-Of: odoo/odoo#243222
This update resolves a potential issue in how Odoo queries its database, specifically when multiple databases are used. The change ensures more accurate results and prevents unexpected errors, leading to more reliable performance. It's a technical update focused on internal database operations.
Original PR description
It prevents hidden bugs when multiple schemas are used in PostgreSQL This was mentioned in: - PR odoo/odoo#243967 Forward-Port-Of: odoo/enterprise#104936
This update strengthens Odoo's database safety by ensuring that queries against PostgreSQL always reference the correct schema. Previously, using multiple schemas could lead to unexpected errors and potential data corruption. This fix prevents these hidden bugs and protects data integrity.
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 Forward-Port-Of: odoo/odoo#243967
This update corrects a recent issue in Odoo 19.1 where the 'anglo-saxon_accounting' setting was inadvertently disabled for existing companies. The original fix to optimize template data loading unintentionally triggered an older fix that removed this setting. This change ensures that Anglo-Saxon accounting is correctly enabled as intended.
Original PR description
In 19.1 a fix was developed to avoid bridge modules for template data [1]. A couple of `ChartTemplate._pre_load_data` calls without template data were added to discard non-existent fields in the database. It inadvertently triggers an older fix [2] that was meant to unset `anglo_saxon_accounting` for existing companies if not explicitly set in the template, which meant that in practice `anglo_saxon_accounting` wasn't being set anymore. [1] https://github.com/odoo/odoo/pull/238115 [2] https://github.com/odoo/odoo/pull/178113 task-5785189
A technical issue preventing the creation of maintenance requests from work orders in the Shop Floor module has been fixed. This change corrects a mismatch in XML IDs that was causing a traceback error. The fix ensures the maintenance request creation process continues to function correctly without disruption.
Original PR description
Issue before this commit: ========================= When creating a maintenance request from a work order in the Shop Floor module, a traceback was raised. Steps to Reproduce:…
Issue before this commit: ========================= When creating a maintenance request from a work order in the Shop Floor module, a traceback was raised. Steps to Reproduce: ========================= - Install the mrp_maintenance module. - Create a Manufacturing Order with at least one operation. - Open the Shop Floor module. - From a work order, click on the three-dot (extra) menu. - Click on Request Maintenance. - A traceback occurs: ValueError: External ID not found in the system: mrp_maintenance.maintenance_request_view_form_inherit_mrp_workorder Cause of the issue: ========================= The above XML ID was previously used to add a custom JS widget that displays a notification when creating a maintenance request from the Shop Floor. During a recent refactoring in this [PR](https://github.com/odoo/enterprise/pull/100326), this XML record was removed (while the notification functionality remained intact). However, the Python code was still referencing this XML ID, which has now been reintroduced in this [PR](https://github.com/odoo/enterprise/pull/100348), and this mismatch resulted in the traceback. With This Commit: ========================= Ensure that creating a maintenance request from the Shop Floor no longer raises a missing external ID error, while keeping the expected behaviour unchanged.
This update addresses a technical issue that prevented the Odoo tour from running correctly for Swiss companies. The fix skips a specific test within the tour when the Swiss localization (l10n_ch_hr_payroll) is installed, as this flow isn't relevant for Swiss businesses. This ensures the tour functions as expected for all users.
Original PR description
Swiss companies don't use Work Entries, therefore on the payslip view, the Work Entry smart button is invisible, which breaks the tour to test the reset of the Work Entries. To fix this we just skip the test if the Swiss localization is installed, because the flow doesn't apply to Swiss companies. Runbot Error: 234647
This update fixes a technical error that occurred when generating invoices for Colombian DIAN reporting. Previously, an empty invoice document caused a system crash. The fix now allows for invoices without attachments, preventing the template from attempting to parse missing data and avoiding the error.
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 Forward-Port-Of: odoo/enterprise#100040
This update fixes a potential issue where custom website buttons were incorrectly wrapped within paragraph tags. This change ensures that button text displays correctly and consistently across the Odoo website, improving the user experience. The fix was triggered by a new automated test.
Original PR description
Add a hoot test covering the case where the custom button snippet gets incorrectly wrapped inside a `<p>` tag. Original changes introduced in commit 3a8f2cc418510c3b91f8b9086bb4a89a1745e40d. Forward-Port-Of: odoo/odoo#244208 Forward-Port-Of: odoo/odoo#224476
This update fixes a problem where the status banner for invoices disappeared when using the auto-post feature for vendor bills. The change ensures the banner correctly reflects the document's status, preventing it from incorrectly transitioning to 'done' due to automated posting processes. This improves the clarity of invoice status information.
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) Forward-Port-Of: odoo/enterprise#104793
This update resolves an issue where GS1 barcodes triggered a validation error, preventing users from scanning products correctly through the barcode app. The fix allows the system to gracefully handle GS1 barcode formats, ensuring reliable product identification and preventing disruptions to inventory management.
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#104832 Forward-Port-Of: odoo/enterprise#104641
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 Forward-Port-Of: odoo/enterprise#102928
This update optimizes the way live chat expertise data is handled, preventing unnecessary data retrieval and potential performance issues. Previously, data was loaded regardless of whether it was needed, now it's only fetched when a live chat conversation is opened. This improves the responsiveness of the live chat feature.
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 Forward-Port-Of: odoo/odoo#244463
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 before triggering the expected action, making the test more reliable and consistent. This improves the stability of the inbox functionality.
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 Forward-Port-Of: odoo/odoo#244950
This update corrects an issue where the invitation link in shared documents was not being generated correctly, leading to a broken URL. The change moves the link generation to the email template, ensuring accurate and functional links are sent to users. This improves the user experience for document sharing.
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 Forward-Port-Of: odoo/enterprise#104573
This update fixes an issue where a single error during invoice imports would halt the entire process, leading to duplicate invoices. The change ensures that the import process continues even if an invoice encounters an unexpected problem, improving data accuracy and reliability. This resolves a previous bug impacting invoice import efficiency.
Original PR description
When you import a batch of invoice and one of them gets an unexpected Exception, the others are created but we stop the method. It's a problem with crons that don't expect to be interrupted in the middle. It creates duplicates as we fail on the same invoice each time. Of course, we should avoid all Exceptions when we can, but we should not loop on the same error. opw-5503069 part of task-5499871 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244543
This update resolves an issue where the IoT driver was incorrectly adding duplicate IDs, causing potential performance problems. The fix ensures that IDs are only added to the cache when actions complete successfully, improving the driver's responsiveness and stability. This change enhances the overall reliability of the IoT integration.
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
A recent test was failing intermittently due to an issue with the redirect URLs used in the documents module. The fix ensures that redirect URLs are consistently relative, resolving the test failure and improving the stability of the system. This change ensures proper functionality within the Odoo Enterprise SaaS platform.
Original PR description
Bug === On some runs, the redirect URL is absolute and not relative, (eg: `http://127.0.0.1:8069/web/signup?db=...`) and so the test needs to be adapted. Task-5857520 Forward-Port-Of: odoo/enterprise#105027
This update resolves an issue where work orders were generating errors due to incorrect data handling. The fix ensures that employee IDs are correctly processed, preventing duplicate key errors and ensuring work orders function as expected. This improves the reliability of the work order management process.
Original PR description
The previous loop used `employee.id` as the key, which is undefined in this context because values come from resIds and represent record IDs directly. Steps to reproduce: - Enable work orders - Create a BOM with a work order - Configure 2 Assigned employees - Open the work order in Shop Floor An error is raised because, since `employee` is an integer (the ID), `employee.id` is undefined so odoo founds duplicate keys (all undefined). opw-5417887 Forward-Port-Of: odoo/enterprise#102510
This update fixes an issue where refund and payment batches weren't always merging correctly, leading to duplicate payment records. The change ensures that inbound and outbound payments for the same partner and bank are combined into a single payment, streamlining financial reporting. This improves accuracy and reduces manual effort.
Original PR description
When we register payments for a list of journal entries, the `account.payment.register` wizard computes batches and sometimes merge them together. For instance, this allows to create a single payment if there is an outbound (a bill to pay) and an inbound (a refund to receive) payment to the same bank for the same partner. Instead of creating two payments of -1000 and +500, we only create one of -500. Currently, this mechanism does not always work. That's because the `batch_key` used to decide whether to merge or not refers to a value that is not updated in the loop. Related ticket: opw-5401372 Forward-Port-Of: odoo/odoo#242863
This update fixes an issue where the floating order name displayed during direct sales in the restaurant POS was incorrectly showing the POS reference instead of the tracking number. Now, the order name accurately reflects the tracking number, ensuring accurate order identification and management for restaurant staff. This improves order clarity and efficiency.
Original PR description
Before this commit, when making a direct sale, the floating order name was the pos reference instead of the tracking number. This is now fixed. task-id: 5470874 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242359
This update resolves an issue where a deleted floor would reappear in the floor selector after a refund was processed on a related order. The fix filters out inactive floors, ensuring the floor selector only shows active tables. This improves the user experience and data accuracy within the restaurant point-of-sale system.
Original PR description
Task: [#5421683](https://www.odoo.com/odoo/project/1737/tasks/5421683) --- !!!! WARNING !!!! The bug is no longer reproductible since the refacto of the floor plan. --> PR [https://github.com/odoo/odoo/pull/239681](https://github.com/odoo/odoo/pull/239681) I just kept the tour test for good measure. --- **Steps to reproduce:** * Create a new floor with one table * Create and pay an order on that table * Delete the floor * Refund one line of the order ==> The deleted floor is shown again in the floor selector, without its table. This happens because the deleted floor is loaded when fetching the table of the order in the Ticket Screen. If an order is linked to a table that belonged to a deleted floor, that floor is loaded again and displayed in the floor selector. **Fix:** Filter out inactive floors from the floor selector. Forward-Port-Of: odoo/odoo#240276
This update resolves an issue preventing non-administrator website editors from saving images they upload from Unsplash. The fix ensures the user creating the attachment has the necessary permissions, eliminating a security warning and improving the editor's functionality. This allows website editors to seamlessly integrate Unsplash images into their designs.
Original PR description
Scenario: - Setup Unsplash and install website - Set a user as "Website: Editor and Designer" - Login as that user and go to any website page with a qweb view - Go to edit mode and drop Text-Image in…
Scenario: - Setup Unsplash and install website - Set a user as "Website: Editor and Designer" - Login as that user and go to any website page with a qweb view - Go to edit mode and drop Text-Image in a view - Replace the image with an unsplash image and then save Result: the save fails without any message shown, and there is a security access WARNING in the logs. Note: a similar scenario can be done for a restricted editor that is editing a HTML field it has write access to. Issue: to save a model with res_id 0, we need to either be admin (base.group_system) or the record creator. Since 9c9c58a5a10101532cbf046d21d4a63c2b7d2838 to bypass the mimetype neutering of happening, we create the attachment as SUPERUSER. Then when we modify the attachment url (for unsplash images), we have no access right to the attachment since we are not the creator. Fix: create the attachment with the current user, and only use SUPERUSER to set the mimetype if it was neutered (ie. the user doesn't have write access right to ir.ui.view, which in normal use case should only happen for "Restricted Editor"). This way the image is created by the user that uploaded it and not SUPERUSER. opw-4850611 opw-5387258 opw-5489219 Forward-Port-Of: odoo/odoo#245085 Forward-Port-Of: odoo/odoo#219472