Daily updates from Odoo
Thursday, January 22, 2026
115 changes
36 changes
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
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.
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 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
7 changes
Enhancements to existing features
This update enhances the user experience by adding a cursor pointer to the headers of statement summaries within the accounting module. This allows users to easily navigate and explore their financial data more efficiently. It's a simple change designed to improve usability.
Original PR description
This improves the user experience by indicating that the headers are clickable. No task ID Forward-Port-Of: odoo/enterprise#105023
Resolved issues and error corrections
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 that reports now function correctly even with contacts lacking a name, 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 resolves a problem where FedEx labels incorrectly displayed addresses containing special characters (like accented letters). The code has been updated to ensure all addresses are converted to ASCII characters before being sent to FedEx, preventing display issues on labels. This ensures accurate and consistent address formatting for shipments.
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 addresses a technical issue that was causing a test to fail in Odoo's HR payroll module. The fix ensures that pages transition correctly during tests involving changes to employee job roles, preventing unexpected test failures. This improves the reliability of our automated testing process.
Original PR description
In the test tour related to the correct change of the salary configurator when the job changes on the employee, some missing expectUnloadPage options were causing the test to crash because the page was changing unexpectedly. With this PR we fix this error. Runbot Error: 231605
A test was failing intermittently due to an issue with redirect URLs being incorrectly formatted. This update corrects the test to handle these URLs properly, ensuring consistent test results. This resolves a technical problem that could have impacted the stability of the system.
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 ensures our subscription icon aligns with the established Milky icon design guidelines. This improves the visual consistency of our SaaS offering and reinforces our brand identity. The change is a minor update to maintain a polished user experience.
Original PR description
This `network_light.svg` wasn't quite aligned with Milky picto's design guidelines. In this PR the pictogram has been tweaked in order for it to follow the guidelines. task-5126719 Forward-Port-Of: odoo/enterprise#95895
Code cleanup and technical improvements
This update streamlines the testing process for the Ar-EDI module by automatically verifying data against JSON files. This change allows tests to run without external dependencies and simplifies updates to test data through a simple tag.
Original PR description
This commit refactors the whole `l10n_ar_edi` test suite to use the new helpers, and made it possible for the test to (finally) be run without external mode. Now, when running these new tests, the test framework will by default assert the request data with their associated JSON file. When a change is made, new overwrites for the test files can be easily changed by just adding the `SAVE_JSON` test tag on the command to run the tests. task-4891206 Forward-Port-Of: odoo/enterprise#104886 Forward-Port-Of: odoo/enterprise#103370
11 changes
Enhancements to existing features
This update adds a comprehensive list of VAT exemption reason codes (VATEX) to the account_edi_ubl_cii_tax_extension module. Previously, the available codes were incomplete, which could lead to inaccuracies in VAT reporting. This enhancement ensures compliance with VAT regulations and improves the accuracy of financial data.
Original PR description
The list is there but not exhaustive. Make the exhaustive list of VAT exemption reason codes (VATEX) available. task-5443294 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244552
Resolved issues and error corrections
This update fixes a bug that caused Odoo to crash when creating invoices in USD with zero amounts and tax/discount applied. The fix prevents a division-by-zero error during currency conversion, ensuring invoices can be generated correctly. This improves stability and prevents data loss.
Original PR description
**Steps to reproduce:** 1. Install the `l10n_it_edi` and switch to IT company 2. Go to Accounting → Invoice. 3. Create an invoice add partner and change the currency to USD 4. Add a product and apply tax and discount of 100% and confirm 3. Click on Send **Issue:** A ZeroDivisionError is raised during the Italian EDI XML generation. `ZeroDivisionError: float division by zero` **Cause:** The conversion rate is computed by dividing `amount_total` by `amount_total_signed` without handling the case where `amount_total_signed` is `0.0`. **Solution:** Skip the conversion rate computation when the signed total amount is zero, preventing the division by zero **opw-5481821** Forward-Port-Of: odoo/odoo#244423
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 that the report can now be successfully exported even with contacts lacking a name, improving report generation reliability.
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 corrects a typographical error in the tests for the search highlight feature within Odoo. The fix ensures the tests run correctly and prevents potential issues with search functionality. This is a routine maintenance update.
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 resolves a problem where FedEx labels incorrectly displayed addresses containing special characters (like accented letters). The code has been updated to ensure all addresses are converted to ASCII characters before being sent to FedEx, preventing display issues and ensuring accurate label formatting. This improves the reliability of shipping labels.
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 UN/ECE code. The fix removes a specific UNECE code ('HD') that wasn't accepted by Peppol, ensuring invoices now pass validation and can be successfully transmitted.
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 resolves a visual glitch on mobile websites (particularly with RTL languages) where a horizontal scrollbar briefly appeared when the header reappeared after scrolling. The fix ensures the header's styling is correctly synchronized, preventing this momentary disruption of the user interface. This improves the overall mobile experience and consistency.
Original PR description
There was an horizontal scrollbar that would appear for a short time after scrolling back to the top of the page. This would occur because the header would still have the "transform" property but the class "o_header_affixed" was already removed. To fix the issue, the header transform is now applied using dynamicContent, to synchronize the style and class correctly. This requires the standard header to have "transition: none" applied after it is scrolled since "translate(0, -100%)" would trigger an animation when hiding the header. task-5155878 Forward-Port-Of: odoo/odoo#241980
This update corrects a technical issue where a function was incorrectly called in the payroll module. The fix creates a new function in the documents module that properly calls the correct function, ensuring the payroll process runs smoothly. This resolves a potential error and maintains the stability of the HR and payroll features.
Original PR description
Issue: `_check_create_documents` is called in 'hr_payroll' but only defined in 'documents_hr_payroll' Solution: Create a new method that will be redefined in 'documents_hr_payroll' to call `_check_create_documents` opw-5213979 Forward-Port-Of: odoo/enterprise#104282
This update resolves an issue where non-administrator editors couldn't save images from Unsplash. The fix ensures that users with editor permissions can successfully upload and save these images, improving website customization capabilities. It addresses a security concern related to user access rights.
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#244831 Forward-Port-Of: odoo/odoo#219472
A test related to user signup was failing intermittently due to an issue with the URL being generated. This update corrects the test to handle both absolute and relative URLs, ensuring consistent test results and improved stability of the signup process. This resolves a technical issue that could have impacted user onboarding.
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 prevents errors when users attempt to upload corrupted or encrypted PDF files when creating quotation document headers and footers. Previously, these files would cause a system error. This change ensures a smoother user experience by gracefully handling invalid PDF uploads, allowing users to continue generating quotes without interruption.
Original PR description
Currently, an error occurs when uploading `encrypted or incomplete` PDF files (missing EOF marker) while creating a quotation document header or footer. **Steps to reproduce:** - Install the…
Currently, an error occurs when uploading `encrypted or incomplete` PDF files (missing EOF marker) while creating a quotation document header or footer. **Steps to reproduce:** - Install the `sale_pdf_quote_builder` module. - Navigate to: Sales > Configuration > Headers/Footers. - Upload encrypted file [1], or incomplete file [2]. **Error:** `PyPDF2.errors.DependencyError: PyCryptodome is required for AES algorithm` `PyPDF2.errors.PdfReadError: EOF marker not found` **Root cause:** At [3], `_get_form_fields_from_pdf` and `_ensure_document_not_encrypted` directly call `pdf.PdfFileReader`, when it fails to read or decrypt the file, Python raises an error. **Fix:** This commit prevents errors when users upload unreadable or encrypted PDF files. [1]: https://drive.google.com/file/d/1moSlwXHkqcV6_7zHBNhLMLi-9Ye_xDGJ/view?usp=sharing [2]: https://drive.google.com/file/d/16O4LLH8dL0RWmbOx4HrcooFUyesWaVi-/view?usp=sharing [3]: https://github.com/odoo/odoo/blob/694f1d0fb03b56dd41a59eb676e56622634cc91b/addons/sale_pdf_quote_builder/utils.py#L11 sentry-6928220164 opw-5227601 Forward-Port-Of: odoo/odoo#245109 Forward-Port-Of: odoo/odoo#230712
13 changes
Resolved issues and error corrections
This update hides live chat commands (like `/help`) from visitors and guests. Previously, these commands were visible but unusable, creating a confusing experience. This change improves usability and prevents accidental interaction by non-users.
Original PR description
**Current behavior before PR:** channel commands like `/help ` or `/leave` are visible to visitors even it is not functional for them. **Desired behavior after PR is merged:** commands are now hidden from visitors. task-4552209 related: [PR](https://github.com/odoo/enterprise/pull/82963) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents website visitors and guests from seeing live chat commands like '/help' or '/leave'. Previously, these commands were visible, even though they weren't functional for non-logged-in users. This change improves the user experience and security by removing potentially confusing or exploitable elements from the website.
Original PR description
**Before PR:** channel commands like `/help ` or `/leave` and more are visible to visitors or guest even it is not functional for them. **After PR:** all commands are now hidden from visitors/guests. task-4548666
This update resolves a bug that caused Odoo to crash when creating invoices in USD with zero amounts and tax/discount applied. The fix prevents a division-by-zero error during currency conversion, ensuring invoices can be processed correctly. This improves stability and prevents data errors related to foreign currency transactions.
Original PR description
**Steps to reproduce:** 1. Install the `l10n_it_edi` and switch to IT company 2. Go to Accounting → Invoice. 3. Create an invoice add partner and change the currency to USD 4. Add a product and apply tax and discount of 100% and confirm 3. Click on Send **Issue:** A ZeroDivisionError is raised during the Italian EDI XML generation. `ZeroDivisionError: float division by zero` **Cause:** The conversion rate is computed by dividing `amount_total` by `amount_total_signed` without handling the case where `amount_total_signed` is `0.0`. **Solution:** Skip the conversion rate computation when the signed total amount is zero, preventing the division by zero **opw-5481821** Forward-Port-Of: odoo/odoo#244423
This update resolves an issue in the Mexico (l10n_mx) accounting reports where an incorrect value appeared in the 'Month 13' column of the Trial Balance. The fix removed a redundant balance column, ensuring data displays accurately within the report. This improves the reliability of financial reporting for Mexican businesses using Odoo Enterprise.
Original PR description
With l10n_mx company: 1 - Add the balance column to the “Trial Balance” accounting report 2 - Create a journal entry for the date 12/31/2024 for 5000 as a credit on the account 119.01.01 VAT due and balance it with 5000 as a debit on another account 3 - Open the Trial Balance report and click on the “Month 13” filter as well as the year 2024. Notice that the “Month 13” column has some numbers when there should not be a number in that column. Delete the balance column from the “Trial Balance” accounting report and notice that the numbers now appear in their appropriate columns. In the _l10n_mx_set_options_month_13 the way to find the initial value, month 13 and end value columns was hardcoded. opw-5222117 Forward-Port-Of: odoo/enterprise#104788 Forward-Port-Of: odoo/enterprise#104105
This update resolves an error that occurred when generating PDF reports for accounting, specifically when a contact didn't have a defined name. The fix ensures that reports can now be created successfully even with contacts lacking names, improving report generation reliability.
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 corrects a typographical error in the tests for Odoo's search functionality. The fix ensures the search results are displayed correctly, improving the overall user experience. This is a routine maintenance update.
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 resolves an issue where list markers disappeared when switching between list types (numbered, bullet, or checklist) in the HTML editor. The fix ensures that markers are consistently displayed regardless of the selected list type, improving the user experience for creating and editing lists.
Original PR description
Steps to reproduce: - Create a numbered list - Press Backspace to remove the list marker - Change the list type to bullet or checklist using the powerbox. Current behavior before PR: - The list type is changed to bullet or checklist, but the marker is not visible Cause: - When a list marker is removed using Backspace, the `oe-nested` class is added to the `<li>` element, which hides the marker. - When switching the list to another list type, the `oe-nested` class is not removed. - As a result, even though the list type changes, the marker remains hidden. Solution: - When changing the list type, remove the `oe-nested` class from `<li>` elements that do not contain any list elements as children. - This ensures the marker is correctly restored for the new list type. task-5468384
This update ensures that new partners created during shared sign requests are automatically named with the signer's name, rather than using their email address. This improves data accuracy and consistency when managing signers within the system.
Original PR description
Version: - saas-18.2 Steps to reproduce: - Create a shared sign request. - Open the shared signing link and complete the signature process. - During signing, a new partner gets created for the signer if not already exists. Before: - When the user signs the shared sign request and a new partner is created, the partner name is not set and email is used as name. After: - Now, when a user signs a shared sign request and a new partner is created, the system automatically sets the partner name using the signer name. task-5776339
This update resolves a technical issue preventing grouping within the planning module. The fix ensures that parameters are passed to a key method in the correct order, enabling proper data aggregation and reporting. This improves the functionality of the planning system.
Original PR description
Before this commit, it was impossible to group by on any field in `planning.slot.template` model, because the parameters given to the parent method of `formatted_read_group` method were not given into the right order. This commit makes sure the order is respected.
A test was failing intermittently due to an incorrect redirect URL format within the Odoo documents module. This update corrects the test to handle both absolute and relative URLs, ensuring consistent test results and stability. This resolves a technical issue that could have impacted the reliability of the system.
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 a bug where the color slider in the editor's custom gradient picker would reset to red when selecting white. The fix prevents unnecessary UI updates during color selection, ensuring a smoother and more reliable color picking experience. This improves the editor's functionality and user experience.
Original PR description
**Current behavior before PR:** In editor's custom gradient picker, if `#FFFFFF` is picked from the very top of picker area, the color slider is reset to color `red`. This happens because when moving picker pointer to the top of area, `selectedColor` prop is updated to `#FFFFFF`, which calls `onWillUpdateProps` callback. As result, `convertRgbToHsl` sets hue value 0 for `#FFFFFF`, setting color slider to red. **Desired behavior after PR is merged:** This commit ensures that in `onWillUpdateProps` callback, `setSelectedColor` should not get called if `newSelectedColor` is the same as `this.colorComponents.cssColor` to prevent updating UI twice while picking the color. task-5170041 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236644
This update fixes an issue where refund and bill payments for the same bank and partner weren't always combined into a single payment. Now, the system correctly merges these payments, reducing the number of payments created and simplifying reconciliation. This improves efficiency and accuracy in payment processing.
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
Code cleanup and technical improvements
This update simplifies the handling of change rounding in Point of Sale transactions. The team has introduced a new setting to easily control whether POS transactions should round to the nearest currency unit, making it more flexible for different business needs. This change improves the user experience and reduces potential discrepancies in cash handling.
Original PR description
In the entreprise associated PR, we override `shouldRoundChange` in `pos_settle_order` module. opw-5222985
5 changes
New functionality added to Odoo
This pull request introduces preliminary work for integrating hardware devices (specifically, the 'blackbox') into the Odoo Enterprise system. The changes include new models, views, and security configurations to support the device's data and functionality. This is an initial development phase and requires further refinement.
Resolved issues and error corrections
This update corrects a database issue related to how VAT data is handled in Odoo's Brazilian retail module (l10n_br_edi_pos). An earlier update removed a necessary step to ensure VAT data was properly formatted in newer Odoo versions. This fix reintroduces a small code block to guarantee accurate VAT data processing, preventing potential reporting errors.
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 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 a name, 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 an issue where selecting a work order in the MRP Overview would incorrectly prioritize it. The fix ensures that work orders are sorted correctly based on their actual record identifiers, resolving a display problem. Additionally, the 'show case' work order now remains at the top when using pagination for 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 corrects a display issue in the applicant recruitment reports module. Previously, stage change notifications weren't labeled correctly in chatter, leading to confusion. The fix ensures that stage change messages are accurately identified and shown with the correct 'Stage changed' label, improving the clarity of applicant communication history.
Original PR description
…records in hr_recruitment_reports demo data Steps to reproduce: 1. Load demo data for hr_recruitment_reports module 2. Check applicant records in chatter 3. Observe that stage change messages don't show "Stage changed" label Bug cause: mail.message records for applicant stage changes were missing the subtype_id field, which defaults to an incorrect subtype (mt_note instead of mt_applicant_stage_changed). This caused the messages to be treated as internal notes rather than stage change notifications. Solution: - Add subtype_id field with reference to hr_recruitment.mt_applicant_stage_changed to all mail.message records that track applicant stage transitions - This ensures stage change events are properly identified and displayed in chatter with the correct "Stage changed" label Affected records: 20 mail.message records in hr_recruitment_reports_demo.xml Task Id:5454691
8 changes
Resolved issues and error corrections
This update corrects a data issue related to Brazilian VAT (tax) records in the enterprise accounting system. A previous change removed a necessary step to ensure VAT data was properly formatted, particularly in the POS module. This fix reintroduces the required formatting to maintain accurate tax reporting.
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 resolves an error that occurred when generating PDF reports for accounting, specifically when a contact record lacked a name. The fix ensures that the report can now be successfully exported even if a contact doesn't have a defined name, improving report generation reliability.
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 resolves an issue where FedEx labels incorrectly displayed addresses containing special characters (like accented letters). The code has been updated to ensure all address fields are converted to ASCII characters before being sent to FedEx, resulting in accurate address formatting on labels. This improves the presentation of customer addresses when using FedEx shipping.
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 fixes an issue where appraisals weren't automatically selecting the correct company-based template. The change ensures that appraisals, regardless of whether the employee or appraisal has a department assigned, correctly utilize the intended template. This prevents errors and ensures appraisals are set up accurately.
Original PR description
### Issue: When having a template with a company but no department, it's not selected by new appraisal. ### Steps to reproduce: - Have an employee whose appraisal date is today. - Have only one…
### Issue: When having a template with a company but no department, it's not selected by new appraisal. ### Steps to reproduce: - Have an employee whose appraisal date is today. - Have only one template, with the company of the employee but no department - Run the cron "Appraisal: Run employee appraisal" - Open the Appraisals app - Click on the newly created appraisal - It doesn't have the template ### Cause: - In `_compute_appraisal_template()`, only the department of the appraisal is used to compute the template. But `_create_new_appraisal()` doesn't include the department in `appraisal_values` to create the appraisal. So `appraisal.department_id` is `False` and the template from the department is ignored. - Another issue is if the employee has no department, then the appraisal also has no department. Then no template is selected by the search domain. ### Solution: - Include `department_id` in `appraisal_values` - Modify the search domain to include the case where the appraisal has no department opw-5477450
This update corrects a bug that prevented users from adding inputs to payslips. The fix ensures that the system correctly identifies and displays salary inputs for each employee, resolving an issue where inputs were not appearing. This improves the accuracy of payslip creation.
Original PR description
When trying to add Inputs for a payslips none appear as the domain was incorrect and only showed salary inputs for use in the employee. This is fixed in this commit by adding to the domain en each specific model. task-5486091
This update resolves an issue where work orders weren't correctly assigning employees due to an incorrect data structure. The fix ensures that employee IDs are handled properly, preventing duplicate key errors and ensuring accurate work order assignments. 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
This update resolves a technical issue preventing payroll tests from running correctly in both Hong Kong and Belgium. Specifically, it ensures the correct company settings are used during test execution, aligning data with payroll configurations and improving test reliability. This change is a fix for a known problem.
Original PR description
As we are enabling tests on runbot, a few issues need to be fixed. When tested in the l10n build, the BE tests are failing due to company setting issue on the admin user. Also aligns the readonly attribute of two computed field on the version to match the employee in HK payroll.
This update resolves a crash within the automated test suite for the Belgian payroll and HR module. The issue stemmed from missing instructions during a test involving job changes, causing unexpected page transitions. This fix ensures the test suite runs smoothly and reliably.
Original PR description
In the test tour related to the correct change of the salary configurator when the job changes on the employee, some missing expectUnloadPage options were causing the test to crash because the page was changing unexpectedly. With this PR we fix this error. Runbot Error: 231605 Forward-Port-Of: odoo/enterprise#105067
15 changes
New functionality added to Odoo
This update adds support for the Caribbean Guilder (XCG) as a new currency option within Odoo. It designates the XCG as the default currency for Curaçao and Sint Maarten, expanding Odoo's currency coverage to include these regions. This enhancement improves the system's ability to handle transactions in these local markets.
Original PR description
Introduce the Caribbean Guilder (XCG) as an available currency and set it as the default currency for Curaçao and Sint Maarten. Related PR-https://github.com/odoo/enterprise/pull/104404 taskID-5490423
This update introduces the Caribbean Guilder (XCG) as a supported currency within Odoo Enterprise. It’s now the default currency for Curaçao and Sint Maarten, aligning our financial data with the broader Odoo community. This change supports international business operations in these regions.
Original PR description
Align enterprise currency data with the community with addition of new currency XCG. Related PR-https://github.com/odoo/odoo/pull/243955 taskID-5490423
Resolved issues and error corrections
This update addresses a discrepancy in the testing process for Mexican VAT (CFDI) invoices, specifically related to rounding rules. The change ensures that test cases accurately reflect the latest Mexican tax regulations regarding rounding, improving the reliability of the l10n_mx_edi module. This ensures accurate VAT calculations for Mexican businesses using Odoo Enterprise.
Original PR description
Adapt the test cfdi rounding 9 for commit https://github.com/odoo/odoo/pull/233278
This update corrects a rounding issue in the payment wizard when converting invoices to MXN currency. Previously, the displayed amount was slightly off due to differences in how currency conversions were handled. This fix ensures accurate currency conversion and display, particularly for companies using MXN as their primary currency.
Original PR description
With a company where the main currency is, for instance, MXN (easier to reproduce with l10n_mx): - Create a currency exchange rate for USD: 0.051908143350 unit per MXN and 19.264800000000 MXN per unit. - Create an invoice in USD with a product priced at 432, quantity of 2, and 16% taxes. In the journal items of the invoice, the balance is 19307.96 MXN. However, in the payment wizard, the amount shown when switching to MXN currency is 19307.95. In _get_total_amount_in_wizard_currency_to_full_reconcile, we convert the source amount currency (which includes line + tax not yet converted), then perform the conversion. Whereas in the invoice, we first convert the product line and tax line separately and then sum them up. opw-4846090 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 addresses a technical issue preventing Odoo from correctly importing a necessary exception class from the 'requests' library. The issue stemmed from a recent change in the 'requests' package itself. By installing a specific version of 'requests' and importing the exception correctly, this fix ensures Odoo's functionality continues without interruption.
Original PR description
Installing `requests==2.25.1` and using the following line of code:
from requests.exceptions import JSONDecodeError
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
This change fixes this error importing the original exception from `json` package
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 resolves an issue where products with single attribute values (like color or shape) weren't correctly displayed when ordered via barcode in Point of Sale. The fix ensures that variants are only shown when multiple attribute selections are present, aligning with current Odoo 18.2 functionality. This improves the user experience for barcode-based ordering.
Original PR description
**Steps to reproduce:** - Make a product with 2 attributes, like color and shape - Enter a single value for each of them - Enter a Barcode on it - Go to PoS, click on it, the variants will be shown in it's name - Order it using the Barcode you defined - The product will not display the variants **Problem:** When ordering a product that has multiple attributes with a single value, the "selected" variants will be shown, even though it is always the same. When ordering it through the Barcode, the variants will not be shown. **Why the fix:** The variants are now not shown if all attributes only have one value, like it is done with the Barcode. If there are some attributes that have multiple values, it will be displayed when clicking on it. It is not possible to order them through Barcode as it does not support the value selection in 18.0. Only showing the variants if there are some choices to be made is how it is done from 18.2 onwards. opw-4946547
This update fixes a technical issue where booking appointments with flexible resources resulted in a 404 error page for users. The change ensures appointments with these resources can be successfully booked, improving the user experience and preventing lost bookings.
Original PR description
**issue:** booking an appointment with a flexible resource returns a 404 error page. **steps to reproduce:** - create an appointment with a flexible resource - go to website - attempt to book an appointment - 404 page not found is returned opw-5039947
This update enhances the stability of the account winbooks import function by breaking down large move creation processes into smaller batches. This prevents potential memory issues that could cause the import to fail, ensuring smoother and more reliable data imports.
Original PR description
The part of the import function that created moves could easily attempt to create thousands of moves at once, potentially leading to a memory error. This PR splits the calls into batches to avoid using too much memory. opw-5003045 Forward-Port-Of: odoo/enterprise#97263 Forward-Port-Of: odoo/enterprise#91931
This update resolves minor visual inconsistencies in the new image gallery template. Specifically, it corrects issues with missing styling and undefined class names, ensuring a more polished and reliable display of images for users. This improves the overall user experience.
Original PR description
This commit fixes a few minor issues in the new carousel items template introduced in [1]: items having an `"undefined"` class, and a missing margin style in the main snippet template. [1]: https://github.com/odoo/odoo/commit/9042b1cae7b630b20e0670788b7a4ed9e4c97609 linked-task-3414281
This update fixes a display issue in the appointment calendar for Ukrainian and Polish users. Previously, month names were shown in the genitive case, which was incorrect. The fix ensures month names are displayed in the nominative case, aligning with standard calendar conventions and improving the user experience for these languages.
Original PR description
In the appointment calendar, the "Month Year" (e.g. January 2026) is displayed at the top of the calendar selector as is standard for calendars. Unfortunately in some languages, the word month word…
In the appointment calendar, the "Month Year" (e.g. January 2026) is displayed at the top of the calendar selector as is standard for calendars. Unfortunately in some languages, the word month word used depends on grammatical situation. Steps to reproduce: - activate Ukrainian (or Polish) language - Preview (i.e. the website view) of any appointment - Change the preview into Ukrainian (or Polish) Expected result: Calendar month at top of calendar is shown in the nominative case: e.g. January 2026 = січень 2026 (in Ukrainian) Actual result: Calendar month is shown in the genitive case (e.g. "of January", as in "the 12th of January): e.g. January 2026 = січня 2026 (in Ukrainian) Fix is to switch from the "MMMM Y" format (i.e. month based on grammar context) to "LLLL Y" (i.e. stand alone month) which will use the correct month case. Ref: https://www.unicode.org/reports/tr35/tr35-dates.html#dfst-month Note that for most languages this won't make a difference since there is usually only 1 way of writing a month. opw-5474705 picture diff (for January 2026): before fix: <img width="1168" height="468" alt="image" src="https://github.com/user-attachments/assets/36754439-e664-40f3-9c5b-7c9c76cd7cca" /> after fix: <img width="1215" height="492" alt="image" src="https://github.com/user-attachments/assets/82f0665e-fe70-4b9f-b1d4-f420b52db38f" />
This update resolves an issue where internal users without sales permissions encountered errors when accessing their sales orders through the /my page. This change ensures a smoother experience for all users within Odoo, preventing disruptions to sales workflows. The fix mirrors a previous update to maintain consistency and stability.
Original PR description
Avoid error when internal user (no sale permissions) see Orders at /my Similar to https://github.com/odoo/odoo/commit/5ebab949a06ec338cc28e912317a74bbfb3fe6ac @Tecnativa TT60025 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a performance issue in the Point of Sale module. Previously, scanning invalid barcodes triggered unnecessary recalculations of product pricing data, slowing down the system. This change prevents those unnecessary calculations, resulting in faster and more efficient point-of-sale operations.
Original PR description
Before this commit, if scanning a barcode that does not correspond to any product, computeProductPricelistCache was called with no data, therefor it recomputed the cache for all records. opw-5476560 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a technical error in the delivery IoT module that caused tracebacks when confirming print jobs. The change ensures compatibility with IoT boxes that don't provide standard print IDs, preventing duplicate print job creation and improving system stability. This resolves a potential issue impacting report processing.
Original PR description
In `delivery_iot`, as reports are fetched in the chatter from the backend, we end up creating one print job in the front end but multiple print jobs can be sent with WebSocket in the backend. We then get a traceback when getting a second confirmation from a print job that has just been deleted from the job list. Additionally, we ensure compatibility with the stable IoT Box, that do not return a `print_id` or `iot_mac`. opw-5464957
This update removes a restriction that limited the use of certain accounts within journals. Previously, accounts used as default debit or credit accounts in journals couldn't be marked as non-reconcilable. This change provides greater flexibility for users to manage their accounting records, simplifying account setup and reconciliation processes.
Original PR description
Previously, a constraint prevented accounts from being non-reconcilable if they were used as default debit/credit accounts involved in journals. This behavior is too restrictive. This commit removes the constraint. task-5254202 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This pull request corrects a technical issue related to the translation of Odoo's Greek language support. Specifically, the incorrect language code 'gr' was replaced with the correct 'el' code, ensuring accurate translations for Greek-speaking users. This update ensures proper localization and a better user experience for our Greek-speaking customers.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244684
5 changes
Resolved issues and error corrections
This update corrects a rounding issue in the payment wizard when displaying amounts in MXN currency for invoices with USD pricing and taxes. The fix ensures accurate currency conversion and display of invoice totals, resolving a discrepancy between the invoice and payment wizard. This improves financial reporting accuracy.
Original PR description
With a company where the main currency is, for instance, MXN (easier to reproduce with l10n_mx): - Create a currency exchange rate for USD: 0.051908143350 unit per MXN and 19.264800000000 MXN per unit. - Create an invoice in USD with a product priced at 432, quantity of 2, and 16% taxes. In the journal items of the invoice, the balance is 19307.96 MXN. However, in the payment wizard, the amount shown when switching to MXN currency is 19307.95. In _get_total_amount_in_wizard_currency_to_full_reconcile, we convert the source amount currency (which includes line + tax not yet converted), then perform the conversion. Whereas in the invoice, we first convert the product line and tax line separately and then sum them up. enterprise: https://github.com/odoo/enterprise/pull/92522 opw-4846090 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a bug in the tests for the Mexican Electronic Invoicing (CFDI) payment wizard. The fix ensures accurate rounding of payments during tax calculations, addressing a potential discrepancy in how taxes were applied. This improves the reliability of financial reporting within the Odoo Enterprise system.
Original PR description
This commit correct the test test_cfdi_rounding_9 after commit a7213d25965348aa3188ee7368f8db6d57463fc1 community: https://github.com/odoo/odoo/pull/222682 opw-4846090
This update addresses a minor issue preventing Odoo modules (l10n_eg_edi_eta, l10n_ro_edi_stock, and l10n_rs_edi) from correctly importing a JSON error handling function. The fix involves installing a specific version of the 'requests' library and importing the necessary exception class, resolving a conflict introduced in a recent 'requests' package update.
Original PR description
Installing `requests==2.25.1` and using the following line of code:
from requests.exceptions import JSONDecodeError
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
This change fixes this error importing the original exception from `json` packageThis update resolves a bug preventing Quality Administrators from creating Quality Worksheet Templates. The issue stemmed from incorrect permission handling during record creation, now corrected to ensure proper access rights are applied. Users can now successfully create and save templates.
Original PR description
A Quality Administrator user currently cannot create a Quality Worksheet Template. This is caused by the fact that the process creates additional records: 'ir.model' and 'ir.model.fields'. The `.sudo()` used with the first one is not propagated to the second one. The solution was to create 'ir.model.fields' separately, after the creation of 'ir.model'. Additionally, 'ir.rule' creation is also done with `.sudo()` now (it's a part of the same process). Steps to reproduce: * as admin, modify the demo user: * make sure the "Administration" access right is empty * set "Quality" access right to "Administrator" * as demo user: * go to Quality -> Configuration -> Quality Worksheet Templates * create a new template and save The template should be saved without any errors. Task: 5350296
This update simplifies the process of reversing returns for products valued using standard costs. Previously, extra journal entries were automatically created, which is no longer necessary. This change streamlines accounting and reduces potential errors when handling returns of standard cost items.
Original PR description
Currently, when a user needs to reverse a return for a standard cost product, extra journal items are created to balance the initial purchase operation. Steps to reproduce: 1. Create a standard price/automated product category 2. Create a storable product with such category and cost 10 3. Create a PO with 1 @ 100, Confirm and receive the product 4. Return the full quantity 5. Return the return for the full quantity Issue: During the last operation two additional journal items are created to balance the returned svl with the original purchase price. However this is not needed when the item has a standard cost inventory valuation. opw-5133716