Daily updates from Odoo
Navigate
Branch
Tuesday, May 5, 2026
349 changes
20 changes
Enhancements to existing features
This update adjusts the reporting of COA and TB data to align with Mexican government specifications. This ensures compliance with tax regulations and reduces the risk of reporting errors. The changes are focused on data formatting for improved accuracy.
Original PR description
Reordered COA and TB attributes to be more according on what government expects on those reports task-5422228
Resolved issues and error corrections
This update resolves an error that prevented users from submitting surveys with background images. The issue stemmed from outdated code referencing a removed component. The fix ensures background images load correctly during the survey submission process, improving the user experience.
Original PR description
### Issue before this commit: When the submit event is triggered, the system attempts to preload the background image for the next screen using SurveyPreloadImageMixin. However, this mixin is no longer used, which results in the following error: SurveyPreloadImageMixin is undefined ### Steps to Reproduce: 1. Install the Survey module 2. Create a new survey 3. Add a section with a background image 4. Add at least one question 5. Click on Test 6. Start the survey and submit the first page ### Cause of the Issue: The code still references SurveyPreloadImageMixin._preloadBackground, even though SurveyPreloadImageMixin has been removed/refactored. This leads to an undefined reference during execution. Refactored-commit: https://github.com/odoo/odoo/commit/50c03d966241da263a63ec7948e293a0475e9ba9 ### With This Commit: To ensure it works correctly, preloadBackground() is imported and called inside nextScreen(). opw-6165822 Forward-Port-Of: odoo/odoo#262424
This update resolves an issue where IoT-connected printers weren't correctly configured within Odoo's Point of Sale (PoS) system. Previously, these printers were unusable. This fix ensures that IoT printers are properly loaded, allowing for seamless operation within the PoS workflow.
Original PR description
preparation printers were not loaded in PoS as IoT devices making them unusable. Forward-Port-Of: odoo/enterprise#115826 Forward-Port-Of: odoo/enterprise#115768
This update fixes a visual issue where quick actions were incorrectly displayed on tracking messages. By standardizing the styling of tracking messages, quick actions are now positioned correctly, ensuring a consistent and user-friendly experience for viewing email notifications.
Original PR description
Previously, quick actions were incorrectly positioned on tracking messages, as they were not treated the same way as notification messages in terms of bubble styling. This PR ensures that tracking messages are handled like notification messages by excluding them from bubble coloring, resulting in the correct placement of quick actions. task-6176330 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where invoices created in a branch environment with tax-included prices didn't correctly calculate the price after applying a fiscal position. Previously, the unit price remained at the full tax-included amount. This change ensures accurate price recalculation and tax handling for multi-company branch operations, improving financial reporting.
Original PR description
When operating in a multi-company branch environment, the unit price of a product with price-included taxes is not correctly recalculated when applying a fiscal position. Steps to reproduce: - Create a tax that is included in the price (e.g., 10% incl). - Assign this tax to a product (e.g., Product A). - Create a fiscal position that maps this 10% tax to a different tax. - Create a branch (child company) of your main company. - Create an invoice in the new branch using the fiscal position and add an invoice line for Product A. Issue: The unit price of the product on the invoice line remains the full tax-included amount rather than being reduced to exclude the original 10% tax. opw-5931302 Forward-Port-Of: odoo/odoo#262190 Forward-Port-Of: odoo/odoo#256897
This update resolves an issue preventing the successful import of Winbooks data for Belgian companies. The fix allows Odoo to correctly recognize a specific tax account (411000) used in Winbooks, ensuring accurate data import and avoiding an error message. This improves the reliability of the Winbooks import process.
Original PR description
Steps to reproduce: ------------------- 1. Install account_winbooks_import, and switch to a Belgian company 2. Open Accounting > Configuration > Settings and click "Import", then click "Import WBK"…
Steps to reproduce: ------------------- 1. Install account_winbooks_import, and switch to a Belgian company 2. Open Accounting > Configuration > Settings and click "Import", then click "Import WBK" 3. Upload a Winbooks zip whose chart of accounts uses 411000 typed as asset_current (Winbooks default for "VAT Recoverable") 4. Confirm the import The import fails with: "You must select a receivable account for 'Tax Receivable Account'." Why the issue ------------- In Winbooks, account 411000 is the V01 central account (tax receivable). In Odoo, 411000 comes from l10n_be (account "a411") with type "asset_current", not "asset_receivable". When the import wizard sets it on the existing tax groups via `manage_centralid` in import_wizard.py, the constraint `_constrains_payable_receivable_account` on account.tax.group rejects the write because the account is not "asset_receivable" + "non_trade". This case was already handled in 20804db6d87: we bypassed the constraints on accounts coming from Winbooks, as those are imported in draft anw and the user finishes the configuration after. However later, [2a38e771a826](https://github.com/odoo/odoo/commit/2a38e771a826) and ff5dee81080 removed the initial constraint and the code that bypassed it for account_winbooks_import. Finally, [746a06fab485](https://github.com/odoo/odoo/commit/746a06fab485) added back a similar constraint "_constrains_payable_receivable_account" to fix a NL issue (same account used as both payable and receivable on a tax group). The Winbooks bypass however was not added back, so the original Winbooks issue appeared again. The fix ------- Add back the same bypass originally introduced in 20804db6d87. opw-6092464 Forward-Port-Of: odoo/enterprise#115291
A small typo in the quality module caused newly created quality alert records to be incorrectly grouped under 'None'. This fix replaces the incorrect '&' character with the correct '|' character, ensuring records are assigned to the appropriate stages.
Original PR description
Issue: ------- While adapting the 'Domain' in the PR https://github.com/odoo/enterprise/commit/07b34a2e927347ca5c839ec632808adb02703e1f there occurred a typo where '|' got replaced with the '&' and causing the records getting grouped in 'None' when creating. Solution: ------------ To replace '&' with '|' to get the records grouped under the correct stage. Steps to reproduce: ----------------------- 1. In v19.0, in quality module try to create a quality alert record. 2. Just like that the newly created record will be under 'None'. Reference Image: <img width="1105" height="407" alt="image" src="https://github.com/user-attachments/assets/4c9c33be-ec06-4f06-8245-54dbe4473bc0" /> OPW - [6074016](https://www.odoo.com/odoo/project/70/tasks/6074016) Forward-Port-Of: odoo/enterprise#113108
This update fixes an issue where changing a task's project would reset its state (done or canceled) unnecessarily. Now, the state remains consistent when a task is marked as done or canceled, ensuring accurate tracking of task completion and preventing redundant state updates. This improves the reliability of project management workflows.
Original PR description
Before this commit, when the project of a task is changed, even if the state of that task is done or cancelled, the state is reset (except if the task is blocked by another one). This behavior is not expected for a task done/cancelled, we should not reconsider that task since it has been done/cancelled and so there is no reason to re-consider it once the project changed. This commit makes sure the state of the task is not reset when the project changed only if the state is a closed state or Waiting state. task-5361864 Forward-Port-Of: odoo/odoo#261648 Forward-Port-Of: odoo/odoo#252752
This update fixes an issue where duplicating a user also duplicated their associated tasks, leading to confusion and potential data inconsistencies. The change ensures that tasks are correctly assigned to new users, preventing shared task assignments and simplifying user management. This improves data accuracy and user experience.
Original PR description
Duplicating a user also duplicates all their task assignments because task_ids on res.users is missing copy=False. The new user ends up sharing the same tasks in project_task_user_rel, so removing a task from either user affects both. Forward-Port-Of: odoo/enterprise#114270 Forward-Port-Of: odoo/enterprise#114028
This update resolves an issue where very long image filenames in Odoo caused errors, specifically 502 errors when uploading images through the Sales Order editor. The fix truncates filenames to 255 characters to ensure compatibility with server limits, improving image upload stability for users.
Original PR description
## Problem: When generating a filename for a related studio image field, if the `name` is excessively long, the response header may exceed nginx's buffer size of 4kb, causing the request to fail. ## Solution: We will truncate the assigned filename for binary streams to the first 255 characters of whatever the assigned name would have been. ## Steps to reproduce (Runbot 18): 1. Open Studio editor on a Sales Order 2. Edit List View on Sale Order Lines 3. + Related Field, Product > Image, image widget 4. Make the description very long (close to 4000 characters) 5. Note the image will not load for that SOL, and the network tab shows a 502 error opw-5360952 Forward-Port-Of: odoo/odoo#258498
This update corrects a bug that occurred when manually creating vendor bills and DIAN commercial events were rejected. The fix ensures that retries work correctly, preventing errors related to outdated data and improving the reliability of DIAN integration for our Colombian users. This resolves a specific issue that only appears in standard testing environments.
Original PR description
This commit fixes an error when retrying a rejected DIAN commercial event on manually created Vendor Bills. This is a tricky error as it only happens when the vendor bill is manually created and the…
This commit fixes an error when retrying a rejected DIAN commercial event on manually created Vendor Bills. This is a tricky error as it only happens when the vendor bill is manually created and the event is rejected (missing/incomplete info or servers down which is common). To add more to this, this error can only be reproduced without demo mode as it forces the acceptance, forcing the need of valid testing or production DIAN credentials How to reproduce it: - Install l10n_co_dian module - On CO company with all required DIAN configuration set - Create a vendor bill manually with enough information to send to the DIAN but causing it to be rejected. - Click on acknowledge receipt, it should be rejected - Complete information to be accepted and again click on acknowledge receipt - A traceback appear Code expects the last document to be the most current one created when triggering commercial event, but this is not true when a rejected document exists since this is unlinked and cache invalidated causing the recordset to be invalidated and retrieved again by ORM with default order, so now the last document is the oldest one without an attachment causing the traceback opw-6104541 Forward-Port-Of: odoo/enterprise#114758
This update optimizes appointment scheduling by only calculating availability for the current month, rather than pre-computing all slots. This change significantly reduces the system's workload and improves response times when users are booking appointments, leading to a smoother user experience. It's a performance enhancement focused on the appointment module.
Original PR description
Generate all slots and compute only availabilities for the display month instead of pre-computing all slots for the whole booking period. task-4144524 Forward-Port-Of: odoo/enterprise#115986
This update fixes a bug preventing the correct import of PINT invoices (Australia, Japan, Myanmarese, Singapore) by adding logic to identify the document type. It also corrects a previous issue where tax amounts were incorrectly processed for JP PINT invoices, ensuring accurate financial reporting.
Original PR description
## PINT modules (`l10n_*_ubl_pint`)
The UBL module wasn't able to import PINT documents because there was no logic to detect the type of UBL document for PINT invoices (`urn:peppol:pint:billing-1@{anz, jp, my, sg}-1`). This PR adds the methods to detect PINT UBL documents and provide appropriate EDI decoder model names. Along with the fix, test cases are added to verify proper import of the said UBL's.
## Base EDI module (`account_edi_ubl_cii`)
Additionally, `_correct_invoice_tax_amount` in the base UBL import is fixed to only process TaxSubtotal nodes in the document currency. Previously it iterated over all `TaxTotal/TaxSubtotal` nodes regardless of currency, which caused the JP PINT import to pick up the company-currency tax amount instead of the document-currency one. JP PINT is the only format that includes TaxSubtotal in both TaxTotal nodes.
Forward-Port-Of: odoo/odoo#262010
Forward-Port-Of: odoo/odoo#258017This update ensures that 'Final Consumer' records are correctly identified as individuals, not companies, within the CO Edition module. The change resolves an issue where the system incorrectly classified these records, and includes updated tests to verify anonymous document creation. This ensures accurate reporting and compliance.
Original PR description
After changes on is_company field to be computed, Final Consumer was being created as a company. Although this is wrong, tests were not asserting correctly on how anonymous documents should be created. This commit fixes this by forcing the value to False and correcting the tests. task-6149751 Forward-Port-Of: odoo/enterprise#115560
This update resolves an issue where users lacked access to equity information for partners associated with different companies within their Odoo Enterprise setup. The change adds a company identifier to equity records, ensuring accurate reporting and access to all relevant partner data, regardless of company affiliation.
Original PR description
Before this commit, if you had some holders only visible to a company you don't have access to, the cap table would show an access error. This commit introduces multi-company logic to equity models by adding a new company_id field related to the company_id of the partner_id. Other partners (holder, seller, subscriber) will have their companies checked against that company. task-6018771 Forward-Port-Of: odoo/enterprise#110724
This update resolves visual issues with Saudi document layouts by removing redundant information and dynamically updating key details like VAT numbers. It ensures all Saudi companies use the correct paper format, improving the accuracy and presentation of invoices and reports.
Original PR description
This commit introduces several improvements and fixes to the Saudi document layouts and company configurations: - Removes the redundant VAT number from document layout header to resolve visual overlapping with other elements. - Extracts `l10n_sa_edi_additional_identification_scheme` and `l10n_sa_edi_additional_identification_number` from static company details and injects them dynamically into document layouts so they always remain up-to-date when printed. - Updates the configuration logic to ensure the default Saudi paper format is applied to all SA companies. task-6040091 Forward-Port-Of: odoo/odoo#255463
This update corrects a technical issue where translations for the Dutch returns module (l10n_nl_returns) were missing. Adding the necessary translation keys ensures accurate and complete functionality for our Dutch-speaking users. This resolves a potential issue with localized reporting and processes.
Original PR description
This [commit](a6a8d121bbf2044793df5211c5bdb18859a62152) introduced a new module in a stable version (19.0) without the required key in the `.weblate.json` file. This commit aims at fixing that to ensure translations are handled correctly. Forward-Port-Of: odoo/enterprise#115753
A recent problem with the departure form being inaccessible when accessed through payslips has been resolved. This change ensures the correct form view is used, preventing errors and improving the user experience for employees submitting departure requests.
Original PR description
The departure form could fail to load when accessed via payslip due to a leaked form_view_ref in the context. Explicitly set the correct form view in the action to avoid this issue. task-6167494 Forward-Port-Of: odoo/odoo#261701
This update corrects a bug in the invoice cancellation process for the ECPay integration. Previously, non-administrator users couldn't properly cancel invoices due to a permission issue with the staging mode setting. This change ensures all users can cancel invoices through the wizard, improving the user experience and preventing disruptions to the accounting workflow.
Original PR description
Before this commit, the invoice cancellation wizard failed when clicking "Request Cancel" because l10n_tw_edi_ecpay_staging_mode lacked sudo access, while similar fields had it. The cancel wizard (l10n_tw_edi.invoice.cancel) needs to read this field to determine the API endpoint, but non-superuser accounts couldn't access it, causing a permission error. This commit adds sudo() when accessing staging_mode, consistent with other ECPay API configuration fields. Steps to reproduce: - Install l10n_tw modules with ECPay staging credentials (MerchantID: 2000132) - Use valid Tax ID (10430481) to create and send invoice - As Accounting/Administrator user, cancel the invoice - Access error occurs on button_request_cancel opw-6101478 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260962
This update corrects a previous issue where all employees could see each other's overtime hours. The root cause was a setting that granted excessive access to overtime calculations. The fix removes this access and includes new tests to ensure this issue doesn't reoccur.
Original PR description
- Step to reproduce: everyone can see everyones overtimes. - Cause: total_overtime compute method is using `compute_sudo=True`. - Solution: removing compute_sudo and adding tests Task: 6125021 Forward-Port-Of: odoo/odoo#262206 Forward-Port-Of: odoo/odoo#261496
18 changes
Enhancements to existing features
This update automatically sets the first available printer as the default for Point of Sale transactions. Previously, users had to manually select a printer, and this change simplifies the process. Additionally, restrictions have been added to prevent incorrect printer configurations, ensuring data integrity within the POS system.
Original PR description
Following this commit: ===== - Set first printer as default printer from the list configured. - Updated the help tooltip. - Added placeholder "None" to field product_categories_ids. - Restrict quick create for `receipt_printer_ids` and `default_receipt_printer_id` for pos.config and res.config.settings views task-5494313 Forward-Port-Of: odoo/odoo#246448
Resolved issues and error corrections
A bug was fixed that prevented the custom color settings for self-ordering kiosks from being applied. The issue stemmed from a missing data field, which defaulted to the standard color. This update ensures that self-ordering kiosks now correctly display the configured color scheme.
Original PR description
The background color configured for the self ordering / kiosk was not applied. This was caused because the `self_ordering_primary_color` field was not sent to the self order when loading the data, resulting in the default color always being used. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6149865
This update fixes an issue where invoices in a multi-company branch environment weren't accurately calculating prices with taxes included. Previously, the unit price didn't correctly reflect the exclusion of the initial tax. Now, invoices will correctly adjust the price to exclude the original tax when a fiscal position is applied.
Original PR description
When operating in a multi-company branch environment, the unit price of a product with price-included taxes is not correctly recalculated when applying a fiscal position. Steps to reproduce: - Create a tax that is included in the price (e.g., 10% incl). - Assign this tax to a product (e.g., Product A). - Create a fiscal position that maps this 10% tax to a different tax. - Create a branch (child company) of your main company. - Create an invoice in the new branch using the fiscal position and add an invoice line for Product A. Issue: The unit price of the product on the invoice line remains the full tax-included amount rather than being reduced to exclude the original 10% tax. opw-5931302 Forward-Port-Of: odoo/odoo#262190 Forward-Port-Of: odoo/odoo#256897
This update resolves an issue where long image filenames in Odoo could cause website errors. The system now automatically shortens these filenames to prevent exceeding server limits, ensuring images load correctly and maintaining a stable user experience. This improves the reliability of image uploads and related features.
Original PR description
## Problem: When generating a filename for a related studio image field, if the `name` is excessively long, the response header may exceed nginx's buffer size of 4kb, causing the request to fail. ## Solution: We will truncate the assigned filename for binary streams to the first 255 characters of whatever the assigned name would have been. ## Steps to reproduce (Runbot 18): 1. Open Studio editor on a Sales Order 2. Edit List View on Sale Order Lines 3. + Related Field, Product > Image, image widget 4. Make the description very long (close to 4000 characters) 5. Note the image will not load for that SOL, and the network tab shows a 502 error opw-5360952 Forward-Port-Of: odoo/odoo#258498
A small typo in the quality module caused new quality alert records to be incorrectly grouped as 'None'. This update corrects the typo, ensuring records are properly assigned to the correct stages when created. This resolves a potential issue with data accuracy and reporting.
Original PR description
Issue: ------- While adapting the 'Domain' in the PR https://github.com/odoo/enterprise/commit/07b34a2e927347ca5c839ec632808adb02703e1f there occurred a typo where '|' got replaced with the '&' and causing the records getting grouped in 'None' when creating. Solution: ------------ To replace '&' with '|' to get the records grouped under the correct stage. Steps to reproduce: ----------------------- 1. In v19.0, in quality module try to create a quality alert record. 2. Just like that the newly created record will be under 'None'. Reference Image: <img width="1105" height="407" alt="image" src="https://github.com/user-attachments/assets/4c9c33be-ec06-4f06-8245-54dbe4473bc0" /> OPW - [6074016](https://www.odoo.com/odoo/project/70/tasks/6074016) Forward-Port-Of: odoo/enterprise#113108
This update resolves a crash in the form builder when using the 'Add other' option with radio buttons. The fix prevents a JavaScript error that occurred when the system tried to access data from a special input field created by the 'Add other' feature. Now, the form builder works reliably with this functionality.
Original PR description
When configuring a "Visible only if" condition that depends on a radio/checkbox field with the "Add other" option enabled, the form options panel crashed with: TypeError: Cannot read properties of…
When configuring a "Visible only if" condition that depends on a radio/checkbox field with the "Add other" option enabled, the form options panel crashed with:
TypeError: Cannot read properties of null (reading 'textContent')
Steps to reproduce:
====================
1. Go to /contactus and edit the form
2. Add a Radio Buttons field and enable "Add other"
3. Add another field and set "Visible only if" to depend on the radio field
=> TypeError, form options panel broken
Cause:
=======
The "Add other" feature inserts an additional `.o_other_input` text input next to the radio inputs (the free-text input shown when "Other" is selected). When loading the available condition values, the code iterated over every `.s_website_form_input` in the dependency container and looked up `label[for="${el.id}"]`. The `.o_other_input` has no `id` and no associated label, so `querySelector(...)` returned `null` and accessing `.textContent` threw.
The crash also prevented editing any field's label on the form until the page was reloaded.
Solution:
==========
Excluding `.o_other_input` from the iteration is correct: the "Other" choice is already represented in the list by its dedicated radio (with its own label), so the free-text payload input must not be treated as a separate condition value.
An alternative would have been to narrow the selector to `.s_website_form_input.form-check-input` (the class carried by radio and checkbox inputs), which also excludes the `.o_other_input`. The chosen approach (`:not(.o_other_input)`) is more explicit about the intent: skip the "Add other" payload input, regardless of any class additions to the radio/checkbox inputs in the future.
=> Visibility dependency loads correctly, only the radio choices
("Other" included via its radio label) are listed
opw-6170367
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes an issue where copying a user also duplicated their associated tasks, leading to shared task assignments. The change ensures that tasks are correctly isolated to the new user, preventing conflicts and simplifying task management. This improves data consistency and reduces potential errors.
Original PR description
Duplicating a user also duplicates all their task assignments because task_ids on res.users is missing copy=False. The new user ends up sharing the same tasks in project_task_user_rel, so removing a task from either user affects both. Forward-Port-Of: odoo/enterprise#114270 Forward-Port-Of: odoo/enterprise#114028
This update ensures that EC Sales Reports generated for the Swedish market (l10n_se) are exported to KVR in whole numbers, as required by Swedish tax regulations. Previously, the export included decimal places, which was incorrect. This fix corrects the rounding logic to meet reporting standards.
Original PR description
**PROBLEM** EC Sales Report in Sweden needs to be reported with integer values. **STEP TO REPRODUCE** 1. Install l10n_se 2. On the se company, create a invoice with lines with EU tax and confirm it. 3. Go to Accounting/Reporting/EC Sale List and export to KVR. 4. Notices the KVR uses numbers with decimals places. opw-6045289 Forward-Port-Of: odoo/enterprise#115980 Forward-Port-Of: odoo/enterprise#114292
This update prevents Odoo from crashing when viewing order details without a linked employee. Previously, enabling 'Log in with Employees' after processing an order would cause issues. Now, the 'Served By' field defaults to the user who created the order, ensuring a smoother experience.
Original PR description
**Before this commit** When trying to open an order's details, we would crash when that order does not have an employee associated with it. This can happen when the "Log in with Employees" setting is…
**Before this commit** When trying to open an order's details, we would crash when that order does not have an employee associated with it. This can happen when the "Log in with Employees" setting is enabled after at least one order has already been processed. **After this commit** If there isn't an `employee_id` associated with an order, don't try to overwrite the "Served By" field. By default, this should allow the name of the user who processed the order to be displayed. This can be seen in the original `getOrderFields()` method on the `OrderDetailsDialog` component. https://github.com/odoo/odoo/blob/e1c81c326e370b0a7b5bc8018b151e251ebce544/addons/point_of_sale/static/src/app/screens/ticket_screen/order_details_dialog/order_details_dialog.js#L81 This commit is mostly a backport of the slight refactor in 19.3, with the added benefit of still showing the names of the users who processed orders before `pos_hr` was installed on the database. https://github.com/odoo/odoo/blob/be57b42442db8c6be219d36f8c3e07e8baf45e31/addons/pos_hr/static/src/app/screens/order_details_dialog.js#L10-L15 opw-6169880
This update simplifies the process for Dutch companies to manage their digipoort certificates within the accounting settings. Previously, users had to navigate to a separate section to create a certificate before selecting it. Now, users can directly create and edit digipoort certificates within the primary accounting settings, improving usability.
Original PR description
Description of the issue this commit addresses: In the Accounting settings on a Dutch company, the setting for the selection of the digipoort certificate only lets you choose amongst existing certificates so if you haven't created one yet, you need to go to the dedicated certificates menu to create one and then come back to the digipoort certificate setting to set it. This is poor UX. --- Desired behavior after this commit is merged: This is improved by letting the user Create and Edit inside the digipoort certificate setting directly. --- task-6065566 Forward-Port-Of: odoo/enterprise#115755 Forward-Port-Of: odoo/enterprise#114307
This update fixes a bug preventing the correct import of PINT invoices for Australia, Japan, Myanmar, Singapore, and other regions. The changes include logic to identify the specific UBL document type for each region, ensuring accurate tax calculations and EDI processing. New test cases have been added to verify the improved functionality.
Original PR description
## PINT modules (`l10n_*_ubl_pint`)
The UBL module wasn't able to import PINT documents because there was no logic to detect the type of UBL document for PINT invoices (`urn:peppol:pint:billing-1@{anz, jp, my, sg}-1`). This PR adds the methods to detect PINT UBL documents and provide appropriate EDI decoder model names. Along with the fix, test cases are added to verify proper import of the said UBL's.
## Base EDI module (`account_edi_ubl_cii`)
Additionally, `_correct_invoice_tax_amount` in the base UBL import is fixed to only process TaxSubtotal nodes in the document currency. Previously it iterated over all `TaxTotal/TaxSubtotal` nodes regardless of currency, which caused the JP PINT import to pick up the company-currency tax amount instead of the document-currency one. JP PINT is the only format that includes TaxSubtotal in both TaxTotal nodes.
Forward-Port-Of: odoo/odoo#262010
Forward-Port-Of: odoo/odoo#258017This update ensures that 'Final Consumer' records created within the CO Edition are correctly identified as individuals, not companies. Previously, a calculation error resulted in these records being incorrectly classified. The fix includes a necessary adjustment to the data and updated tests to guarantee accurate record creation.
Original PR description
After changes on is_company field to be computed, Final Consumer was being created as a company. Although this is wrong, tests were not asserting correctly on how anonymous documents should be created. This commit fixes this by forcing the value to False and correcting the tests. task-6149751 Forward-Port-Of: odoo/enterprise#115560
This update resolves an issue where users lacked access to equity information for partners associated with different companies. The change adds a company identifier to equity models, ensuring accurate reporting and access to all relevant partner data, regardless of company affiliation. This enhances the reliability of equity reporting within the Odoo Enterprise system.
Original PR description
Before this commit, if you had some holders only visible to a company you don't have access to, the cap table would show an access error. This commit introduces multi-company logic to equity models by adding a new company_id field related to the company_id of the partner_id. Other partners (holder, seller, subscriber) will have their companies checked against that company. task-6018771 Forward-Port-Of: odoo/enterprise#110724
This update resolves an error that prevented users from submitting surveys with background images. The issue stemmed from outdated code referencing a removed component. The fix ensures background images load correctly during the survey submission process, improving the user experience.
Original PR description
### Issue before this commit: When the submit event is triggered, the system attempts to preload the background image for the next screen using SurveyPreloadImageMixin. However, this mixin is no longer used, which results in the following error: SurveyPreloadImageMixin is undefined ### Steps to Reproduce: 1. Install the Survey module 2. Create a new survey 3. Add a section with a background image 4. Add at least one question 5. Click on Test 6. Start the survey and submit the first page ### Cause of the Issue: The code still references SurveyPreloadImageMixin._preloadBackground, even though SurveyPreloadImageMixin has been removed/refactored. This leads to an undefined reference during execution. Refactored-commit: https://github.com/odoo/odoo/commit/50c03d966241da263a63ec7948e293a0475e9ba9 ### With This Commit: To ensure it works correctly, preloadBackground() is imported and called inside nextScreen(). opw-6165822 Forward-Port-Of: odoo/odoo#262424
This update clarifies the tax selection process on invoices for Saudi Arabia (l10n_sa). Previously, users incorrectly chose a general VAT tax, leading to compliance issues. This fix simplifies the settings and ensures accurate tax calculations according to ZATCA regulations.
Original PR description
This commit aims to make the invoice line tax drop-down cleaner and more straightforward. The tax `15% PH PE HS` is already handled through the `0% PE` and `0% PH` taxes and `0% Not Subject to VAT`…
This commit aims to make the invoice line tax drop-down cleaner and more straightforward. The tax `15% PH PE HS` is already handled through the `0% PE` and `0% PH` taxes and `0% Not Subject to VAT` is visible with the other `0%` taxes such as `0% EX G`, etc. The users were incorrectly selecting the `0% Not Subject to VAT` instead of the actual `0%` taxes according to the characteristics of the supply; leading to non-compliance with the ZATCA rules. Before this commit: - `15% PH PE HS` tax was `active`. - `0% PE & 0% PH` had distribution for invoices: `base tax grid = 3(B)` and distribution for refunds: `base tax grid = 3(B)`. - `0% Not Subject to VAT` tax was `active` and had distribution for invoice: `base tax grid = 3(B)` and distribution for refunds: `base tax grid 3(B)` - `0% IT G and 0% QT` taxes were `active`. After this commit: - `15% PH PE HS` tax is `inactive`. - `0% PE & 0% PH` taxes have distribution for invoices: `base tax grid = 2(B)` and distribution for refunds: `base tax grid = 2(B)` - `0% Not Subject to VAT` tax is set to `inactive`, `sequence = 17` and tax grid has been removed. - `0% IT G and 0% QT` taxes have been set to `inactive`. task-5959979 Forward-Port-Of: odoo/odoo#253598
This update resolves visual issues and ensures accurate Saudi document formatting. Specifically, it dynamically updates VAT information and standardizes paper formats for Saudi companies, improving the clarity and reliability of printed reports.
Original PR description
This commit introduces several improvements and fixes to the Saudi document layouts and company configurations: - Removes the redundant VAT number from document layout header to resolve visual overlapping with other elements. - Extracts `l10n_sa_edi_additional_identification_scheme` and `l10n_sa_edi_additional_identification_number` from static company details and injects them dynamically into document layouts so they always remain up-to-date when printed. - Updates the configuration logic to ensure the default Saudi paper format is applied to all SA companies. task-6040091 Forward-Port-Of: odoo/odoo#255463
This update corrects a technical issue where the Dutch translations for the 'l10n_nl_returns' module were missing from the project's translation files. Adding these translations ensures accurate and complete functionality for Dutch-speaking users of the Enterprise software. This resolves a potential display issue and improves the user experience.
Original PR description
This [commit](a6a8d121bbf2044793df5211c5bdb18859a62152) introduced a new module in a stable version (19.0) without the required key in the `.weblate.json` file. This commit aims at fixing that to ensure translations are handled correctly. Forward-Port-Of: odoo/enterprise#115753
This update resolves an issue preventing correct December pay calculations after migrating to a new data structure. The fix adds necessary input definitions, ensuring the wizard accurately writes pay values and avoids calculation errors. This ensures accurate payroll processing for Belgian users.
Original PR description
Purpose: after migrating to property inputs, the inputs for december pay weren't added to the properties definition so when you use `action_validate` in the december pay wizard, the values weren't written to these inputs as they don't exist in the definition task-id: 6103779 Forward-Port-Of: odoo/enterprise#105075
14 changes
Resolved issues and error corrections
A small typo in the quality module caused new quality alert records to be incorrectly grouped as 'None'. This update corrects the typo, ensuring records are properly assigned to the correct stages when created. This resolves a potential issue with data accuracy.
Original PR description
Issue: ------- While adapting the 'Domain' in the PR https://github.com/odoo/enterprise/commit/07b34a2e927347ca5c839ec632808adb02703e1f there occurred a typo where '|' got replaced with the '&' and causing the records getting grouped in 'None' when creating. Solution: ------------ To replace '&' with '|' to get the records grouped under the correct stage. Steps to reproduce: ----------------------- 1. In v19.0, in quality module try to create a quality alert record. 2. Just like that the newly created record will be under 'None'. Reference Image: <img width="1105" height="407" alt="image" src="https://github.com/user-attachments/assets/4c9c33be-ec06-4f06-8245-54dbe4473bc0" /> OPW - [6074016](https://www.odoo.com/odoo/project/70/tasks/6074016) Forward-Port-Of: odoo/enterprise#113108
This update corrects a technical issue that was causing unwanted options to appear in the email marketing builder. Specifically, it ensures the image transform option is hidden, and adds visibility to the Background Color and Border options. This improves the user experience and consistency within the mass mailing builder.
Original PR description
Commit 1 -------------- From the [commit], the options API was refactored to not use `OptionComponent` when adding an option. The mass mailing builder used the `ImageToolOptionPlugin` which replaced…
Commit 1 -------------- From the [commit], the options API was refactored to not use `OptionComponent` when adding an option. The mass mailing builder used the `ImageToolOptionPlugin` which replaced the `OptionComponent` with some modified version. As the `OptionComponent` is no longer present in the base option, patching the same won't use the modified option. Hence, the option became visible in the mass mailing builder. This commit adapts the mass mailing builder with the refactoring of the options API to keep the image transform option hidden. [commit]: https://github.com/odoo/odoo/commit/179480d996a19dff4d56265a610259b1c6e33f99 Commit 2 ------------------- ### Steps to reproduce 1. Open Email Marketing 2. Open/Create a Mailing 3. In the editor, insert an `Alert` block. --------> Some options won't be visible. ### Technical The [commit] restructured the `Alert` snippet, therefore, for the builder to identify the mass mailing's alert block, we need to adapt the selector of the option to `.s_mail_alert`. After this commit, the following options will become visible (which were invisible before the commit): - Background Color - Border Option Note: 1. mass_mailing's `Alert` option now correctly uses the mass mailing's option template. Which included different size options, but those are now already added by `size_option_plugin`. Therefore this commit also removes those redudant size options from the alert option. 2. The width option for the `Alert` block is already added by original `width_option_plugin`, therefore we remove the patch of the selector inside mass mailing to avoid redundancy. [commit]: https://github.com/odoo/odoo/commit/b6e51609807bdb771f305ba289aafe3e2b9b26b6 Task-5999942 Forward-Port-Of: odoo/odoo#260923
This update resolves an issue preventing the `sale_stock` and `purchase_stock` modules from installing correctly on databases with existing sale or purchase orders that include non-stock items like downpayments. The fix filters out these lines during the installation process, preventing a software error and ensuring proper module functionality.
Original PR description
## Summary When installing `sale_stock` or `purchase_stock` module on a database that already has sale/purchase orders with non-stock lines (downpayments, section notes), the installation fails with:…
## Summary
When installing `sale_stock` or `purchase_stock` module on a database that already has sale/purchase orders with non-stock lines (downpayments, section notes), the installation fails with:
ValueError: Expected singleton: uom.uom()
## Root Cause
The `post_init_hook` (`_create_pickings_for_open_sale_orders` / `_create_pickings_for_open_purchase_orders`) filters order lines to create pickings:
```python
empty_lines = open_sale_orders.order_line.filtered(
lambda l: l.product_uom_id.is_zero(l.qty_delivered)
)
```
This accesses product_uom_id without checking if it exists. Lines with:
- display_type set (sections, notes)
- is_downpayment = True (downpayments)
...don't have a product_id or product_uom_id, causing the error.
Fix
Add filters to skip non-stock lines before accessing product_uom_id:
```
empty_lines = open_sale_orders.order_line.filtered(
lambda l: not l.display_type and not l.is_downpayment and l.product_uom_id.is_zero(l.qty_delivered)
)
```
Steps to Reproduce
1. Create a fresh database (without sale_stock/purchase_stock)
2. Create a sale order with a downpayment line or section/note
3. Install sale_stock module
4. Error: ValueError: Expected singleton: uom.uom()
Reproduction Reference
- purchase_stock issue: https://drive.google.com/file/d/1aKw-ago-pMds_-x_y9f8nJZyZsLqGJ67/view?usp=sharing
- sale_stock issue: https://drive.google.com/file/d/1I9fY8UZZZ3ULcairl3YGZTi_KttsYLNR/view?usp=sharing
opw-6179073
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prAn error prevented users from importing emissions data through the Emitted Emissions menu. This fix restricts imports to manual emissions, resolving a database conflict issue related to journal entry emissions. This ensures data integrity and stability within the ESG reporting functionality.
Original PR description
The import button is present in the Emitted Emissions menu, but it produces the following error: "cannot insert into view 'esg_carbon_emission_report' DETAIL: Views containing UNION, INTERSECT, or EXCEPT are not automatically updatable." => To fix this, we will only allow the insertion of manual emissions (model: other.emission) via import, not emissions related to journal entries. task-6168587 Forward-Port-Of: odoo/enterprise#115856 Forward-Port-Of: odoo/enterprise#115306
This update optimizes appointment scheduling by only calculating availability for the current month instead of pre-computing all slots. This change significantly reduces the system's workload and improves response times when users are booking appointments, leading to a smoother user experience. It addresses a performance bottleneck related to appointment slot generation.
Original PR description
Generate all slots and compute only availabilities for the display month instead of pre-computing all slots for the whole booking period. task-4144524 Forward-Port-Of: odoo/enterprise#115986
This update ensures that 'Final Consumer' records are correctly created as individuals, not companies, within the Odoo system. The previous issue stemmed from incorrect test assertions related to anonymous document creation. This fix resolves the problem by explicitly setting the 'Final Consumer' type to 'individual' and updating associated tests.
Original PR description
After changes on is_company field to be computed, Final Consumer was being created as a company. Although this is wrong, tests were not asserting correctly on how anonymous documents should be created. This commit fixes this by forcing the value to False and correcting the tests. task-6149751
This update simplifies the process for Dutch companies to manage their digipoort certificates. Previously, users had to navigate between separate menus to create and select a certificate. Now, users can directly create and edit digipoort certificates within the main Accounting settings, improving the user experience.
Original PR description
Description of the issue this commit addresses: In the Accounting settings on a Dutch company, the setting for the selection of the digipoort certificate only lets you choose amongst existing certificates so if you haven't created one yet, you need to go to the dedicated certificates menu to create one and then come back to the digipoort certificate setting to set it. This is poor UX. --- Desired behavior after this commit is merged: This is improved by letting the user Create and Edit inside the digipoort certificate setting directly. --- task-6065566 Forward-Port-Of: odoo/enterprise#115755 Forward-Port-Of: odoo/enterprise#114307
This update resolves an issue where users couldn't access equity information for partners linked to companies they didn't have access to. The change adds a 'company_id' field to equity models, allowing the system to correctly identify and display equity data for all partners, regardless of their associated company.
Original PR description
Before this commit, if you had some holders only visible to a company you don't have access to, the cap table would show an access error. This commit introduces multi-company logic to equity models by adding a new company_id field related to the company_id of the partner_id. Other partners (holder, seller, subscriber) will have their companies checked against that company. task-6018771 Forward-Port-Of: odoo/enterprise#110724
This update resolves an issue where the survey module would fail to load background images due to an outdated reference to a component that was no longer used. The fix ensures the background image loading process is correctly implemented, preventing the error and improving the survey experience. This ensures surveys load correctly and reliably.
Original PR description
### Issue before this commit: When the submit event is triggered, the system attempts to preload the background image for the next screen using SurveyPreloadImageMixin. However, this mixin is no longer used, which results in the following error: SurveyPreloadImageMixin is undefined ### Steps to Reproduce: 1. Install the Survey module 2. Create a new survey 3. Add a section with a background image 4. Add at least one question 5. Click on Test 6. Start the survey and submit the first page ### Cause of the Issue: The code still references SurveyPreloadImageMixin._preloadBackground, even though SurveyPreloadImageMixin has been removed/refactored. This leads to an undefined reference during execution. Refactored-commit: https://github.com/odoo/odoo/commit/50c03d966241da263a63ec7948e293a0475e9ba9 ### With This Commit: To ensure it works correctly, preloadBackground() is imported and called inside nextScreen(). opw-6165822 Forward-Port-Of: odoo/odoo#262424
This update resolves visual issues with Saudi document layouts by dynamically updating VAT information and ensuring the correct paper format is applied to all Saudi companies. This improves the accuracy and presentation of invoices and other financial documents for our Saudi customers.
Original PR description
This commit introduces several improvements and fixes to the Saudi document layouts and company configurations: - Removes the redundant VAT number from document layout header to resolve visual overlapping with other elements. - Extracts `l10n_sa_edi_additional_identification_scheme` and `l10n_sa_edi_additional_identification_number` from static company details and injects them dynamically into document layouts so they always remain up-to-date when printed. - Updates the configuration logic to ensure the default Saudi paper format is applied to all SA companies. task-6040091 Forward-Port-Of: odoo/odoo#255463
This update corrects a technical issue where translations for the Dutch returns module (l10n_nl_returns) were missing in the system's configuration. Adding these translations ensures accurate and localized functionality for our Dutch-speaking customers. This resolves a potential problem with incorrect display or functionality.
Original PR description
This [commit](a6a8d121bbf2044793df5211c5bdb18859a62152) introduced a new module in a stable version (19.0) without the required key in the `.weblate.json` file. This commit aims at fixing that to ensure translations are handled correctly. Forward-Port-Of: odoo/enterprise#115753
This update corrects a setting for Thai WHT (Withholding Tax) taxes, ensuring they don't automatically generate closing entries. WHT uses separate accounts, simplifying reporting and aligning with local tax regulations. This change improves the accuracy of WHT financial reporting.
Original PR description
Set tax closing entry to False by default for WHT taxes, as WHT uses separate payable accounts and does not require closing entries. task-6146195 Forward-Port-Of: odoo/odoo#262464
This update resolves a visual glitch where the user status icon on the dashboard displayed a grey question mark instead of the correct work location. The fix standardizes the data format used for user status, ensuring the icon accurately reflects the user's location setting. This improves the user experience and consistency.
Original PR description
Steps to reproduce: ------------------------------ 1. Install `hr_homeworking` module 2. Go to User > Calendar Tab 3. Set location for the days (e.g, 'Office' for M-F, 'Home' for Sat/Sun) 4. Go back…
Steps to reproduce:
------------------------------
1. Install `hr_homeworking` module
2. Go to User > Calendar Tab
3. Set location for the days (e.g, 'Office' for M-F, 'Home' for Sat/Sun)
4. Go back to the app dashboard and reload
Observation:
------------------------------
You'll see that the status icon (top right) flashes online and then remains as the grey circle with a question mark.
Issue:
------------------------------
The im_status field had an inconsistent format across different parts of the codebase:
* `res_users.py` was setting `im_status` as `presence_office_online` (3-part format)
* `res_partner.py` was setting `im_status` as `office_online` (2-part format) https://github.com/odoo/odoo/blob/5d88f089764b08ef8fd06dc4add7cb6f4815f307/addons/hr_homeworking/models/res_partner.py#L18
* `im_status_patch.xml` expected the 2-part format and checked `persona.im_status.split('_').length == 2`
https://github.com/odoo/odoo/blob/5d88f089764b08ef8fd06dc4add7cb6f4815f307/addons/hr_homeworking/static/src/im_status_patch.xml#L6
When users had a work location set, `res_users._compute_im_status()` produced the 3-part format (presence_office_online), which failed the XML template's length check. This caused the template to fall through to the default '' placeholder, displaying a grey question mark icon instead of the proper location icon.
Solution:
------------------------------
Standardized on the 2-part format (location_status) because:
* Minimal changes required - Only 2 files needed modification
* Aligns with existing code - `res_partner.py` and `im_status_patch.xml` already used this format
https://github.com/odoo/odoo/blob/5d88f089764b08ef8fd06dc4add7cb6f4815f307/addons/hr_homeworking/static/src/im_status_patch.xml#L6
* Backward compatible - The main `im_status` template logic was already designed for this format
`avatar_card_resource_popover.xml` had hardcoded checks for the 3-part format (presence_home_online, presence_office_away, etc.). After fixing `res_users.py to use the 2-part format, these hardcoded checks would never match, causing the avatar card popover to not display location icons
opw-6064997
Forward-Port-Of: odoo/odoo#258829This update fixes a technical issue that caused a traceback when canceling an empty order in the Point of Sale (POS) system, specifically when loyalty programs were active. The fix ensures the POS dialog is closed before order deletion, preventing a re-render and the resulting error. This improves stability and prevents unexpected errors during order cancellation.
Original PR description
Steps to reproduce: = - Enable loyalty in the POS configuration. - Add an eWallet program for this POS. - Open a table and cancel the (empty) order using the "Cancel Order" control button. Issue: = - A traceback occurs: `TypeError: Cannot read properties of undefined (reading 'getTotalWithTax')` Reason: = - When clicking "Cancel Order", the order is deleted and `currentOrder` becomes `undefined`. - During the re-render of `ControlButtons` on the product screen, there is no active order, which leads to the traceback. Fix: = - Ensure the `ControlButtons` dialog is closed before deleting the order to prevents the re-render of `ControlButtons` without an active order and avoids the traceback. task-6030182 Forward-Port-Of: odoo/odoo#261775 Forward-Port-Of: odoo/odoo#254337
3 changes
New functionality added to Odoo
This update prepares Odoo for a new Belgian VAT regulation, effective May 1st. It introduces a new 'Tax Provision Account' (411800) to accurately reflect VAT returns, aligning with the latest accounting standards. This ensures accurate financial reporting for businesses operating in Belgium.
Original PR description
Starting May 1st, in Belgium the VAT provision account will replace the current account for periodic returns - Adding the new bank account - Adding a new account 'Tax Provision Account' 411800 Community PR: odoo/odoo#255272 Task [link](https://www.odoo.com/odoo/project.task/6044017) task-6044017 Forward-Port-Of: odoo/enterprise#115777 Forward-Port-Of: odoo/enterprise#111599
Resolved issues and error corrections
This update resolves an issue where Amazon's stock synchronization was failing due to incorrect fulfillment channel data. The system now uses a new API field to accurately determine channel availability, defaulting to FBM when necessary to ensure stock updates continue. The change also improves how user-specific configurations are handled during synchronization.
Original PR description
During the upgrade from XML-based feeds to the new JSON Listings API for stock management, we chose to use Amazon's API to fetch a listing's fulfillment channel information. However, Amazon does not…
During the upgrade from XML-based feeds to the new JSON Listings API for stock management, we chose to use Amazon's API to fetch a listing's fulfillment channel information. However, Amazon does not provide a clear answer for a given listing. After some research, we assumed an offer was FBM when the listing contained a `merchant_shipping_group`, because this setting is specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58. This assumption was flawed: Amazon can keep the shipping group even after a listing switches to FBA, which can block stock synchronization. This commit uses the `fulfillmentAvailability` field from the Listings API instead. This field stores the available quantity for each fulfillment channel in which the listing is sold. When multiple fulfillment channels are present, the offer defaults to FBM so stock synchronization can continue. The `sale_amazon_channel_management` module can then be installed to manually select and disambiguate the channel. This commit also upgrades the patching method used to update the FBM stock to ensure user specific configuration aren't overriden during the synchronization. opw-6064896 opw-5152359 Forward-Port-Of: odoo/enterprise#114473
This update fixes an issue where users could accidentally select customers from different companies within the Helpdesk module. The fix involved adding a restriction to the customer selection process, ensuring users only see customers within their assigned company. This improves data accuracy and prevents misdirected support tickets.
Original PR description
Steps to reproduce: - - Create two companies (Company A and Company B) - Create one partner in each company - Enable both companies for the user - Open Helpdesk and go to the tickets Kanban view for a Company A team. - In the quick create form, the customer dropdown shows customers from Company B Issue: - - Customers from other companies are visible in the customer field, Cause: - - The partner_id field in the quick create view had no domain, so it displayed partners from all allowed companies. Solution: - - Added a domain on partner_id in the Python field. task-4971466 Forward-Port-Of: odoo/enterprise#111909
7 changes
Enhancements to existing features
This update simplifies the process for users experiencing issues downloading the SSL certificate. The homepage now displays a clear warning message, eliminating the need to manually check logs and reducing potential user frustration. This improves the overall user experience and troubleshooting.
Original PR description
We improved the certificate status warning displayed on the homepage to avoid having to check the logs to know what went wrong while downloading the SSL certificate. Forward-Port-Of: odoo/odoo#232670 Forward-Port-Of: odoo/odoo#232471
Resolved issues and error corrections
This update fixes an issue where the system incorrectly reserved stock quantities when using the 'Smallest number of packages' removal strategy. The fix ensures that stock is accurately reserved, preventing over-reservation and ensuring correct inventory management. This improves the reliability of stock tracking.
Original PR description
Issue ----- When there is a packaged quant in stock, the `least package` removal strategy has unexpected behaviour. Steps to reproduce ----- - Enable packages - Create a product AAA tracked by SN -…
Issue ----- When there is a packaged quant in stock, the `least package` removal strategy has unexpected behaviour. Steps to reproduce ----- - Enable packages - Create a product AAA tracked by SN - product category removal strategy set to "Smallest number of packages" - Create a reception for 5 units - Generate serials - Put last line in pack - Confirm reception - Create delivery for 2 units of AAA - Mark as Todo - Change the quants taken: instead of SN 5, take SN 3 (so take SN 3 & 4) - Create a delivery for 3 units of AAA - Mark as Todo > Quantity reserved is one, it only reserved SN 5 Cause ----- The problem arises in `_run_least_packages_removal_strategy_astar`. Because there is an available quant inside a package, we continue past https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L675-L676 We end up at https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L724 The `generate_domain` function has a problem: if there sin't enough products inside packages to satisfy the demand, it searches for items not in packages to take from. https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L701-L705 This search is flawed, because it does not take into account the fact that the quant might already be reserved. So it expands the domain with an `AND` on quant ids that are not available. This leads to `quants` in `_get_reserve_quantity` containing unavailable quants https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L866 This later gets "caught" in `available_quantity` https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L897 and the quants don't get reserved a second time thanks to https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L912-L914 but this also means the reservation is incomplete. Note that calling `action_assign` a second time will correctly reserve the remaining quantities, as there is no package left to reserve in stock, so we do go in https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L675-L676 and avoid the faulty logic. Solution ----- Ideally, we would use the value of `available_quantity` in our search domain. However, the field is not stored https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L88-L91 Our options are: - make the field stored (not stable) - add a search function - filter reserved quants out of `single_item_ids` First option is not stable. Second option requires subqueries to compare `quantity` and `reserved_quantity`. Third option is the least bad one, with only a very situational performance loss. ----- Ticket: opw-5972350 Forward-Port-Of: odoo/odoo#261568 Forward-Port-Of: odoo/odoo#256106
This update resolves an issue where multiple documents with the same subject wouldn't all be included in the downloaded zip file. The fix ensures that all signed documents with identical subjects are correctly bundled together, preventing data loss. This improves the reliability of the Sign app's download feature.
Original PR description
## Issue In the *Sign* app, when attempting to download multiple documents with similar subjects, only one document appears in the resulting zip file. ## Steps to reproduce 1. Install *Sign* (`sign`)…
## Issue
In the *Sign* app, when attempting to download multiple documents with similar subjects, only one document appears in the resulting zip file.
## Steps to reproduce
1. Install *Sign* (`sign`)
2. Sign a same template twice, using the same subject S1. This gives us Documents D1 an D2.
3. (Optionally), sign the same template a third time, using a different subject S2, creating document D3.
4. In Sign > Documents, select the 2 (3) signed documents and click *Download*.
5. **In the resulting zip file, there's one folder S1 containing a single pdf document (D1) (and one folder S2 containing D3). Document D2 is missing from the zip file.**
## Cause
When generating the zip file, the path used for each document is `{subject}/{doc_name}`.
https://github.com/odoo/enterprise/blob/863abc99469c12acdebcab05788d566c370bb46f/sign/controllers/main.py#L276-L286
Neither of this attribute are unique, which means that two signed documents with the same name and subject can be downloaded simultaneously, but will then overwrite each other.
## Fix
Before version 18.3, the zip file would contain folders named with the (unique) request id, which would consistently make them distinct from one another. This behavior was changed by https://github.com/odoo/enterprise/commit/4254542e8fb4ce3b2b9b46c624d86f7fcac8df7b to use the `sign_request.subject` instead. This commit adds the `request.id` after the subject to keep the clarity of the subject, and add the uniqueness of the id.
opw-6143128This update fixes a bug that prevented users from assigning recruiters to job positions when the hr_payroll module wasn't installed. The change ensures the necessary data is always available, resolving an error message and improving the usability of the recruitment process. This update doesn't impact any core functionality.
Original PR description
**Steps to Reproduce:** 1. Ensure hr_payroll module is NOT installed 2. Open a Job Position in hr_recruitment app 3. Click on "Assign Recruiter" button for a position without a recruiter 4. Observe error: "Name 'company_id' is not defined" **Bug Cause:** The interviewer_ids field on hr.job uses a string domain that references company_id. Since company_id is not available in the current view without hr_payroll it fails. **Solution:** Add `<field name="company_id"/>` to the hr_job_kanban view to ensure the field is consistently available for domain evaluation regardless of other installed modules. **Task:** 6106143 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259305
This update fixes a bug preventing website appointment syncs from appearing in Outlook calendars. Previously, a timing issue with the synchronization cron prevented events created through appointments from being properly synced. This change ensures all website appointments are now reliably synchronized with Outlook, improving user scheduling and calendar integration.
Original PR description
Before this change, the "Outlook: synchronization" cron would not create calendar events on Outlook's side in _sync_odoo2microsoft due to a filter for calendar.events written to within 5 minutes of…
Before this change, the "Outlook: synchronization" cron would not create calendar events on Outlook's side in _sync_odoo2microsoft due to a filter for calendar.events written to within 5 minutes of microsoft_last_sync_date, when _sync_data is not called when a calendar.event is created, such as through website.appointment. microsoft_last_sync_date was set to datetime.now() at the beginning of _sync_microsoft_calendar, which would skip a large period of time between the last sync and now, if the only syncs were triggered through cron, and not _sync_data (by opening the calendar app). To reproduce, Default "Outlook: synchronization" is ran every 12 hours. 1) Calendar event is synced through "Outlook: synchronization" cron at 00:00, setting microsoft_last_sync_date to 00:00 2) A website.appointment is created for a resource with Outlook calendar sync enabled any time between 00:01 - 11:54. 3) "Outlook: synchronization" runs again at 12:00, which sets microsoft_last_sync_date to 12:00, and filters out calendar.events based on their write_dates in _extend_microsoft_domain that need syncing outside of 11:55 to 12:00. This change removes setting of microsoft_last_sync_date at the beginning of _sync_microsoft_calendar, where we need to use the old value before setting it at the end of _sync_microsoft_calendar. opw-5212908 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261935 Forward-Port-Of: odoo/odoo#245964
This update corrects a problem with the Intrastat CSV export functionality, which was broken following a technical update in version 18.0. The fix ensures accurate data is exported by addressing formatting errors and database synchronization, preventing potential reporting discrepancies.
Original PR description
Since the technical refactoring of intrastat in 18.0, the csv export in `l10n_nl_intrastat` seems broken. Here is the fixes done in this commit: 1. `Commodity flow` is supposed to be a single diggit (6 or 7) but an empty blank space was hidden. 2. Switching the condition on `country_origin_code` as it was the opposite 3. Add a `flush_all` before calling the report during the export, to be sure the database is up to date. opw-5799126 Forward-Port-Of: odoo/enterprise#116004 Forward-Port-Of: odoo/enterprise#115791
This update fixes an issue where users could select customers from different companies within the Helpdesk system. The fix involved adding a restriction to the customer selection process, ensuring users only see customers within their assigned company. This improves data accuracy and prevents incorrect customer assignments.
Original PR description
Steps to reproduce: - - Create two companies (Company A and Company B) - Create one partner in each company - Enable both companies for the user - Open Helpdesk and go to the tickets Kanban view for a Company A team. - In the quick create form, the customer dropdown shows customers from Company B Issue: - - Customers from other companies are visible in the customer field, Cause: - - The partner_id field in the quick create view had no domain, so it displayed partners from all allowed companies. Solution: - - Added a domain on partner_id in the Python field. task-4971466 Forward-Port-Of: odoo/enterprise#111909
6 changes
Resolved issues and error corrections
This update resolves an issue where Amazon's stock synchronization was failing due to incorrect fulfillment channel data. The system now uses a new API field to accurately determine channel availability, defaulting to FBM when necessary to ensure stock updates continue. The update also improves the process for handling user-specific configurations.
Original PR description
During the upgrade from XML-based feeds to the new JSON Listings API for stock management, we chose to use Amazon's API to fetch a listing's fulfillment channel information. However, Amazon does not…
During the upgrade from XML-based feeds to the new JSON Listings API for stock management, we chose to use Amazon's API to fetch a listing's fulfillment channel information. However, Amazon does not provide a clear answer for a given listing. After some research, we assumed an offer was FBM when the listing contained a `merchant_shipping_group`, because this setting is specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58. This assumption was flawed: Amazon can keep the shipping group even after a listing switches to FBA, which can block stock synchronization. This commit uses the `fulfillmentAvailability` field from the Listings API instead. This field stores the available quantity for each fulfillment channel in which the listing is sold. When multiple fulfillment channels are present, the offer defaults to FBM so stock synchronization can continue. The `sale_amazon_channel_management` module can then be installed to manually select and disambiguate the channel. This commit also upgrades the patching method used to update the FBM stock to ensure user specific configuration aren't overriden during the synchronization. opw-6064896 opw-5152359 Forward-Port-Of: odoo/enterprise#114473
This update adds logging of Amazon's request IDs for SP-API responses. Previously, these IDs were missing, making it harder for support teams to troubleshoot issues with Amazon. Logging these IDs will significantly improve response times and resolution for support requests.
Original PR description
Each response from Amazon's SP-API includes a request identifier used by their support team for debugging. This identifier was not previously logged, making support investigations more difficult. Forward-Port-Of: odoo/enterprise#114483
This update corrects a bug that prevented users from saving accounting settings when GST registration was unregistered. The fix ensures the system correctly checks GST registration status, preventing a 'Missing Required Fields' error and allowing users to configure the module properly. This improves the usability of the Invoicing module for businesses operating in India.
Original PR description
**Steps to reproduce:** * Install `l10n_in` module. * Go to Accounting > Settings. * Check 'Fetch Vendor E-Invoiced Document` and clear the GST Username * Uncheck `Registered Under GST`. * Try to…
**Steps to reproduce:** * Install `l10n_in` module. * Go to Accounting > Settings. * Check 'Fetch Vendor E-Invoiced Document` and clear the GST Username * Uncheck `Registered Under GST`. * Try to modify any setting and save. **Observed behavior:** * A `Missing Required Fields` error is raised even though no visible field is missing a value. **Cause:** * The `l10n_in_gstr_gst_username` field is placed inside a `div` that is hidden when `l10n_in_is_gst_registered` is `False`. * However, its `required` condition only checked `l10n_in_gst_efiling_feature or l10n_in_fetch_vendor_edi_feature`, without accounting for `l10n_in_is_gst_registered`. * Since both features default to enabled, the field remained required even when invisible, blocking any settings save. **Fix:** * Update the `required` attribute on `l10n_in_gstr_gst_username` to include `l10n_in_is_gst_registered` as a condition, so the field is only required when the GST section is visible and either `GST E-Filing & Matching` or `Fetch Vendor E-Invoiced Document` is enabled. opw-6133001
This update resolves an issue where multiple users were incorrectly added to WhatsApp discussion channels after a message was sent. The fix ensures that only the user who initiated the conversation is added to the channel, preventing unnecessary notifications and channel clutter. This improves the user experience and channel management efficiency.
Original PR description
…ser sends a template message when creating discussion channels after the partner sends a message back. Issue: Currently, When there are multiple users listed under whatsapp.account.notify_user_ids no matter what, when creating a new discuss channel it will add all users in that list. Even when a single user inside that list initiated the conversation with a template. To replicate in runbot add multiple users to whatsapp.account.notify_user_ids, make a partner with a number, send a template, then have the partner send a message back. All users will be notified and added to the channel. There was an unformatted number being passed to a function that required the formatted number. This caused _find_active_channel to find 0 active channels. Fix: Format the number received from the message values inside WhatsAppAccount._process_messages opw-5349138 Forward-Port-Of: odoo/enterprise#102452
This update resolves a problem with the CSV export for Dutch Intrastat reporting, which was broken following a recent technical update. The fix addresses an incorrect formatting of 'Commodity flow' data and ensures the database is up-to-date before generating the report, improving data accuracy for reporting.
Original PR description
Since the technical refactoring of intrastat in 18.0, the csv export in `l10n_nl_intrastat` seems broken. Here is the fixes done in this commit: 1. `Commodity flow` is supposed to be a single diggit (6 or 7) but an empty blank space was hidden. 2. Switching the condition on `country_origin_code` as it was the opposite 3. Add a `flush_all` before calling the report during the export, to be sure the database is up to date. opw-5799126 Forward-Port-Of: odoo/enterprise#115791
This update resolves an issue where users could accidentally select customers from different companies within the Helpdesk module. The fix adds a restriction to the customer selection field, ensuring users only see customers within their assigned company. This improves data accuracy and prevents potential errors in ticket management.
Original PR description
Steps to reproduce: - - Create two companies (Company A and Company B) - Create one partner in each company - Enable both companies for the user - Open Helpdesk and go to the tickets Kanban view for a Company A team. - In the quick create form, the customer dropdown shows customers from Company B Issue: - - Customers from other companies are visible in the customer field, Cause: - - The partner_id field in the quick create view had no domain, so it displayed partners from all allowed companies. Solution: - - Added a domain on partner_id in the Python field. task-4971466 Forward-Port-Of: odoo/enterprise#111909
24 changes
New functionality added to Odoo
This update introduces a preview of the DMFA report within the Odoo Enterprise application. This allows users to quickly review the report's formatting and content before generating the final report, improving accuracy and reducing potential errors. It's a small enhancement to the payroll reporting process.
Original PR description
Task: 6067446
This update adds support for calculating Benefits in Kind (BIK) for Electricity, Heating, Housing, Reclassified Rents, and Supplementary Pension in the Belgian payroll. It introduces new salary rules and data fields to accurately reflect these benefits, ensuring compliance with Belgian tax regulations. Updated reports and calculations now include these new BIK values.
Original PR description
This commit introduces five new Benefits in Kind (ATN/VAA) to the Belgian payroll localization: Electricity, Heating, Housing, Reclassified Rents, and Supplementary Pension. Changes included: - Added monetary fields for the new benefits on `hr.version` and `hr.employee`. - Inserted the new fields into the `hr.employee` payroll view form. - Created 5 new regular salary rules (e.g., ATN_ELEC, ATN_HEATING) to calculate the ATN. - Updated the `cp200_employees_termination_fees_advantage_any_kind` salary rule to automatically include these new benefits in the severance pay calculation. - Included the new BIK codes in the 281.10 XML generation (`l10n_be_281_10.py`) - Added the new BIK codes to the Social Security Certificate (`l10n_be_social_security_certificate.py`) - Updated unit tests to verify the payslip computation and employer cost impacts for each new benefit. Task: 6090160
This update introduces a new type of payslip – the 'arrear payslip' – to accurately reflect unpaid salaries in Belgium. It includes specific tax rules and triggers necessary accounting adjustments (DMFA regeneration) for accurate reporting on financial statements (fiches 273.10 and 281.10).
Original PR description
In this commit we introduce the arrear payslips: - Add a boolean to mark a regular payslip as an arrear payslip. - Implement a specific withholding tax rule for arrear payslips. - Trigger DMFA regeneration for the same period upon validation of an arrear payslip. - Ensure arrear payslips are counted in the year of creation (not the targeted period) for fiches 273.10 and 281.10.
Enhancements to existing features
This update adds more thorough tests for the longpolling functionality within Odoo Enterprise. Specifically, the tests now verify how the system handles network errors, ensuring a more reliable response when connectivity issues occur. This improves the overall stability and robustness of the IoT integration.
Original PR description
This commit adds tests for the `onMessage` method of the longpolling JS class, and in particular tests the recently added behaviour where the polling request returns an 'unreachable' result when a network error occurs.
This update ensures accurate tax calculations for employees with Income from Let-Out Property, aligning with Indian tax regulations. A 30% standard deduction is now applied to rental income, and a new configuration option allows for future adjustments. This change improves compliance and reporting accuracy for Indian users.
Original PR description
Purpose: Ensure correct tax computation for Income from Let-Out Property by applying the standard 30% deduction as per Indian tax regulations. This PR includes: - Applied 30% standard deduction on let-out property during tax input value computation. - Added rule parameter for let-out property deduction to allow future changes via configuration. - Updated tax input values to consider only 70% of the declared rental income for tax calculation. - Added tooltip on let-out property field to clarify that a 30% standard deduction is applied on gross rental income for tax computation. This change aligns the payroll tax computation with Indian income tax rules, Income from Let-Out Property is calculated after deducting the standard maintenance deduction of 30% from the gross annual rental income. task-5848157 Forward-Port-Of: odoo/enterprise#112969
This update introduces a 'Changes Summary' report for Engineering Change Orders (ECOs), streamlining the process of reviewing updates to Bills of Materials. Previously, users had to navigate multiple tabs to understand component, operation, and by-product changes. This new report consolidates all relevant information into a single, easily digestible view, improving efficiency.
Original PR description
This commit introduces a new report "Changes Summary" to Engineering Change Order (ECO) model. Previous to this commit, users had to navigate through 4 different tabs to analyze the changes of the new versions of the BoM: components, operations, instructions and by-products. This commit removes these tabs and replaces them with one comprehensive report that shows all the changes next to each other. Task-5343222
Resolved issues and error corrections
This update automatically generates a new offer link token each time an offer email is sent, eliminating the need for manual token changes. This improves security by invalidating compromised tokens and simplifies the process for users. Minor adjustments were made to related tours to account for the new token generation process.
Original PR description
In the case that an offer link is compromised, the access token needs to be changed to invalidate the old one. Right now it has to be done manually. This commit removes the ability to edit access…
In the case that an offer link is compromised, the access token needs to be changed to invalidate the old one. Right now it has to be done manually. This commit removes the ability to edit access tokens manually and instead generates a new access token whenever an offer email is sent. The reason why the access token is set in the "MailComposeMessage" class instead of directly inside the "HrContractSalaryOffer" class is that the "Send by Email" button on the offer form doesn't directly send the email, it instead opens a dialogue to edit it before sending. In this dialogue, the user can just discard the email. If the access token was set when the dialogue was opened, discarding the email would change the access token of the offer without sending the new link. Instead of this the access token is updated right before sending the offer email. The reason why some tours were modified is that since the access token is tracked, changing it will produce a new message in the chatter, the problem with this is that those tours have the assumption that the salary configurator link will be in the first message in the chatter which is no longer true as it is the second message now. Task-ID: 5172914
This update resolves an issue where printers connected as IoT devices were not being correctly loaded within the Point of Sale (PoS) system. This fix ensures that IoT printers are now functional and usable, improving the PoS experience for users. It addresses a previously unusable printer scenario.
Original PR description
preparation printers were not loaded in PoS as IoT devices making them unusable. Forward-Port-Of: odoo/enterprise#115826 Forward-Port-Of: odoo/enterprise#115768
This update eliminates a distracting popup message that appeared when opening the Point of Sale (PoS) module, specifically when reading scale weight data. The fix prevents a frustrating user experience and ensures smoother PoS operations. This resolves a minor usability issue.
Original PR description
This PR removes the unwanted popup "can't reach iot box on local network" before opening PoS when reading scale weight
This update prevents referral-only users from accessing the Reporting tab within the Referrals app. Access to this tab is now restricted to users with recruitment management permissions, streamlining the reporting process for authorized personnel. This change improves data security and usability.
Original PR description
This commit hides the Reporting tab in the Referrals app from users with referral only access rights, and only show it to users with recruitment access. TaskID-6133065
This update significantly speeds up the process of writing data to reconciliation models in the accounting system. By optimizing how the system retrieves and filters bank statement lines, the update reduces processing time and memory usage, particularly for large databases with many unreconciled transactions. This results in a faster and more efficient reconciliation workflow.
Original PR description
When writing on reconcile models, the ORM fetches all the unreconciled bank.statement.lines then calls filtered on `unreconciled_statement_lines.line_ids`. In databases with a lot of unreconciled…
When writing on reconcile models, the ORM fetches all the unreconciled bank.statement.lines then calls filtered on `unreconciled_statement_lines.line_ids`. In databases with a lot of unreconciled statement lines scattered across multiple models, this `filtered` can be heavy, both in memory (fetching all the amls fields) and in time. This commit fixes this by using a search to prefilter the amls using the reconcile models in self. Then we filter the result on `suspense_account_id`. This greatly reduces the number of lines loaded up in memory and speeds up writing on reconcile models. ### speedup In a customer database with 484 042 statement.lines, 141 000 unreconciled statement.lines, 37 account.reconcile.model. Time to write on a reconcile_model. | Nbr linked unreconciled lines| Before PR | After PR | |:----------------------------:|:---------:|:--------:| | 702 | 40s | 3s | | 2000 | 40s | 4.47s | | 10000 | 40s | 11.28s | Since most of the slowness comes from the `filtered` call, the number of unreconciled statement lines linked to the reconcile.model being updated has no impact on the timing before this patch. ### memory For the 702 unreconciled lines case, the memory consumption goes - 2.2 Gb -> 200Mb. Forward-Port-Of: odoo/enterprise#115583
This update restores a previous system for tracking changes made to employee payslips. Now, when a user edits a payslip line, a detailed log is created showing all affected lines. This enhances transparency and simplifies auditing of payroll adjustments.
Original PR description
purpose: We want to reintroduce the same way of logging payslip lines changes as previously done by the removed payslip edit wizard - changed the log in chat to include all affected lines by the user's change task-id: 6144266
This update enhances the accuracy of invoice imports by adding a crucial field – the 'partner' – to the query builder for move lines. This resolves issues with unsynchronized values during import, particularly related to invoices generated using UBL standards. It’s part of a larger effort to improve data consistency.
Original PR description
This commit is part of a bigger commit on the community side- to refactor the import code of BIS3 Invoice to fix various unsynchronized values issues. task-id: 5058687 Forward-Port-Of: odoo/enterprise#115517 Forward-Port-Of: odoo/enterprise#108356
This update fixes a technical issue that previously displayed confusing error messages when generating tax reports. Now, users will receive a helpful message guiding them to set up a certificate if one isn't already configured, preventing tracebacks and improving the user experience. This ensures reports can be successfully submitted to authorities.
Original PR description
Description of the issue this commit addresses: When sending the tax report or ec sales list xbrl file via the wizard to the authority, if no certificate has been set, a traceback shows up. This happens because some processes try to use the certificate without checking its existence. Desired behavior after the commit is merged: When sending via the xbrl wizard, if no certificate has been set up, an error offering the user to go to the certificate set up shows up and no traceback. task-6065382 Forward-Port-Of: odoo/enterprise#115907 Forward-Port-Of: odoo/enterprise#112951
A small typo in the quality module caused newly created quality alert records to be incorrectly grouped as 'None'. This fix replaces the incorrect '&' character with the correct '|' character, ensuring records are properly assigned to their intended stages. This resolves a potential data grouping error.
Original PR description
Issue: ------- While adapting the 'Domain' in the PR https://github.com/odoo/enterprise/commit/07b34a2e927347ca5c839ec632808adb02703e1f there occurred a typo where '|' got replaced with the '&' and causing the records getting grouped in 'None' when creating. Solution: ------------ To replace '&' with '|' to get the records grouped under the correct stage. Steps to reproduce: ----------------------- 1. In v19.0, in quality module try to create a quality alert record. 2. Just like that the newly created record will be under 'None'. Reference Image: <img width="1105" height="407" alt="image" src="https://github.com/user-attachments/assets/4c9c33be-ec06-4f06-8245-54dbe4473bc0" /> OPW - [6074016](https://www.odoo.com/odoo/project/70/tasks/6074016) Forward-Port-Of: odoo/enterprise#113108
This update ensures our accounting system accurately reflects the latest Ecuadorian withholding tax regulations (Resolución N.º NAC-DGERCGC26-00000009) for 2026. The changes involve updating unit tests to align with these new tax percentages, ensuring compliance and accurate reporting.
Original PR description
In accordance with the implementation of the new withholding tax percentages according to "Resolución N.º NAC-DGERCGC26-00000009" for Ecuador, following internal implementation guidelines by TRESCLOUD. Unit tests are updated to be based on the new withholding percentages. BP #110343 Forward-Port-Of: odoo/enterprise#112957 Forward-Port-Of: odoo/enterprise#110712
This update fixes a validation error that occurred when creating correction payslips in Odoo. It ensures that each correction payslip is correctly linked to a structure, allowing for accurate payroll processing. This improves the reliability of the payroll system when adjustments are made.
Original PR description
Ensure `structure_id` is set when creating correction payslips to avoid validation errors. Group payslips by structure before creating pay runs for corrections/reverts, and set the payrun period from the minimum to maximum payslip dates. Fix condition in "Payslip period does not match payrun" to exclude correction payslips (they may span multiple months). task: 6089082 Forward-Port-Of: odoo/enterprise#115405
This update fixes an issue where copying a user also duplicated their assigned tasks, leading to shared task assignments. The change ensures that tasks are uniquely associated with each user, preventing conflicts and simplifying task management. This improves data consistency and reduces potential errors.
Original PR description
Duplicating a user also duplicates all their task assignments because task_ids on res.users is missing copy=False. The new user ends up sharing the same tasks in project_task_user_rel, so removing a task from either user affects both. Forward-Port-Of: odoo/enterprise#114270 Forward-Port-Of: odoo/enterprise#114028
This update resolves an issue preventing the import of Winbooks tax data for Belgian companies. The fix re-enables a temporary workaround that allows the system to correctly handle a specific account type used in Winbooks, ensuring accurate data import. This avoids a previous error message related to receivable account selection.
Original PR description
Steps to reproduce: ------------------- 1. Install account_winbooks_import, and switch to a Belgian company 2. Open Accounting > Configuration > Settings and click "Import", then click "Import WBK"…
Steps to reproduce: ------------------- 1. Install account_winbooks_import, and switch to a Belgian company 2. Open Accounting > Configuration > Settings and click "Import", then click "Import WBK" 3. Upload a Winbooks zip whose chart of accounts uses 411000 typed as asset_current (Winbooks default for "VAT Recoverable") 4. Confirm the import The import fails with: "You must select a receivable account for 'Tax Receivable Account'." Why the issue ------------- In Winbooks, account 411000 is the V01 central account (tax receivable). In Odoo, 411000 comes from l10n_be (account "a411") with type "asset_current", not "asset_receivable". When the import wizard sets it on the existing tax groups via `manage_centralid` in import_wizard.py, the constraint `_constrains_payable_receivable_account` on account.tax.group rejects the write because the account is not "asset_receivable" + "non_trade". This case was already handled in 20804db6d87: we bypassed the constraints on accounts coming from Winbooks, as those are imported in draft anw and the user finishes the configuration after. However later, [2a38e771a826](https://github.com/odoo/odoo/commit/2a38e771a826) and ff5dee81080 removed the initial constraint and the code that bypassed it for account_winbooks_import. Finally, [746a06fab485](https://github.com/odoo/odoo/commit/746a06fab485) added back a similar constraint "_constrains_payable_receivable_account" to fix a NL issue (same account used as both payable and receivable on a tax group). The Winbooks bypass however was not added back, so the original Winbooks issue appeared again. The fix ------- Add back the same bypass originally introduced in 20804db6d87. opw-6092464 Forward-Port-Of: odoo/enterprise#115291
This update adds logging of Amazon's unique request IDs for SP-API responses. Previously, this information wasn't captured, making it harder for support teams to troubleshoot issues with Amazon orders. This enhancement streamlines support investigations and improves order processing efficiency.
Original PR description
Each response from Amazon's SP-API includes a request identifier used by their support team for debugging. This identifier was not previously logged, making support investigations more difficult. Forward-Port-Of: odoo/enterprise#115929 Forward-Port-Of: odoo/enterprise#114483
This update resolves a crash that occurred when users attempted to fetch device information in the HR Attendance module. The issue stemmed from a missing server URL configuration, which has now been addressed by displaying a user-friendly error message prompting them to set the correct URL.
Original PR description
Version: - saas-19.3 Steps to reproduce: - Install the hr_attendance_zkteco module - Go to Settings → Device/Terminal - Click on “Fetch Terminal” Issue: - A traceback error occurs. Cause: - The server URL is not set in settings, so the server value is empty and causes an error. Fix: - Show a user error if the server URL is not configured, asking the user to set it before fetching the terminal. Task-6144254 Forward-Port-Of: odoo/enterprise#114561
This update simplifies the process for Dutch companies to manage their digipoort certificates within the accounting settings. Previously, users had to navigate to a separate section to create a certificate before selecting it. Now, users can directly create and edit digipoort certificates within the main accounting settings, improving the user experience.
Original PR description
Description of the issue this commit addresses: In the Accounting settings on a Dutch company, the setting for the selection of the digipoort certificate only lets you choose amongst existing certificates so if you haven't created one yet, you need to go to the dedicated certificates menu to create one and then come back to the digipoort certificate setting to set it. This is poor UX. --- Desired behavior after this commit is merged: This is improved by letting the user Create and Edit inside the digipoort certificate setting directly. --- task-6065566 Forward-Port-Of: odoo/enterprise#115755 Forward-Port-Of: odoo/enterprise#114307
This update resolves an issue where users were unable to view equity holders associated with companies they didn't have access to. The change adds a company association to equity records, ensuring accurate reporting and access to all relevant shareholder information. This enhances the reliability of our equity management features.
Original PR description
Before this commit, if you had some holders only visible to a company you don't have access to, the cap table would show an access error. This commit introduces multi-company logic to equity models by adding a new company_id field related to the company_id of the partner_id. Other partners (holder, seller, subscriber) will have their companies checked against that company. task-6018771 Forward-Port-Of: odoo/enterprise#110724
This update resolves an issue preventing the system from correctly calculating overtime pay. The fix re-introduced a missing data file and corrected a reference, ensuring that overtime hours are now accurately considered when generating payslips. This improves payroll accuracy and compliance.
Original PR description
Issue: The issue here is that work_entry_type is not associated with the overtime ruleset. That's why when creating a payslip, it is not considering overtime hours. From this PR - https://github.com/odoo/enterprise/pull/98952 the data file is missing from the manifest file. Fix: Added back file to manifest and fixed reference for work_entry_type_id. task-6073921 Forward-Port-Of: odoo/enterprise#115981 Forward-Port-Of: odoo/enterprise#112934
1 change
Resolved issues and error corrections
This update fixes an issue where Odoo's barcode scanning system wouldn't correctly assign a result package when moving a package with existing contents. Previously, only empty packages could be assigned. Now, the system accurately assigns the result package regardless of the package's contents, ensuring seamless internal transfers.
Original PR description
Issue ===== When scanning a package as result package, if the package is empty, it works, but if this package already has content, it doesn't work. How to reproduce ================ 1. Enable…
Issue ===== When scanning a package as result package, if the package is empty, it works, but if this package already has content, it doesn't work. How to reproduce ================ 1. Enable "Packages" and "Storage Locations" settings; 2. Create two packages with some content in WH/Stock/Shelf 1; 3. Create an empty package; 4. Create an internal transfer directly from the Barcode app; 5. Scan Shelf 1 barcode and scan first package; 6. Scan the empty package => It's assigned as the result package; 7. Confirm the operation; 8. Create another internal transfer; 9. Scan Shelf 1 barcode and scan second package; 10. Scan the no more empty package => This time, it's not assigned as the result package. Reason ====== A package was assigned as the result package only if one of the following conditions is matched: 1. The scanned package is empty (it's what's happening in 6.); 2. The selected line has no result package yet and the scanned package is in the selected line's destination location. Here, it doesn't work because since we move a package, the barcode line has already a destination package (the same then the source package.) Fix === For the condition 2., adapt the condition to make it works too if the selected line has the same package as the source and result package. [opw-5326234](https://www.odoo.com/odoo/project/49/tasks/5326234) Forward-Port-Of: odoo/enterprise#102051 Forward-Port-Of: odoo/enterprise#101357
6 changes
Enhancements to existing features
Odoo now supports the new alphanumeric CNPJ format required by the Brazilian government to accommodate a growing number of businesses. This update replaces an outdated validation method, ensuring Odoo can accurately process Brazilian company registrations as they transition to this new format. This change avoids dependency issues with a third-party library.
Original PR description
Purpose: The Brazilian Federal Government, through the Brazilian Federal Revenue Service (Receita Federal do Brasil), is implementing the alphanumeric CNPJ to address the imminent depletion of its…
Purpose: The Brazilian Federal Government, through the Brazilian Federal Revenue Service (Receita Federal do Brasil), is implementing the alphanumeric CNPJ to address the imminent depletion of its capacity to generate new CNPJ numbers. The current, exclusively numeric model is approaching its limit. The transition to a format that includes letters and numbers expands the number of possible combinations, ensuring the future availability of registrations for new companies. With the government expanding the CNPJ numbers, we need to implement a solution to support the alphanumeric CNPJ that will be issued starting July 2026. Current Behavior: The method, `is_valid,` from stdnum is currently used to determine whether the CNPJ is valid or not. This is now considered an outdated method to determine the validation. Changed Behavior: The new validation logic by stdnum, found here https://github.com/arthurdejong/python-stdnum/commit/d3ec3bd7fefe0d0a708b6594a66de28777eb9b8d, is patched into `check_vat_br.` The reasoning for patching this rather than calling stdnum is because using stdnum will cause library dependency issues for older versions of Odoo. task-5234869 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260516
Resolved issues and error corrections
This update resolves an issue where strict XML validators (like those for German XRechnung) were rejecting invoices due to extra whitespace in the generated XML attachments. The fix removes unnecessary whitespace during XML generation, ensuring compatibility with these validators and enabling successful electronic invoicing. This prevents invoice rejection and ensures compliance with German regulations.
Original PR description
### Issue: Some strict validators, such as the German XRechnung validator, reject generated documents because the `EmbeddedDocumentBinaryObject` contains leading and trailing whitespace ### Cause:…
### Issue: Some strict validators, such as the German XRechnung validator, reject generated documents because the `EmbeddedDocumentBinaryObject` contains leading and trailing whitespace ### Cause: Before 18.4, `_postprocess_invoice_ubl_xml()` used f-strings to generate the XML content With this formatting, the result of: `base64.b64encode(attachment_values['raw']).decode()` was indented together with the XML block, introducing unwanted whitespace and line breaks inside `EmbeddedDocumentBinaryObject` ### Steps to reproduce: - Install `l10n_de` and switch to the DE Company - In Settings, enable Peppol and Activate Electronic Invoicing - Create and confirm an Invoice (Customer: DE Company, any product line with tax) - Send the invoice via Peppol - Check the generated XML attachment ### Before the fix: The XML contains formatted content such as: ```xml <cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="INV_2026_00005.pdf"> content </cbc:EmbeddedDocumentBinaryObject> ``` This formatting introduces leading/trailing whitespace and may be rejected by strict validators. ### After the fix: The XML is generated without extra whitespace: ```xml <cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="INV_2026_00005.pdf">content</cbc:EmbeddedDocumentBinaryObject> ``` opw-6121616
This update resolves a problem where community edition tests for invoice payments were failing due to inconsistent payment status after registration (paid or in_payment). The change uses a dynamic function to determine the correct payment state, ensuring tests accurately reflect real-world scenarios and improving test reliability.
Original PR description
Community edition tests fail because payment status after registration can be (`paid` or `in_payment` depending on environment), while the test assumes a fixed value. so instead of hardcoding the state, we use `_get_invoice_in_payment_state` which return required state, depending on environment we are Runbot [link](https://runbot.odoo.com/odoo/error/243480) runbot-error:243480
This update fixes an error in how VAT carryover reimbursements are calculated when generating VAT returns. Previously, incorrect ratios were used, leading to inaccurate reimbursement move amounts. The fix ensures the correct calculation of these amounts, improving financial reporting accuracy.
Original PR description
When generating a VAT return with an unclaimed tax amount carried to the next month, the carryover reimbursement move amounts are computed with an incorrect ratio. Steps to reproduce: - Create and…
When generating a VAT return with an unclaimed tax amount carried to the next month, the carryover reimbursement move amounts are computed with an incorrect ratio. Steps to reproduce: - Create and post a bill in May containing a VAT amount. - Create and post a bill in June containing a VAT amount. - Create a VAT return for May to carry over the VAT amount to the next month. - Create a VAT return for June, requesting the full VAT amount to be reimbursed. - Validate and send the June VAT return. - Check the generated reimbursement move Issue: Line values does not correspond to anything real/tangible. It occurs because when computing the ratio for the move we check the last tax report entry, where we find the amount of tax from the past months and a line balancing the last month that should not be taken into account. The "Balance tax current account (receivable)" line from the tax closing entry is mistakenly picked up as a tax carried forward line, throwing off the amounts. opw-5961836
This update resolves an issue causing incorrect rounding when importing purchase orders processed through OCR. The fix restores the original rounding precision, aligning with the system's intended use for EDI, rather than the OCR process. This ensures accurate financial calculations for purchase orders.
Original PR description
Since commit odoo/odoo@86463ce, there could be rounding issues when importing a purchase order matched through the OCR. A first attempt at fixing this was done in commit odoo/odoo@5dbb814, but it was eventually reverted as deemed too risky for a stable branch. More information about how the rounding error occurred is available in that commit description. This second fix should be much safer, we simply don't disable the rounding precision when the OCR is used, as this was intended for EDI in mind in the first place, not the OCR. opw-[6113387](https://www.odoo.com/odoo/my-support-tasks/6113387)
This update resolves a crash in the website event editor that occurred when the event was set as the homepage. The fix adds a default return value to ensure correct event ID retrieval, preventing the editor from failing to load. This ensures a stable and functional experience for users managing their events.
Original PR description
**Description of the issue/feature this PR addresses:** The `WebsiteEvent._getEventObjectId` method lacks a specific match case for the root directory, causing event ID retrieval to fail on the…
**Description of the issue/feature this PR addresses:** The `WebsiteEvent._getEventObjectId` method lacks a specific match case for the root directory, causing event ID retrieval to fail on the homepage. In order to resolve this, I've implemented a default return of 0 when the URL pattern matching fails [following the pattern established by later revisions of this code](https://github.com/odoo/odoo/blob/2199f71070ce3e9a4717eb6b750c14485406f7aa/addons/website_event/static/src/website_builder/event_page_option_plugin.js#L67). **Steps to reproduce bug:** 1. Create an event website 2. Create an event and visit it 3. On the page click Site > Properties 4. Enable `Is Homepage` 5. Return to the homepage of the application and open the editor https://drive.google.com/file/d/1OpCUAp4LJKqkoStciWeJEGVVlR3qpw1R/view?usp=drive_link **Current behavior before PR:** https://drive.google.com/file/d/1c7ACqaQx03mePzJSV_RoPn8mlLWSMa1I/view?usp=drive_link **Desired behavior after PR is merged:** https://drive.google.com/file/d/1L3Ne9h6-yB3v7VbXipjly9OrDSkZvDOu/view?usp=drive_link opw-6101680
1 change
Resolved issues and error corrections
This update clarifies the purpose of the invoice_mail_template_id field in the subscription module. The help text has been revised to specifically state that it applies only to recurring renewal invoices, reducing potential confusion. This change ensures users understand when and how the email template is utilized.
Original PR description
The existing help text of the invoice_mail_template_id field was unclear andcould lead to confusion about when the email template is used. After discussion with the Product Owner, the help text has been updated to better clarify that it applies only to recurring renewal invoice emails. **opw-5993315**