Daily updates from Odoo
Monday, May 4, 2026
36 changes · saas-19.3
Resolved issues and error corrections
This update removes a confusing setting related to WHT return types in the Sri Lanka (l10n_lk) reports. Previously, the system was incorrectly mixing WHT closing entries with VAT closing entries, leading to potential reporting errors. This change ensures accurate reporting of withholding taxes.
Original PR description
WHT does not require a closing entry. The current return type is causing VAT closing entry to mix with WHT closing entry or vice versa. task-6157814 Forward-Port-Of: odoo/enterprise#115576
This update prevents invoices from being silently rolled back to draft when a payment batch reconciliation fails due to approval rules. Previously, a third-party module could block the posting process, requiring users to manually correct the invoice. Now, the system correctly handles these scenarios, ensuring payments remain posted.
Original PR description
When unreconciling a batch payment from a bank statement line, delete_reconciled_line() resets the linked invoice to draft to recompute its amount_residual, then re-posts it. If a third-party module…
When unreconciling a batch payment from a bank statement line, delete_reconciled_line() resets the linked invoice to draft to recompute its amount_residual, then re-posts it. If a third-party module (e.g. Studio Approvals) silently rejects action_post for the current user, the invoice stays in draft and the user has to redo the work manually. This internal repost is not a business action, the move was already approved when initially posted, so it can run as sudo to bypass approval checks. Steps to reproduce: 1. Add a Studio Approval rule on account.move.action_post with an approver other than the current user 2. As a user without that approval right, post a vendor bill and register a payment 3. Add the payment to a batch payment 4. Reconcile a bank statement line with the batch payment 5. With the user without approval rights, try to unreconcile the bank statement line (delete_reconciled_line) - Expected: the bill stays Posted. - Actual (before fix): the bill silently rolls back to Draft because action_post is rejected by the approval hook. opw-6121448 Forward-Port-Of: odoo/enterprise#115579 Forward-Port-Of: odoo/enterprise#115241
This update clarifies the tax selection process on Saudi invoices by disabling the incorrect '0% Not Subject to VAT' option. Previously, users were selecting this option instead of the appropriate '0%' tax rates, leading to potential compliance issues with ZATCA regulations. This change ensures invoices accurately reflect supply characteristics and meets legal requirements.
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 ensures the session cookie is consistently set for Odoo.sh users, preventing frequent disconnections when sending messages. Previously, the cookie was only set if a specific database was defined, which caused issues with the Odoo.sh environment. This change enhances the overall reliability of the Odoo.sh connection.
Original PR description
Before this commit, the session cookie was only being set when the `db_name` is defined in `odoo.conf`. This was because it was used to identify the correct DB in a multi-DB setup. However, having the session cookie set also prevents frequent disconnects on every message when connected to an odoo.sh DB. After this commit, the session cookie is always set even when no `db_name` is defined. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261802
This update resolves a bug in the POS system where tours would incorrectly terminate. The issue stemmed from a misinterpretation of the tour progress, preventing the tour from stopping when the JS bundle wasn't fully loaded. The fix ensures the tour correctly identifies its completion point, improving the user experience.
Original PR description
There is an issue with the POS since 19.3, when a tour is running, the tour service would get the tour name from the backend with 0 steps, and because the JS bundle of the tours is not loaded by the…
There is an issue with the POS since 19.3, when a tour is running, the tour service would get the tour name from the backend with 0 steps, and because the JS bundle of the tours is not loaded by the POS frontend the tour would continue with 0 steps.
Most of the time the currentActionIndex would be > 0, so the check on line 87 of `tour_interactive.js` would pass
```
if (this.currentActionIndex === this.actions.length)
```
and later run into a
```
TypeError: Cannot read properties of undefined (reading 'step')
at TourInteractive.play (http://localhost:8069/web/assets/debug/point_of_sale.assets_prod.js:121705:33) (/web_tour/static/src/js/tour_interactive/tour_interactive.js:95)
at TourInteractive.start (http://localhost:8069/web/assets/debug/point_of_sale.assets_prod.js:121655:14) (/web_tour/static/src/js/tour_interactive/tour_interactive.js:45)
at TourService.resumeTour (http://localhost:8069/web/assets/debug/point_of_sale.assets_prod.js:123226:39) (/web_tour/static/src/js/tour_service.js:260)
```
I'm not sure what's the correct fix,
- either what I did here
- change the condition on the `play()` to `this.currentActionIndex >= this.actions.length` instead of `this.currentActionIndex === this.actions.length`
- bundle the tours inside the POS front end (although they are not used there so it seems unnecessary)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue where correction payslips were failing validation due to missing information. The update ensures that correction payslips include the necessary structure ID and adjusts the payrun period to accommodate multi-month corrections, improving the accuracy of payroll processing.
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
This update fixes a bug preventing users from seeing all available employee types within the Payroll module. The issue stemmed from a recent change that incorrectly filtered employee types based on country settings. This ensures all employee types are consistently visible, streamlining the employee onboarding process.
Original PR description
Version: - saas-19.3 Steps to reproduce: - Install the Payroll module - Navigate to the Employees menu - Open an employee record - Go to the Payroll tab - Try selecting an Employee Type Issue: - Users are unable to see all employee types. This happens because some employee types do not have a country set, causing them to be excluded by the domain filter. However, users should be able to view all employee types regardless of the country field. Fix: - A recent change introduced in PR https://github.com/odoo/odoo/pull/258284 modified the domain, which caused this issue. This PR updates the domain to ensure all employee types are visible as expected. Task-6167327 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue preventing users from deleting time off allocations that were created after a payslip had been validated. Previously, the system incorrectly blocked deletion, requiring manual adjustments through HR. This change ensures time off allocations can be deleted regardless of when they were created relative to payslip validation.
Original PR description
## Issue When creating a time off for a date that is already covered by a confirmed payslip, that time off cannot be deleted. ## Steps to reproduce 1. Install *Time Off in Payslips*…
## Issue
When creating a time off for a date that is already covered by a confirmed payslip, that time off
cannot be deleted.
## Steps to reproduce
1. Install *Time Off in Payslips* (`hr_payroll_holidays`)
2. Create or use an employee E with a running contract, e.g.:
- Contract: Jan 1 to Indefinite
- Wage: $1000/month
3. In Payroll > Payslips, create a new Off-Cycle for Employee E:
- Period: March 1 - March 31
- *Compute Sheet*, *Confirm* and *Mark as paid*
4. In Time Off > Management > Time Off, create a new time off allocation for Employee E:
- Date: anywhere during March
- *Save* and *Validate*
5. Try to delete the allocation
6. **An error occurs: _"The pay of the month is already validated with this day included. If you need to adapt, please refer to HR."_**
## Cause
The condition under which this error is raised is defined in `_check_uncovered_by_validated_payslip`:
https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_payroll_holidays/models/hr_leave.py#L195-L203
It was originally added by https://github.com/odoo/enterprise/commit/1abb4a815ecb32557fc773cae54baf3e205d9b8c to prevent the deletion of holidays created **before** validating a payslip.
The condition does not take in account the moment when the leave was created. If a leave is created after the computation of the payslip, it did not impact that payslip, and thus can be deleted without risk.
opw-6089990
Forward-Port-Of: odoo/enterprise#115659
Forward-Port-Of: odoo/enterprise#114895This update fixes a critical issue where gift cards and e-wallets could be reused after being refunded, leading to potential fraud. Refunds for these cards are now prevented, and the system now correctly handles products linked to multiple loyalty programs, ensuring distinct order lines are created.
Original PR description
Previously, it was possible to refund a gift card or e-wallet after creation. However, the associated code remained usable, allowing the gift card or e-wallet to be reused, which is not the expected behavior. To address this, refunds for gift cards and e-wallets are now prevented. Additionally, when a product is part of the trigger products for multiple gift card or e-wallet programs, it was not possible to create separate order lines for the same product with different programs selected. The second line was merged into the first. A condition has been added to prevent merging when different programs are selected. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6052281 Forward-Port-Of: odoo/odoo#262208 Forward-Port-Of: odoo/odoo#256896
This update resolves a bug where editing an already-edited message would cause unexpected behavior, like incorrect selection or empty message fields. The fix removes a redundant 'edited' span from the editor content, ensuring messages are edited correctly and consistently. This improves the user experience for message composition and editing.
Original PR description
When editing an already-edited message, the `(edited)` span was included in the editor's editable content because `prepareBodyForEditing` (formerly `getNonEditableMentions`) passed the raw body…
When editing an already-edited message, the `(edited)` span was included in the editor's editable content because `prepareBodyForEditing` (formerly `getNonEditableMentions`) passed the raw body directly to the composer. This caused two issues: - CTRL+A would select the `(edited)` label, allowing it to be styled, repositioned, or accidentally deleted. - CTRL+A + Backspace + retype left the body empty after saving, because the self-closing `<span class="o-mail-Message-edited"/>` in the stored HTML was parsed by browsers as an open tag (spans are not void elements), swallowing subsequent content as its children. Fix: strip `.o-mail-Message-edited` from the body before loading it into the editor. The server always re-appends a fresh `(edited)` span at the end when saving, so removing it from the editor content is safe and correct. Also align the mock server with the real server behavior: - Place the span *inside* the last `div`/`p` element instead of after it. Rename `getNonEditableMentions` → `prepareBodyForEditing` to reflect that the function now covers both making mentions non-editable and stripping the edited label. task-6172161 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261772
This update resolves critical issues with the Documents Sign feature, preventing crashes when deleting sign templates and ensuring accurate tracking of document lineage across multiple templates. The change improves stability and data integrity for users managing signature workflows.
Original PR description
Steps to reproduce: Bug 1 (The Crash): 1. Open Documents app, select a PDF, and click Action > Sign. 2. In the Sign app, delete the newly created Sign Template. 3. Return to the Documents app. 4. A…
Steps to reproduce:
Bug 1 (The Crash):
1. Open Documents app, select a PDF, and click Action > Sign.
2. In the Sign app, delete the newly created Sign Template.
3. Return to the Documents app.
4. A traceback occurs (`KeyError: <document_id>`) in `web_read`.
Bug 2 (The Broken Lineage):
1. Create two separate Sign Templates from the exact same Document.
2. Send a signature request from the second template.
3. The `reference_doc` on the signature request fails to link back to the original Document.
Current behavior:
When creating a sign template from a document, `documents_sign` intentionally unlinks the original `ir.attachment` (`res_model = False`) to pass custody to `sign.document`. If the template is deleted, the attachment is orphaned, permanently corrupting the original `documents.document` and crashing the UI.
Furthermore, the lineage tracking (`reference_doc`) relies strictly on a 1:1 shared `attachment_id`. If a user creates multiple templates from one document, the system is forced to make a copy for the second template, natively breaking the lineage tracking because the IDs no longer match.
Expected behavior:
Documents should not be corrupted when generating or deleting sign templates. Furthermore, lineage tracking (`reference_doc`) should successfully link back to the original document regardless of how many templates have been generated from it.
Fix:
1. Replaced the `res_model = False` custody-handoff hack in `documents_sign` with a safe `.copy({'original_id': attachment.id})`. This sandboxes the Sign app's files, completely preventing the deletion crash and the multi-template conflicts.
2. Updated the `reference_doc` computation in `sign.request` to dynamically search for both the current `attachment_id` AND its `original_id` (utilizing a minimal-diff recordset union `|`). This perfectly preserves the lineage tracking for all templates without requiring database schema changes.
Task: 5432116
Forward-Port-Of: odoo/enterprise#114221
Forward-Port-Of: odoo/enterprise#113167This update fixes an issue where the namespace for DIAN credit notes was incorrectly configured, causing errors when submitting to the DIAN tax authority. The change ensures that only the top-level node of the credit note has the correct namespace, aligning with DIAN requirements and preventing submission failures. This resolves a recurring problem identified previously.
Original PR description
Issue: Incorrect `sts` namespace raises several issues when sent to dian Steps to reproduce: - On a Colombian company - Create a credit note - Send to DIAN Current Behavior: - Credit note have `sts` namespace defined to `dian:gov:co:facturaelectronica:Structures-2-1` while their Extension node has another `sts` namespace to `http://www.dian.gov.co/contratos/facturaelectronica/v1/Structures` Expected Behavior: - Only the top level Node should have `sts` namespace defined to `dian:gov:co:facturaelectronica:Structures-2-1`. It was forgotten that Credit Note were part of the Invoices in the last refactor. As it's the second time(odoo/enterprise#68619 3rd commit) it happens, I updated the test. opw-6077050 Forward-Port-Of: odoo/enterprise#114725 Forward-Port-Of: odoo/enterprise#113643
This update resolves an issue where transcription summaries were incorrectly duplicated across multiple chat records. The fix ensures that summaries are now only posted to the relevant current chat, and also addresses 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 fixes a technical issue that caused error messages when generating tax reports via the Odoo wizard. Now, if a certificate isn't set up, users receive a helpful message guiding them to configure one, preventing confusing tracebacks and ensuring smooth report submission.
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#112951
This update ensures that vendor bills can now be searched using the 'expense_direct_cost' account type. Previously, this account type wasn't searchable, which limited reporting capabilities. The change removes a restriction on account code filtering during searches, improving search accuracy and usability.
Original PR description
The expense direct cost account (account_type: expense_direct_cost) should also be searchable on vendor bills, and search by account code should ignore filters (reverted change) task-id: [6138677](https://www.odoo.com/odoo/project/967/tasks/6138677) origin pr: https://github.com/odoo/odoo/pull/257850 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260076
This update adds a configuration setting to enable logging of order data during support investigations. By including the order's receipt reference, it makes identifying and tracking specific orders in logs much easier. This enhancement improves our ability to quickly resolve customer issues.
Original PR description
During support investigations, it can be useful to log the data of the orders being processed in `sync_from_ui`. This commit adds a configuration parameter `point_of_sale.log_order_data` that allows to enable this logging. By default, it is disabled to avoid filling the logs with potentially sensitive data. Also, the pos_reference field is added to the order representation in the logs, as it's printed in the receipt and can be useful to identify the order in the logs. opw-6145038 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262109 Forward-Port-Of: odoo/odoo#261792
This update addresses a user experience issue where a lingering Point of Sale session remained active after a user closed their browser tab or navigated away. This caused confusion for users and prevented proper session management. The fix ensures sessions are correctly terminated when the Point of Sale is no longer in use.
Original PR description
When the user closes the browser tab or navigates away after a session in opening_control, the session is not deleted and it causes confusion. opw-6114420 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261207 Forward-Port-Of: odoo/odoo#258933
This update addresses a user experience issue where a session in the opening_control POS module wouldn't automatically close when the user left the browser tab or navigated away. This prevented confusion for users and ensured sessions were properly terminated, improving overall system stability. The change was driven by a reported problem (opw-6114420).
Original PR description
When the user closes the browser tab or navigates away after a session in opening_control, the session is not deleted and it causes confusion. opw-6114420 Forward-Port-Of: odoo/enterprise#115056
This update optimizes how prices are calculated in Point of Sale (POS) transactions. Previously, redundant price recalculations were slowing down the system, especially during order merges. This change consolidates price updates, resulting in faster and more efficient POS operations. The update also improves performance by preventing unnecessary data serialization in production environments.
Original PR description
Calling triggerRecomputeAllPrices() synchronously on every orderline mutation (create, merge, delete) caused the full tax/price computation to run 3 times per addLineToOrder call when a merge occurred, and triggered an expensive JSON.parse/JSON.stringify of the price data on each of those calls via logPosMessage. Replace the eager synchronous recompute with a microtask coalescer: the first call within a synchronous operation schedules a single Promise.resolve().then() microtask; subsequent calls within the same tick are no-ops. Because the microtask is queued before the outer await continuation (updatePrograms), _updatePrograms still reads fresh prices when it accesses line.prices. Also guard the args serialization in logPosMessage behind odoo.debug so the JSON deep-clone of the price data object is skipped entirely in production. opw-6091501 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260436
This update corrects a problem where existing ARCA connections persisted after duplicating an Odoo database. This prevented users from properly testing without impacting live production connections. The fix ensures ARCA connections are cleared when database credentials are updated, improving stability and preventing unintended production usage.
Original PR description
Problem and Cause: When duplicating a database with existing ARCA connections, the connections to ARCA webservices are not cleared. Users using the duplicate database may not realize that the ARCA connections are still present. This may lead to production connections getting used while users are testing. Solution: Clear connections to ARCA webservices when updating the credentials. Forward-Port-Of: odoo/enterprise#115068
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