Daily updates from Odoo
Monday, May 4, 2026
181 changes
17 changes
New functionality added to Odoo
This update introduces a 'tare' function for Toledo scales within the Odoo system. This allows users to reset scale readings to zero, improving the accuracy of inventory tracking for products sold on these scales. This enhancement supports a key feature for businesses utilizing Toledo scales in their operations.
Original PR description
This PR adds the tare mode for Toledo scales. Related PR: https://github.com/odoo/odoo/pull/253328 Forward-Port-Of: odoo/odoo#262256 Forward-Port-Of: odoo/odoo#262027
Resolved issues and error corrections
This update resolves a crash that occurred when users attempted to fetch device information within the HR Attendance module. The issue stemmed from a missing server URL configuration, which prevented the system from properly connecting to the device. Now, users will receive a clear error message prompting them to set the necessary URL before attempting to fetch data.
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
This update adjusts the checksum verification process for the IoT scale certification module. It’s a necessary change to align with recent updates to the underlying IoT drivers, ensuring data integrity and continued functionality of the certified module. This update maintains the security and reliability of the IoT scale certification process.
Original PR description
This PR adapts the expected checksum for the scale certified module corresponding change in iot_drivers module Forward-Port-Of: odoo/enterprise#115825 Forward-Port-Of: odoo/enterprise#115771
This update adds logging of Amazon's request identifiers to the sale module. Previously, support teams struggled to debug issues with Amazon's SP-API, now investigations are simplified and more efficient. This improves overall support response times and reduces troubleshooting complexity.
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 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 work entry types are properly linked to overtime rulesets when generating payslips. This ensures accurate overtime compensation.
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#115720 Forward-Port-Of: odoo/enterprise#112934
This update resolves an issue where the full composer in the chatter didn't load the default email template body. Now, when using a default template, the full composer will correctly display the template's body content, ensuring emails are properly formatted. This improves the user experience and accuracy of email communications.
Original PR description
**Issue:** - When opening the full composer from the chatter, the body of the default email template is not loaded. Only the subject line from the template appears, while the body remains empty or…
**Issue:** - When opening the full composer from the chatter, the body of the default email template is not loaded. Only the subject line from the template appears, while the body remains empty or contains only the user's signature. **Steps to reproduce:** 1. Install `contact` 2. Open any contact form. 3. In the chatter, click 'Send message' and then expand button 4. Write a something in body, then save this as a new template. 5. Set this new template as the default (using Debug Mode > Set Default Values). 6. Click 'Send message' in the chatter, 7. Click the 'Full composer' (expand) button without typing anything. **Observed behavior:** - The full composer opens with the correct subject from the default template, but the body is empty. **Cause:** - The `onClickFullComposer` method always passes a `default_body` value in the context to the mail.compose.message wizard. Even if the chatter input is empty **Solution:** - Forward isBodyEmpty in the context from onClickFullComposer. If the user typed content, do nothing. If the body is empty and a default template is available, allow the backend to apply the default template by removing default_body. opw-5405056 Forward-Port-Of: odoo/odoo#257277 Forward-Port-Of: odoo/odoo#239851
This update significantly speeds up the process of writing bank reconciliation records in Odoo. The change optimizes how the system handles large numbers of statement lines, reducing processing time and memory usage. This results in faster and more efficient reconciliation workflows, especially for businesses with extensive transaction data.
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 resolves a bug where the state of a date field in forms was incorrectly being reset after saving. Typing a date into the field and saving would sometimes result in the field reverting to its previous value. The fix ensures the date field's state is correctly updated after the datepicker is closed, improving data consistency.
Original PR description
Step to reproduce: - Go on view form with a date field - Set the date with the input by typing the date with day and month (mm/dd or dd/mm), then press enter - Save the record - Redo the second step by with a different date - Save the record The assignation of the state.value done when closing the datepicker is useless and can put old a value in the state. The datepicker hasn't finished to update of the record that the assignation put back the old value of the record back in the state. The reason why it happens only after a save is still unknown. task-6095467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258111
This update fixes an issue where the tax return dashboard wouldn't display all tax return groups, showing only the first few. The change adjusts how many groups are automatically expanded, ensuring users can see all their tax return data. This improves the usability of the accounting dashboard for tax reporting.
Original PR description
When navigating to the tax return list view from the accounting dashboard, only the first few groups were expanded, leaving subsequent groups appearing empty with only a date header visible. Steps to reproduce: - Generate several tax returns. - Open the main Accounting dashboard. - On a Tax Return card, click one of the generated buttons. - Scroll down the resulting list view. Issue: After 10 groups, following sections appear empty, showing only the header Analysis: By default, the web client limits the number of automatically opened groups. This change adds 'max_number_opened_groups' to the buttons context, aligning the behavior with the primary 'Tax Return' button action. https://github.com/odoo/enterprise/blob/1a2afda205c41773747ed5f174d75843effbbe9f/account_reports/views/account_return_views.xml#L183 opw-5769978 Forward-Port-Of: odoo/enterprise#114673 Forward-Port-Of: odoo/enterprise#113332
This update corrects a previous issue where invoices rejected by the Italian tax system (SdI) remained marked as 'sent' in the system. Now, when an invoice is rejected, the system automatically clears this status, allowing users to easily resubmit the invoice after resolving the underlying problem. This improves the efficiency of invoice processing for Italian customers.
Original PR description
When an invoice is rejected by the SdI or by a PA partner, the move remained flagged as sent, preventing the user from resending it after fixing the underlying issue. Override write() on account.move to clear is_move_sent whenever l10n_it_edi_state transitions to 'rejected' or 'rejected_by_pa_partner', so the invoice can be re-submitted. task-4490454 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262075 Forward-Port-Of: odoo/odoo#260591
A previous bug prevented custom loyalty program domains (using many2many fields) from functioning properly when accessing the point-of-sale (POS). This fix ensures that loyalty rewards can be correctly applied when using these custom domains, resolving a critical issue that blocked reward usage. The update expands a previous compatibility function to support many2many fields.
Original PR description
When you set many2many fields in a custom loyalty domain, when opening the pos a popup will open saying that the domain must be compatible with the POS.
Steps to reproduce:
-------------------
* Setup a loyalty program, as the reward it should be something like: 10% discount on specific products.
* Set a discount product domain: [("product_tag_ids", "not ilike", "test")]
* Open the pos
> Observation: A popup appears saying that the domain is not compatible with
the pos.
As a result this reward can never be used.
Why the fix:
------------
There's already a function responsible for chnaging `ilike` and `not ilike` with compatible pos operators `in` and `not in`. However this was only applied to `many2one` fields. We extand that.
opw-5990415
Forward-Port-Of: odoo/odoo#258560This update fixes an issue where combo products weren't displayed in the correct order within the Point of Sale system. The change ensures that combo items are consistently ordered according to the choices made when creating the combo, improving the user experience and accuracy of order lines.
Original PR description
When creating a combo product, its items were not ordered according to the combo choice sequence, and extra items were always appended at the end. As a result, combo items could appear in the wrong order. This fix ensures that, when computing combo prices and merging combo items with extra items before creating the order lines, the correct sequence is derived from the parent product. All items are then sorted based on this sequence so that they consistently follow the order defined by the combo choices. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6064642 Forward-Port-Of: odoo/odoo#262102 Forward-Port-Of: odoo/odoo#255596
This update resolves issues where imported BIS3 invoices didn't accurately reflect the total amounts from the original XML files. The changes improve the import process by synchronizing values and using a more robust tax calculation method. A new testing approach, 'Partial Imports,' has been implemented to streamline testing and improve test file readability.
Original PR description
This commit refactors the import code of BIS3 Invoice to fix various issues about unsynchronized values between the imported invoice and the source XML file. The new way we import BIS3 invoice can be…
This commit refactors the import code of BIS3 Invoice to fix various issues about unsynchronized values between the imported invoice and the source XML file. The new way we import BIS3 invoice can be categorized as: - collecting all the values from the XML to a dictionary object - prepare the values and amounts to write to the invoice in its entirety using the tax computation engine helpers - write the whole processed values to the invoice (as a single write) - (in 18.0 ~ 18.2) recalculate discrepancies and update the invoice lines (if needed) with the corrected amounts This commit also includes a new test suite for BIS3 import, and a new approach of import testing, "Partial Imports", is introduced to better atomize the big import test files (and make it understandable). In the long term, `l10n_account_edi_ubl_cii_tests` will eventually be removed in favor of these small-but-many partial tests. task-id: 5058687 Co-authored-by: Yosua Nicolaus <yoni@odoo.com> Forward-Port-Of: odoo/odoo#261052 Forward-Port-Of: odoo/odoo#250160
This update enhances how Odoo matches invoice data by adding a 'partner' domain to the move line query builder. This ensures more accurate synchronization of values, particularly during imports, and resolves issues related to inconsistent data between invoices and accounting records. This change is part of a larger effort to improve invoice import reliability.
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#114893 Forward-Port-Of: odoo/enterprise#108356
This update fixes an issue where applying a global discount and a gift card resulted in incorrect order totals. The fix ensures gift card deductions are properly handled, preventing the system from recomputing discounts and adding back incorrect amounts. This ensures accurate pricing and a better customer experience.
Original PR description
Applying a global order discount and then paying with a gift card (or eWallet) caused the POS to recompute the global discount as if the gift card deduction were part of the taxable merchandise base.…
Applying a global order discount and then paying with a gift card (or eWallet) caused the POS to recompute the global discount as if the gift card deduction were part of the taxable merchandise base. The negative reward line was included in `isGlobalDiscountApplicable()`, so the percentage discount shrank and the order total increased by “global_discount% × gift card amount” (e.g. 10% of $50 → $5 added back). Steps to reproduce: ------------------- * Open PoS with global discount and a gift card / eWallet program. * Add a product (e.g. $100), apply a global discount (e.g. 10%). * Apply a gift card for part of the balance (e.g. $50). > Observation: Total is wrong (e.g. $45 instead of $40): the gift card amount is reduced, then a fraction of that amount is added back via the recomputed global discount line. Why the fix: ------------ `pos_discount` only skips tip and discount-product lines; gift card reward lines use another product and were still “discountable”. The fix belongs in `pos_loyalty`: override `isGlobalDiscountApplicable()` to return false only for gift card and eWallet reward lines (`isGiftCardOrEWalletReward()`), and fall to `super` otherwise so promotion/loyalty reward behavior stay correct. opw-6104090 Forward-Port-Of: odoo/odoo#259577
This update corrects a visual inconsistency in the project timesheet interface. Previously, the 'Time Remaining' value wasn't highlighted in red when negative, even though the label was. The fix ensures that negative time remaining values are displayed with the appropriate red warning indicator, improving clarity for users.
Original PR description
**Steps to reproduce:** - Open project shared form view. - Go to the Timesheets tab. - Observe the Time Remaining value. **Issue:** - The Time Remaining label is red properly but its value does not becomes red even when the value is negative. **Fix:** In hr_timesheet, the remaining_hours field has a decoration-danger applied In sale_timesheet_enterprise, this field is overridden as portal_remaining_hours So, Added the corresponding decoration-danger on portal_remaining_hours. task-5404009 Forward-Port-Of: odoo/enterprise#114836 Forward-Port-Of: odoo/enterprise#113632
This update fixes a visual issue in the project timesheet reporting. Previously, the 'Time Remaining' value wasn't highlighted in red when it was negative. The fix ensures that negative time values are correctly displayed in red, providing clearer reporting for project managers.
Original PR description
**Steps to reproduce:** - Open project shared form view. - Go to the Timesheets tab. - Observe the Time Remaining value. **Issue:** - The Time Remaining label is red properly but its value does not becomes red even when the value is negative. **Fix:** - Adjusted the logic to ensure the Time Remaining value is highlighted in red when value is negative **Task-id: 5404009** Forward-Port-Of: odoo/odoo#260996 Forward-Port-Of: odoo/odoo#240489
11 changes
Enhancements to existing features
This update adds the delivery address to the TicketScreen in Point of Sale. This allows sales staff to quickly view and confirm the correct delivery address while scheduling deliveries, streamlining the order fulfillment process. It’s a small change that improves efficiency and reduces potential errors.
Original PR description
In this commit: =============== - Added address details on the TicketScreen when the order preset identification type is `address`. - This helps to easily see the delivery address while scheduling the delivery. Task-5974595 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257302 Forward-Port-Of: odoo/odoo#251389
Resolved issues and error corrections
This update fixes an issue where applying a global discount and a gift card resulted in an incorrect order total. The system was incorrectly recomputing the discount based on the gift card amount, leading to an inflated total. The fix ensures gift card deductions are handled properly, providing accurate order totals.
Original PR description
Applying a global order discount and then paying with a gift card (or eWallet) caused the POS to recompute the global discount as if the gift card deduction were part of the taxable merchandise base.…
Applying a global order discount and then paying with a gift card (or eWallet) caused the POS to recompute the global discount as if the gift card deduction were part of the taxable merchandise base. The negative reward line was included in `isGlobalDiscountApplicable()`, so the percentage discount shrank and the order total increased by “global_discount% × gift card amount” (e.g. 10% of $50 → $5 added back). Steps to reproduce: ------------------- * Open PoS with global discount and a gift card / eWallet program. * Add a product (e.g. $100), apply a global discount (e.g. 10%). * Apply a gift card for part of the balance (e.g. $50). > Observation: Total is wrong (e.g. $45 instead of $40): the gift card amount is reduced, then a fraction of that amount is added back via the recomputed global discount line. Why the fix: ------------ `pos_discount` only skips tip and discount-product lines; gift card reward lines use another product and were still “discountable”. The fix belongs in `pos_loyalty`: override `isGlobalDiscountApplicable()` to return false only for gift card and eWallet reward lines (`isGiftCardOrEWalletReward()`), and fall to `super` otherwise so promotion/loyalty reward behavior stay correct. opw-6104090 Forward-Port-Of: odoo/odoo#259577
This update corrects a previous issue where all employees could see each other's overtime hours. The root cause was a setting in the system's calculations that granted excessive access. The fix removes this setting and includes new tests to ensure this problem 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#262107 Forward-Port-Of: odoo/odoo#261496
This update resolves an issue where the default email template body wasn't appearing in the full composer view within the chatter. The fix ensures that the correct default template body is loaded, regardless of whether the user manually enters content in the composer, improving email communication reliability.
Original PR description
**Issue:** - When opening the full composer from the chatter, the body of the default email template is not loaded. Only the subject line from the template appears, while the body remains empty or…
**Issue:** - When opening the full composer from the chatter, the body of the default email template is not loaded. Only the subject line from the template appears, while the body remains empty or contains only the user's signature. **Steps to reproduce:** 1. Install `contact` 2. Open any contact form. 3. In the chatter, click 'Send message' and then expand button 4. Write a something in body, then save this as a new template. 5. Set this new template as the default (using Debug Mode > Set Default Values). 6. Click 'Send message' in the chatter, 7. Click the 'Full composer' (expand) button without typing anything. **Observed behavior:** - The full composer opens with the correct subject from the default template, but the body is empty. **Cause:** - The `onClickFullComposer` method always passes a `default_body` value in the context to the mail.compose.message wizard. Even if the chatter input is empty **Solution:** - Forward isBodyEmpty in the context from onClickFullComposer. If the user typed content, do nothing. If the body is empty and a default template is available, allow the backend to apply the default template by removing default_body. opw-5405056 Forward-Port-Of: odoo/odoo#257277 Forward-Port-Of: odoo/odoo#239851
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 smoother and faster user experience.
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 fixes an issue where the tax return dashboard wouldn't display all tax return groups, showing only the first few. The change ensures that all tax return groups are expanded automatically, providing a complete view of tax return data. This improves usability for users generating and reviewing tax returns.
Original PR description
When navigating to the tax return list view from the accounting dashboard, only the first few groups were expanded, leaving subsequent groups appearing empty with only a date header visible. Steps to reproduce: - Generate several tax returns. - Open the main Accounting dashboard. - On a Tax Return card, click one of the generated buttons. - Scroll down the resulting list view. Issue: After 10 groups, following sections appear empty, showing only the header Analysis: By default, the web client limits the number of automatically opened groups. This change adds 'max_number_opened_groups' to the buttons context, aligning the behavior with the primary 'Tax Return' button action. https://github.com/odoo/enterprise/blob/1a2afda205c41773747ed5f174d75843effbbe9f/account_reports/views/account_return_views.xml#L183 opw-5769978 Forward-Port-Of: odoo/enterprise#114673 Forward-Port-Of: odoo/enterprise#113332
This update resolves a technical issue preventing the departure form from loading correctly when accessed through the payslip. The fix ensures the correct form view is used, eliminating a problem caused by incorrect context information. This improves the reliability of the payslip process.
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
This update fixes an issue where discounts on purchase orders weren't being correctly reflected in the final accounting. The fix ensures that the total tax-excluding amount, including the discount, is accurately displayed when creating accrued expense entries. This improves the reliability of purchase order accounting.
Original PR description
Steps to reproduce: [purchase] - Create a purchase order - add a line with a discount - confirm and receive - create an accrued expense entry Issue: The full tax excl amount is displayed but no discount is applied opw-5049848 Forward-Port-Of: odoo/odoo#240887 Forward-Port-Of: odoo/odoo#225375
This update corrects a bug where invoices rejected by the Italian tax system (SdI) were incorrectly marked as 'sent,' preventing users from resubmitting them. The change automatically clears the 'is_move_sent' flag when an invoice is rejected, allowing for proper resubmission and streamlining the invoice processing workflow. This ensures Italian businesses can quickly resolve issues and avoid delays.
Original PR description
When an invoice is rejected by the SdI or by a PA partner, the move remained flagged as sent, preventing the user from resending it after fixing the underlying issue. Override write() on account.move to clear is_move_sent whenever l10n_it_edi_state transitions to 'rejected' or 'rejected_by_pa_partner', so the invoice can be re-submitted. task-4490454 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262075 Forward-Port-Of: odoo/odoo#260591
A bug was preventing custom loyalty program domains (using many2many fields) from functioning properly when accessing the point-of-sale (POS). This fix expands a previous change to support many2many fields, ensuring loyalty rewards can be applied correctly through the POS interface. This resolves a critical issue preventing users from utilizing custom loyalty programs.
Original PR description
When you set many2many fields in a custom loyalty domain, when opening the pos a popup will open saying that the domain must be compatible with the POS.
Steps to reproduce:
-------------------
* Setup a loyalty program, as the reward it should be something like: 10% discount on specific products.
* Set a discount product domain: [("product_tag_ids", "not ilike", "test")]
* Open the pos
> Observation: A popup appears saying that the domain is not compatible with
the pos.
As a result this reward can never be used.
Why the fix:
------------
There's already a function responsible for chnaging `ilike` and `not ilike` with compatible pos operators `in` and `not in`. However this was only applied to `many2one` fields. We extand that.
opw-5990415
Forward-Port-Of: odoo/odoo#258560This update fixes an issue where the 'Back to edit mode' link in the land portal invoice was incorrectly directing users to the wrong Odoo app. By switching to the correct action, the webclient now consistently directs users to the Invoicing app, ensuring accurate invoice management.
Original PR description
The "Back to edit mode" link used action_move_out_invoice_type, which isn't bound to any menu, so the backend fell back to whichever app happened to match (e.g. Website when installed) instead of Invoicing. Switch to action_move_out_invoice (the one referenced by the Invoicing menu) so the webclient resolves the correct app automatically. task-5882256 Forward-Port-Of: odoo/odoo#257841
16 changes
Enhancements to existing features
This update automatically sets the first available printer as the default for Point of Sale transactions. This simplifies the setup process for users and ensures that receipts are always printed without requiring manual selection. Additionally, quick creation of printer settings has been restricted to improve data consistency.
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
Resolved issues and error corrections
This update corrects a visual issue where positive time remaining values in task timesheets were incorrectly displayed in red, misleading users. The fix ensures that positive values are shown with the correct styling, and also addresses misalignment of time remaining data on sales orders. This improves the clarity and accuracy of timesheet reporting.
Original PR description
_* = sale_timesheet **Steps to reproduce:** - Open form view of any task. - Go to the Timesheets tab. - Observe the Time Remaining value. - Observe the Time remaining on SO. **Issue:** - The Time Remaining value becomes red even when the value is positive, which incorrectly suggests a warning. - The Time remaining on SO is not properly aligned. **Issue from :** - https://github.com/odoo/odoo/pull/192366 **Fix:** - Adjusted the logic to ensure the Time Remaining value is highlighted in red only when the value is negative. - Positive values now display with normal styling. - Adjusted the logic to ensure Time remaining on SO is displayed properly. **Task-id: 5404009**
This update adds logging of Amazon's request identifiers to the SP-API responses. Previously, this information was missing, making it harder for support teams to troubleshoot issues with Amazon. Logging this ID will significantly improve the speed and efficiency of support investigations.
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 automatically allows users to reconcile bank statements from a parent company with related payments and invoices from its branches. Previously, reconciliation was limited to matching statements directly with company records. This enhancement streamlines the bank reconciliation process, making it easier to manage financial data across multiple locations.
Original PR description
The aim of this commit is allowing in the automatic reconciliation of bank reconciliation widget the possibility to reconcile statement lines from a parent company with moves (payments and invoices) from a branch. To do that, we are not only checking that the company between the AML and the statement line is the same, we are checking that there is a parent relation between the company of the AML and the statement line. opw-6056320 Forward-Port-Of: odoo/enterprise#114850
This update fixes a visual issue in the Timesheets section of the project shared form. Previously, the Time Remaining value wasn't highlighted in red when the amount was negative. This change ensures that negative time values are clearly indicated, improving accuracy and clarity for users.
Original PR description
**Steps to reproduce:** - Open project shared form view. - Go to the Timesheets tab. - Observe the Time Remaining value. **Issue:** - The Time Remaining label is red properly but its value does not becomes red even when the value is negative. **Fix:** - Adjusted the logic to ensure the Time Remaining value is highlighted in red when value is negative **Task-id: 5404009** Forward-Port-Of: odoo/odoo#240489
This update corrects a visual inconsistency in the project timesheet interface. Previously, the 'Time Remaining' value wasn't highlighted in red when negative, even though the label was. The fix ensures that negative time remaining values are correctly displayed with a red color, improving clarity and accuracy for users.
Original PR description
**Steps to reproduce:** - Open project shared form view. - Go to the Timesheets tab. - Observe the Time Remaining value. **Issue:** - The Time Remaining label is red properly but its value does not becomes red even when the value is negative. **Fix:** In hr_timesheet, the remaining_hours field has a decoration-danger applied In sale_timesheet_enterprise, this field is overridden as portal_remaining_hours So, Added the corresponding decoration-danger on portal_remaining_hours. task-5404009 Forward-Port-Of: odoo/enterprise#113632
This update resolves an issue where the full composer in the chatter didn't display the default email template's body. The fix ensures that the correct template body is loaded automatically, regardless of whether the user manually enters content in the composer. This improves the consistency and usability of email sending within Odoo.
Original PR description
**Issue:** - When opening the full composer from the chatter, the body of the default email template is not loaded. Only the subject line from the template appears, while the body remains empty or…
**Issue:** - When opening the full composer from the chatter, the body of the default email template is not loaded. Only the subject line from the template appears, while the body remains empty or contains only the user's signature. **Steps to reproduce:** 1. Install `contact` 2. Open any contact form. 3. In the chatter, click 'Send message' and then expand button 4. Write a something in body, then save this as a new template. 5. Set this new template as the default (using Debug Mode > Set Default Values). 6. Click 'Send message' in the chatter, 7. Click the 'Full composer' (expand) button without typing anything. **Observed behavior:** - The full composer opens with the correct subject from the default template, but the body is empty. **Cause:** - The `onClickFullComposer` method always passes a `default_body` value in the context to the mail.compose.message wizard. Even if the chatter input is empty **Solution:** - Forward isBodyEmpty in the context from onClickFullComposer. If the user typed content, do nothing. If the body is empty and a default template is available, allow the backend to apply the default template by removing default_body. opw-5405056 Forward-Port-Of: odoo/odoo#257277 Forward-Port-Of: odoo/odoo#239851
This update speeds up the process of writing to reconciliation models, a key task for managing financial records. By optimizing how the system handles large numbers of bank statement lines, the change significantly reduces processing time and memory usage, leading to a smoother and faster user experience.
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 resolves an issue where the tax return dashboard wouldn't expand all groups, leaving some sections empty. The fix adds a setting to ensure all groups are initially displayed, providing a more complete and user-friendly experience when reviewing tax returns. This improves usability for users generating and analyzing tax returns.
Original PR description
When navigating to the tax return list view from the accounting dashboard, only the first few groups were expanded, leaving subsequent groups appearing empty with only a date header visible. Steps to reproduce: - Generate several tax returns. - Open the main Accounting dashboard. - On a Tax Return card, click one of the generated buttons. - Scroll down the resulting list view. Issue: After 10 groups, following sections appear empty, showing only the header Analysis: By default, the web client limits the number of automatically opened groups. This change adds 'max_number_opened_groups' to the buttons context, aligning the behavior with the primary 'Tax Return' button action. https://github.com/odoo/enterprise/blob/1a2afda205c41773747ed5f174d75843effbbe9f/account_reports/views/account_return_views.xml#L183 opw-5769978 Forward-Port-Of: odoo/enterprise#114673 Forward-Port-Of: odoo/enterprise#113332
This update corrects an issue where the EC Sales Report exported to KVR (a key reporting tool) displayed values with decimal places, which is not permitted for Swedish reporting requirements. The fix ensures all values are rounded to integers, aligning with local regulations and improving data accuracy for financial reporting. This resolves a previous reporting discrepancy.
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#115459 Forward-Port-Of: odoo/enterprise#114292
This update corrects a bug where invoices rejected by the Italian tax system (SdI) were incorrectly marked as 'sent,' preventing users from resubmitting them. The change automatically clears the 'is_move_sent' flag when an invoice is rejected, allowing invoices to be properly resubmitted after the issue is resolved. This improves the efficiency of invoice processing for Italian businesses.
Original PR description
When an invoice is rejected by the SdI or by a PA partner, the move remained flagged as sent, preventing the user from resending it after fixing the underlying issue. Override write() on account.move to clear is_move_sent whenever l10n_it_edi_state transitions to 'rejected' or 'rejected_by_pa_partner', so the invoice can be re-submitted. task-4490454 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262075 Forward-Port-Of: odoo/odoo#260591
A previous issue prevented custom loyalty domains from functioning properly when using the Point of Sale (POS). This fix expands a system function to correctly handle many2many fields in loyalty domains, resolving a bug that blocked reward usage. This ensures loyalty programs are fully operational within the POS environment.
Original PR description
When you set many2many fields in a custom loyalty domain, when opening the pos a popup will open saying that the domain must be compatible with the POS.
Steps to reproduce:
-------------------
* Setup a loyalty program, as the reward it should be something like: 10% discount on specific products.
* Set a discount product domain: [("product_tag_ids", "not ilike", "test")]
* Open the pos
> Observation: A popup appears saying that the domain is not compatible with
the pos.
As a result this reward can never be used.
Why the fix:
------------
There's already a function responsible for chnaging `ilike` and `not ilike` with compatible pos operators `in` and `not in`. However this was only applied to `many2one` fields. We extand that.
opw-5990415
Forward-Port-Of: odoo/odoo#258560This update resolves an issue preventing correct December pay calculations within the Belgian payroll module. The migration to a new data structure caused a missing link in how pay information was recorded, leading to incorrect calculations. This fix ensures accurate December pay processing.
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
This update resolves an issue causing excessive logging within the Documents module, specifically when handling attachments. The change prevents unnecessary error handling and log spam related to URL type attachments, primarily impacting integrations and workflows that create attachments directly. This improves system stability and reduces unnecessary log volume.
Original PR description
Return None when datas is empty alongside the existing mimetype check. Avoids unnecessary exception handling leading to logspam for URL type attachments where binary data is unavailable. This issue is only reproducible programmaticaly as the mimetype is not available with url type attachment in Odoo. Thus, it's a problem that only impact third party integrations, EDI connectors or any workflow that creates ir.attachment records directly. opw-6010528 Forward-Port-Of: odoo/enterprise#113396
This update fixes an issue where invoices created in a branch environment with tax-included products didn't correctly calculate the unit price after applying a fiscal position. Previously, the price remained unchanged. This change ensures accurate tax calculations on branch invoices, improving financial reporting and compliance.
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 prevents image uploads from failing due to excessively long filenames. The system now truncates filenames to a safe length (255 characters) to avoid exceeding server buffer limits, ensuring images load correctly. This resolves a previous issue where long descriptions caused 502 errors during image uploads.
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
2 changes
Resolved issues and error corrections
A bug in the MRP component consumption test was preventing it from running correctly on the community version of Odoo. This fix removed a dependency on an enterprise-only module, allowing the test to pass reliably in all Odoo environments. This ensures consistent test results and improved quality assurance.
Original PR description
The test `test_multi_lot_component_consumption` relies on `move_raw_line_ids`, which is initialized by the `stock_barcode_mrp` module. This module is only available in enterprise, causing the test to fail in community setups. https://github.com/odoo/odoo/blob/0ce5baf2918960591284eb494d82dfef07043af0/addons/mrp/tests/test_consume_component.py#L494 runbot-242612 Forward-Port-Of: odoo/odoo#261816
This update resolves an issue where referenced refunds in Viva.com were incorrectly reversing payments. A recent update mistakenly removed a key data field, causing this problem. This fix restores the necessary data, ensuring refunds work as intended and preventing payment reversals.
Original PR description
Referenced refunds in Viva.com require the session ID of the original payment to be sent, resulting in that payment being reversed. Unfortunately this functionality was broken when a forward-port PR (odoo/odoo#236004) mistakenly removed the `parentSessionId` field from the request. This commit restores the `parentSessionId` field, fixing the issue. It also adds a tour to test the full payment and referenced refund flow. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
8 changes
Enhancements to existing features
This update implements a crucial gross up calculation for Indonesian payroll, ensuring accurate reporting and compliance. It also includes adjustments to insurance rules and a fix for a parameter related to Japanese payroll, enhancing the overall functionality of the HR payroll module. This change supports Indonesian business operations.
Original PR description
- Add the gross up calculation for indonesia payroll - Move insurance rule to new category BIK - Fix starting month of JP rule parameter task-[5033626](https://www.odoo.com/web#model=project.task&id=5033626)
Resolved issues and error corrections
This update simplifies the management of simulation employee offers within Odoo Enterprise by removing a redundant field. The change consolidates data and ensures simulation offers are automatically deactivated after one month, improving data cleanliness and reducing potential confusion. This improves the overall efficiency of the HR contract management process.
Original PR description
- Replaced the `simulation_employee_id` field with the `employee_id` field from
regular offer to reduce code duplication.
- The `simulation_employee_id` field was redundant as it served the same purpose
as `employee_id` but only for simulation offers.
- The filtering now uses `is_simulation_offer` instead of checking field.
- The original domain [('contract_date_start', '!=', False)] is preserved
in the simulation view.
- To prevent simulation offers from appearing in employee offer lists,
they are now marked as `active=false` on creation. As it will be get cleanup
after one month by cron.
task-[5993083](https://www.odoo.com/odoo/project/1251/tasks/5993083)This update resolves an issue where transcription summaries were incorrectly sent to multiple chatter channels. The fix ensures summaries are now only posted to the relevant current chatter, and also corrects a previous error that occurred when closing the composer window. This improves the user experience and prevents redundant notifications.
Original PR description
Before this commit, there was an issue where the message of the transcription summary would get posted to the chatters of all records of a given model. With this commit, the message is only posted on the current chatter. This commit also fixes a regression where closing the composer window would cause an exception to occur. task-6147951 Forward-Port-Of: odoo/enterprise#115829
This update adjusts the checksum calculation for the IoT scale certified module, aligning it with recent changes in the related iot_drivers module. This ensures data integrity and stability for users relying on this certified module, preventing potential issues with data processing.
Original PR description
This PR adapts the expected checksum for the scale certified module corresponding change in iot_drivers module Forward-Port-Of: odoo/enterprise#115825 Forward-Port-Of: odoo/enterprise#115771
This update resolves an issue preventing mobile users from uploading documents to shared folders within the Odoo portal. The fix adjusts how the mobile file picker interacts with the portal interface, ensuring the file upload process functions correctly. This improves the user experience for mobile portal users.
Original PR description
Steps to reproduce: 1. Install `documents` 2. Create a portal user and share a document folder with edit access 3. Log in as the portal user on a mobile device 4. Try to upload a document inside the…
Steps to reproduce:
1. Install `documents`
2. Create a portal user and share a document folder with edit access
3. Log in as the portal user on a mobile device
4. Try to upload a document inside the shared folder
Issue:
- After selecting a file from the file picker, the document is not uploaded.
Cause:
- On mobile in the portal flow, Upload is triggered from a nested dropdown (inside New) inside the adaptive control-panel dropdown (bottom sheet). By default, DropdownItem uses closingMode="all", so tapping Upload closes parent dropdowns immediately. That unmounts the hidden <input type="file"> before the OS file picker returns. When the user comes back, the input no longer exists, so change never fires and upload does not start.
- Admin/internal users do not hit the same nested adaptive-dropdown path in this view
Solution:
- Set closingMode="'none'" on the Upload DropdownItem so the menu stays mounted while the native picker is open. After a file is selected and onFileInputChange starts upload, close the bottom sheet programmatically with: `window.dispatchEvent(new Event("popstate"))`
opw-5937105
Forward-Port-Of: odoo/enterprise#108486This update ensures that changes to employee contract dates don't inadvertently exclude previously paid payslips. The system now validates that new contract start and end dates align with existing payslip dates, preventing data inconsistencies and ensuring accurate payroll reporting. This protects against potential errors and compliance issues.
Original PR description
Prevent changing a contract's contract_date_start or contract_date_end in a way that would exclude already validated/paid payslips for that version and there is not a departure set. It raises a ValidationError if: - the new contract_date_start is after the earliest payslip date_from - the new contract_date_end is before the latest payslip date_to. task-6088963
This update resolves an issue where the tax return dashboard wouldn't expand all tax return groups, leaving some sections empty. The fix ensures that all generated tax returns are displayed correctly within the list view, providing a complete overview for users. This improves the usability of the accounting reporting feature.
Original PR description
When navigating to the tax return list view from the accounting dashboard, only the first few groups were expanded, leaving subsequent groups appearing empty with only a date header visible. Steps to reproduce: - Generate several tax returns. - Open the main Accounting dashboard. - On a Tax Return card, click one of the generated buttons. - Scroll down the resulting list view. Issue: After 10 groups, following sections appear empty, showing only the header Analysis: By default, the web client limits the number of automatically opened groups. This change adds 'max_number_opened_groups' to the buttons context, aligning the behavior with the primary 'Tax Return' button action. https://github.com/odoo/enterprise/blob/1a2afda205c41773747ed5f174d75843effbbe9f/account_reports/views/account_return_views.xml#L183 opw-5769978 Forward-Port-Of: odoo/enterprise#114673 Forward-Port-Of: odoo/enterprise#113332
Features or functions removed from Odoo
This change removes a previously implemented feature that checked spreadsheet compression. This verification was introduced to aid debugging but has not been needed since its addition, streamlining the process and reducing unnecessary overhead.
Original PR description
Compression verification was introduced to check that the compression of the spreadsheet data was correctly done, and to help debugging issues related to it. We can now remove it as we haven't had any issue related to compression since its introduction. Task: 6179135
19 changes
Enhancements to existing features
This update improves the accuracy of the Brazil demo data within the Odoo Enterprise system. The changes ensure that testing of the l10n_br_avatax module reflects current Brazilian tax regulations and business practices. This enhances the reliability of testing and demonstration for potential users.
Original PR description
Updated Brazil Product and company demo data to ensure accurate testing task-6159933
Resolved issues and error corrections
This update resolves an issue where Amazon-related stock moves incorrectly displayed 'False' as their reference. The change updates the system to use the 'reference' field instead of 'name', ensuring accurate tracking of these moves within the Amazon integration. This prevents data discrepancies and improves the reliability of order fulfillment.
Original PR description
Issue ----- Commit d0c1e78 removed the `name` field of `stock.move`. Instead, we now use the `reference`field, which is computed in `_compute_reference` https://github.com/odoo/odoo/blob/2ec714b19e2c56bff965ab32f7e6a4485df2d247/addons/stock/models/stock_move.py#L357-L369 The problem is that there is no picking linked to the move, so `move.reference` is set to `False`. This means that, after we go through the override in `sale_amazon`, we end up with `Amazon move: False` https://github.com/odoo/enterprise/blob/596d8c1216b33c1f73feb8f60eef1b69a2164579/sale_amazon/models/stock_move.py#L10-L14 ----- Ticket: opw-5969357
This update resolves an issue where incorrect pivot IDs were used in purchase and vendor dashboards. The fix ensures accurate data representation within these reports, improving the reliability of key business insights related to purchasing and vendor management. This change enhances the accuracy of the dashboard data.
Original PR description
This commits fixes the pivot id in some formulas. Task: 5875749
This update adjusts the default date range for the Lead and Pipeline dashboards to 'Last 30 days'. This change ensures users consistently see the most recent data, providing a clearer and more accurate view of sales performance. It's a minor improvement to dashboard usability.
Original PR description
This commmit fixes the date filter default value to `Last 30 days`. Task: 5902231
This update resolves a bug in the Spanish BOE (mod347) export that incorrectly included certain invoices. Previously, invoices under €3,005.06 were causing the BOE to display incorrect partner information. This fix ensures that the BOE accurately reflects cash payments related to invoices, improving data accuracy for tax reporting.
Original PR description
Fix a bug in mod347 BOE export. Steps to reproduce: 1- Create an invoice with a spain Company, with an amount lower than 3 005,06€ 2- Add a Type for mod347 3- Create a cash payment 4- Export the mod347 BOE The partner will appear in the BOE with all line at 0. But this partner shouldn't be in the export. This is due because of a search on account.partial.reconcile, which add partners to the export if a cash payment is found in the period. But this search is not usefully as there is no legal indication that these partners should be in the export in this case, as the partners should only be returned by the main queries. Backport of PR #84317 opw-5960226 Forward-Port-Of: odoo/enterprise#114672 Forward-Port-Of: odoo/enterprise#110947
This update fixes an issue where helpdesk notification emails incorrectly linked to the company's default website instead of the customer's original website. Now, 'View Ticket' buttons in helpdesk emails always direct users to the website where their ticket was created, improving the user experience across multi-website setups. This ensures consistent and accurate ticket navigation.
Original PR description
On a multi-website / single-company setup, helpdesk notification emails posted after the initial confirmation contained a "View Ticket" button pointing to the wrong website, always the company's…
On a multi-website / single-company setup, helpdesk notification emails posted after the initial confirmation contained a "View Ticket" button pointing to the wrong website, always the company's default website instead of the website the ticket was created from. Steps to reproduce: =================== 1. Create two websites W1 (seq 1) and W2 (seq 2) under the same company, with distinct domains. 2. Create two helpdesk teams with "Submit a Ticket" enabled, each bound to one website (Helpdesk1 -> W1, Helpdesk2 -> W2). 3. From W2, submit a ticket on /helpdesk/helpdesk2. 4. In the ticket, send email from the chatter. 5. Inspect the outgoing notification email. => "View Ticket" button points to W1's domain. Root cause: ============ `helpdesk.ticket` has no `website_id`, so `Base.get_base_url` falls through to `company_id.website_id.domain`, i.e. the first website of the company by sequence. The first confirmation message looked right only because it was posted inside a website request, where `website.get_current_website()` provided the correct context; subsequent agent replies are posted from the ticket with no such context, so the fallback kicked in. Override `get_base_url` on `helpdesk.ticket` to prefer `team_id.website_id.domain` when set, so every notification on the ticket links back to the website the customer submitted it from. => "View Ticket" button points to W2's domain (the site the customer is browsing). opw-6071999
This update adds logging of Amazon's SP-API request identifiers to help support teams quickly troubleshoot issues with Amazon integrations. Previously, missing this information slowed down investigations and increased resolution times. This change enhances the efficiency of support for our Amazon-related features.
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
A technical error prevented importing emissions data through the system's import feature. This update restricts imports to manual emissions data, resolving a database conflict issue related to journal entry emissions. This ensures data integrity and proper reporting within the ESG carbon emission reports.
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#115306
This update ensures that barcode validations during stock receipt creation correctly check if a destination has been scanned, even if a destination wasn't explicitly selected. Previously, the system didn't verify this, leading to potential issues. This change enhances the reliability of the barcode scanning process for stock management.
Original PR description
### Steps to reproduce: - In the settings: Enable "Storage Locations" - Inventory > Configuration > Warehouse Management > Operation Types - On receipts, in the Barcode App tab enable: "Force a…
### Steps to reproduce: - In the settings: Enable "Storage Locations" - Inventory > Configuration > Warehouse Management > Operation Types - On receipts, in the Barcode App tab enable: "Force a destination on all products" - Open the barcode app, create a new receipt - Scan a product > Validate #### > You are not blocked by the fact that you did not scan any destination even just to validate the default one ### Cause of the issue: The `barcode_validation_after_dest_location` operation type setting is not used at any point in the barcode app. ### Note: Line in the barcode app are always created a with a `location_dest_id`: https://github.com/odoo/enterprise/blob/a220fc61d9076decdb987421df9330a1c2c20546/stock_barcode/static/src/models/barcode_picking_model.js#L1310-L1322 In particular, even if the setting says: Force a destination on all products. It should rather be interpreted as force a destination scan before validation. Note that a destination scan will not necessarily update a single line but rather all concerned lines at once: https://github.com/odoo/enterprise/blob/a220fc61d9076decdb987421df9330a1c2c20546/stock_barcode/static/src/models/barcode_picking_model.js#L1558-L1576 It is therefore a valid call to check if a location dest was scanned to determine if the a destination was set on each product before validation of the picking, even if it is just to confirm the default destination. ### Note 2: We modify the `_get_barcode_config` to only provide a `barcode_validation_after_dest_location` if locations re enabled otherwise users enabling the option without the ability to scan locations would be soft lock and unable to validate their picking. That same logic already being applied to the `restrict_scan_dest_location` config parameter: https://github.com/odoo/enterprise/blob/6afe02e3e836df2822d7cae8aebbd5bdde6b34cc/stock_barcode/models/stock_picking_type.py#L109 opw-6110690 Forward-Port-Of: odoo/enterprise#115534 Forward-Port-Of: odoo/enterprise#114429
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 setting it. Now, users can directly create and edit certificates within the digipoort setting, improving usability and efficiency.
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#115628 Forward-Port-Of: odoo/enterprise#114307
This update fixes an issue where OCR software misinterpreting invoice data, specifically when 'Single Invoice Line Per Tax' was enabled. The change now uses account and tax information for labeling, resulting in more accurate data extraction and reducing errors in invoice processing. This improves the reliability of our invoicing system.
Original PR description
Previously, when a user enabled 'Single Invoice Line Per Tax', the tax group contained the partner name and date. However, the OCR would sometimes misclassify the partner name, resulting in random text appearing in the label. To fix this, we decided to use the account name and tax as the label instead. task-6159843
This update resolves an issue where the 'data_cleaning' module incorrectly removed the delete option from the attachment list view after installation. The change prevents the module from overriding the default view order, restoring the original functionality. This ensures users can always delete attachments as expected.
Original PR description
Steps: - Enable debug mode - Go to Attachments view (list) - Select several items - Actions -> You have delete - Install `data_cleaning` - Do the same - Actions -> You don't have delete anymore Context: - `IrUiView` has 16 by default for `priority` field and order set as `priority,name,id`. - `IrAttachment` has a default view with no name, so `ir.attachment` is taken by default. - `data_cleaning` creates a view named `Storage Detail` with no priority specified (so 16 by default) on model `ir.attachment`. That makes the `ir.attachment` view from `data_cleaning` before the original one if we use the order "priority,name,id", as both of them have 16 in priority and `Storage Detail` is before `ir.attachment`. This commit restore the previous behaviour by preventing `data_cleaning` from overriding original `ir.attacmhent` view. opw-6149907
This update corrects a technical issue where translations for the Netherlands returns module (l10n_nl_returns) were missing in the system's translation files. Adding these translations ensures accurate and localized functionality for our Dutch-speaking customers. This resolves a potential problem with incorrect display or functionality related to returns processing.
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.
This update resolves an issue where users wouldn't be able to view equity information for partners associated with inaccessible companies. 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 company access. This ensures accurate reporting and a smoother user experience.
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
This update prevents unauthorized users from viewing or modifying assets linked to invoices. Previously, users on lower-level access groups could access invoices with assets, leading to potential data access issues. Now, access is restricted to users within the ‘account.group_account_readonly’ or ‘account.group_account_invoice’ groups, enhancing security and data integrity.
Original PR description
Only groups `account.group_account_readonly`, `account.group_account_invoice` or higher have access to model `account.asset`, therefore if an user goes to see an invoice with assets and they are not on either group, they will receive an error and won't be able to access said invoice. How to reproduce: - Create a vendor bill - Create an account.asset and link it to said account.move - Go to the form view with an user that it's on group "Purchase: User" for example --> They get a traceback --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#113858 Forward-Port-Of: odoo/enterprise#112890
This update fixes an issue where Shopee account authorization was failing when a shop already existed. Now, the system correctly reuses authorization tokens to fetch access tokens for multiple shops associated with an account, streamlining the onboarding process for Shopee users. This ensures a smoother and more reliable experience when connecting multiple shops through a single Shopee account.
Original PR description
When authorizing a Shopee shop, a user has the choice to either connect to a Shopee Shop, or connect to a Shopee Account and grant access to multiple shops of the account. In the later scenario, the authorization code returned by Shopee OAuth should be used once to fetch the access tokens, and the tokens should be copied to all shops authorized by the account. However, when the shop already existed, the access token was fetched again, raising an error because the authorization code had already been used. opw-6166585
This update resolves a crash that occurred when sending invoices with attachments created via log notes. The fix prevents the system from incorrectly syncing orphaned attachment files, which caused versioning conflicts and data loss during the printing process. This ensures invoices print reliably and avoids data corruption.
Original PR description
Steps to reproduce: - Set a journal with documents folder sync. - Create and post a customer invoice. - Add an image attachment via a log note. - Click Send & Print. -> KeyError:…
Steps to reproduce: - Set a journal with documents folder sync. - Create and post a customer invoice. - Add an image attachment via a log note. - Click Send & Print. -> KeyError: `proforma_pdf_attachment` Cause: Adding an image via log note sets it as the main attachment, but it is intentionally orphaned (res_model=False) to prevent UI clutter. `documents_account` incorrectly syncs this unlinked file, creating a workspace document with a missing model. During "Send & Print", the official invoice PDF replaces the image as the main attachment. The document versioning logic intercepts this swap and attempts to re-parent the new PDF to match the orphaned document. This destroys the PDF's linkage to the invoice, causing a crash when the system later attempts to fetch the PDF. Solution: Since the base module now suppresses premature document creation during the message post, we explicitly handle the sync ourselves. We override `_fix_attachments_on_record_from_files_data` to iterate over the validated attachments and trigger document creation only for files that retained their `res_model`. We also add a check inside `_update_or_create_document` to strictly block orphaned attachments. opw-5930888 Forward-Port-Of: odoo/enterprise#115065
This update optimizes appointment scheduling by calculating availability only for the currently displayed month, rather than pre-computing all slots. This change significantly reduces server load and improves the responsiveness of the appointment booking process, leading to a smoother user experience. It addresses a performance bottleneck related to handling extended booking periods.
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
This update resolves a rejection issue with payroll exports to the Mexican SAT (tax authority). When payslips only include 'OtrosPagos', the SAT incorrectly flagged the data due to a requirement in the NOM36 XML format. The fix ensures the 'TotalPercepciones' attribute is omitted when this scenario occurs, aligning with tax regulations.
Original PR description
When a payslip contains only OtrosPagos (no perceptions), the SAT rejects with NOM36 because TotalPercepciones must not exist per the nomina12 XSD. This is a valid scenario under LISR articles 93 and 94, where certain payments (e.g., viáticos, becas, fondo de ahorro patronal) do not constitute taxable salary income. Apply the same 'or None' pattern already used for TotalDeducciones, so format_float(None) returns None and the attribute is omitted from the XML.
4 changes
Resolved issues and error corrections
This update resolves an issue where discounts weren't being imported accurately due to rounding discrepancies. The fix skips rounding during the import process, ensuring the subtotal matches the original invoice file. This prevents discrepancies between Odoo's calculations and the imported data.
Original PR description
**PROBLEM** When importing an invoice, we don't want to round the discounts, to avoid discrepancy between the subtotal computed by Odoo, and the subtotal of the file we import. To do this, we change the decimal precision of discount to 100 digits when importing files. However, float_round wasn't built with this in mind, in float round, we add a small epsilon to fix some rounding issue. This small epsilon changes the amount of the discount (50.0 -> 0.5000000000004) and this changes the subtotal. **STEP TO REPRODUCE** 1. Install l10n_edi_it. 2. Change the VAT number of IT Company to 05098540288 (to match the one on the file to import). 3. Import the file present in the bug ticket. 4. Notice the subtotal of the line doesn't match what's in the invoice. **FIX** We skip rounding of the discount on import. Ticket [link](https://www.odoo.com/odoo/project.task/6046324) opw-6046324 Forward-Port-Of: odoo/odoo#256037
This update resolves a bug that prevented the 'Display Thanks Message' option from working correctly in website popups and newsletter snippets. Previously, the thanks message wasn't shown after saving, and popups would close immediately. The fix ensures the thanks message is displayed as intended, improving the user experience for newsletter sign-ups.
Original PR description
Steps to reproduce: =================== 1. Add a Newsletter snippet to a website page. 2. In the snippet options, check "Display Thanks Message". 3. Save the page and re-enter edit mode. => The…
Steps to reproduce: =================== 1. Add a Newsletter snippet to a website page. 2. In the snippet options, check "Display Thanks Message". 3. Save the page and re-enter edit mode. => The checkbox appears unchecked and the thanks message preview is not shown. Also: 4. Add a Newsletter popup. 5. Check "Display Thanks Message", save. 6. Subscribe via the popup. => The popup closes immediately instead of showing the thanks message. Cause: ====== The `toggleThanksMessage` editor option was using `o_disable_preview` / `o_enable_preview` classes to determine the widget state via `_computeWidgetState`. These classes are removed by `cleanForSave`, so the state was lost after saving. Additionally, on subscribe success inside a popup, the modal was closed immediately regardless of whether the thanks message option was enabled. Solution: ========= - In `init`, restore the preview state from this attribute when entering edit mode. - `_computeWidgetState` now reads from the data attribute instead of checking preview classes. - On subscribe success, only show the thanks message (and keep the popup open) if `data-show-thanks-message` is set; otherwise close the popup as before. opw-6093824 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change reverts a recent update to Odoo's unit of measure (UoM) rounding method. The initial change was deemed too risky and caused a test failure, potentially leading to unexpected issues. We're now investigating a more targeted solution to ensure accurate UoM calculations.
Original PR description
This reverts commit 5dbb814. The commit seems too risky for stable, it broke a test in 18.2 which was recently modified only in 18.0 (see 8ba1214, not sure why it wasn't fw-ported). There is a chance it breaks other stuff silently. We'll look for a more local fix that doesn't affect other use cases.
This update resolves an issue where new company contacts created through invoices still incorrectly included DnB industry data (UNSPSC) as partner tags. The fix ensures that company creation from Partner many2one views aligns with the standard contact form, preventing unnecessary IAP credit usage. This improves data consistency and efficiency.
Original PR description
Partner Autocomplete was updated so DnB industry data (UNSPSC) is no longer stored on Partner Tags. That behavior was applied to the name/VAT char widget, but creating a company from a Partner…
Partner Autocomplete was updated so DnB industry data (UNSPSC) is no longer stored on Partner Tags. That behavior was applied to the name/VAT char widget, but creating a company from a Partner many2one (e.g. customer/vendor on an invoice) still used the old path: calling an IAP suggestion `iap_partner_autocomplete_add_tags` Steps to reproduce: ------------------- * Open a customer invoice (draft). * On Customer, search a company name and pick a Partner Autocomplete line to create a new company. * Save the quick-create dialog. > Observation: The new contact still had Partner Tags populated from DnB industry data (UNSPSC), unlike contacts created or enriched from the contact form autocomplete. (see video on ticket to avoid using more IAP credits) Why the fix: ------------ Align `res_partner_many2one` with `field_partner_autocomplete`: do not call `iap_partner_autocomplete_add_tags`. From task-5373200, industries from DnB must no longer be added as Partner Tags. opw-5972360
4 changes
Resolved issues and error corrections
This update corrects a bug where users could select customers from different companies within the Helpdesk system. The fix involved adding a restriction to the customer selection field, 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
This update corrects a bug in the Mod 349 tax report that prevented it from displaying vendor bills with amounts less than 1 Euro. The fix adjusts a calculation to ensure these small amounts are correctly included in the report, improving data accuracy for Spanish tax reporting.
Original PR description
Steps to reproduce: - Install l10n_es_reports. - Create a company from France. - Create and post a vendor bill for that company with an amount of 0.12 EUR. - Open the Tax Return report and switch to the Mod 349 report for the current year. - Click the 0.12 EUR amount line. Observed: - The journal items view opens with no records. Cause: - `_get_modelo349_audit_aml_domain()` calls `_custom_modelo349_common()`, which filters lines using: `float_compare(result_dict['value'], 0, precision_rounding=2)` - Using `precision_rounding=2` treats values below 1 as equal to 0, so those lines are excluded from the audit domain. Fix: - Replace `precision_rounding` with `precision_digits=2` so values are only treated as zero when they are effectively below 0.01. opw-6134339
This update resolves an issue where employees with manually created badges (without the '041' prefix) couldn't log into the Point of Sale system. The fix adds a fallback barcode listener to handle these cases, ensuring all employees can access the system. This was triggered by a mismatch between the system's barcode requirements and the badge format.
Original PR description
Steps to reproduce: ------------------- 1. Create an employee, set its badge to "1234567". Don't generate the badge using the "generate" button, type it manually. 2. Print the badge of that employee,…
Steps to reproduce: ------------------- 1. Create an employee, set its badge to "1234567". Don't generate the badge using the "generate" button, type it manually. 2. Print the badge of that employee, and take a photo of it for later. 3. Enable "Multi Employees per Session" for a PoS, and add the employee of step 1 into the "Basic rights" group. 4. Open the session, and click "Scan your badge", the camera will Open 5. Scan the badge printed in step 2 with the camera -> Error: "Unknonw Barcode: 1234567 ... The PoS couldn't find any product, customer, employee associated ...." Why it's happening: ------------------- The LoginScreen registers an exclusive barcode listener that only listens to barcode scan events related to employees, which makes sense on the login screen: we don't want to scan products or etc, just employees so they can log in. However, from the nomenclature rules of point_of_sale, a cashier barcode must start with 041. Since our cashier has a custom barcode " 1234567" (not starting with "041"), the "cashier" barcode listener is never triggered, and a default error message is thrown. Note that generating the badge with the "generate" button automatically appends the "041" prefix to the beggining of the badge code, so the issue does not exist if we automatically generate the badge. Fix: ---- When the cashier barcode listener is registered from the login screen, i.e. with `exclusive === true`, we also add a fallback listerner on the 'product' type with the same cashier action! Why 'product'? Because it's the last type tried to match against, as last resort, when all the other types don't match. With that fix, old employees having badges manually generated and hence not prefixed with "041" would be able to login. opw-6125029
This update fixes an issue where the return quantity displayed in the stock return wizard was incorrect when the product's unit of measure differed from the unit of measure used in the original delivery order. The system now correctly converts quantities to the product's UoM, ensuring accurate return calculations. This improves the reliability of inventory management.
Original PR description
Steps to reproduce: - Create a storable product "P1" with UoM set to KG - Update on-hand quantity to 1 KG - Create a delivery order for 100g of P1 and validate it - Click the Return button Problem: The return wizard displayed 100 KG instead of 0.1 KG. The `uom_id` field on `stock.return.picking.line` is a non-stored related field pointing to `product_id.uom_id`. The quantity was taken directly from the stock move (expressed in the move's UoM) without being converted to the product's UoM before being passed to the wizard. Solution: Convert the quantity from the move's UoM to the product's UoM. opw-6113515