Daily updates from Odoo
Thursday, September 18, 2025
58 changes
3 changes
Enhancements to existing features
Accounting KPI summaries now include posted bank journal entries tied to unreconciled bank statements. This gives businesses a more complete view of outstanding bank activity and helps prevent understated accounting indicators.
Original PR description
### [REF] account: reorganize kpi.provider tests The account test_kpi_provider was already getting complicated, and this commit aims to simplify it by breaking it into smaller tests that show more clearly what is expected. Task-id: 5062431 ### [IMP] account: make kpi.provider report unreconciled bank statements The `kpi.provider:get_account_kpi_summary` method should include posted moves of a bank journal that are related to an unreconciled bank statement. Task-id: 5062431 Forward-Port-Of: odoo/odoo#227744 Forward-Port-Of: odoo/odoo#227605
Resolved issues and error corrections
Pasted tables with a header row from tools like ChatGPT are now normalized so the editor can handle them correctly. This prevents crashes or selection problems when users edit or delete rows in those tables, improving reliability for content editing.
Original PR description
**Current behavior before PR:** Steps to reproduce: - Copy a table from chatGPT's response containing first row wrapped in `<thead>`. - Paste it in editor. - Select last row. - Pressing backspace leads to traceback. This issue happens because the copied table is pasted with first row wrapped in a thead element. Due to this, rows are wrongly calculated leading to traceback in removeRow method. **Desired behavior after PR is merged:** - This commit ensures that if a table has first row wrapped inside a `thead`, the row is moved from `thead` to the start of `tbody` ensuring that rows are calculated correctly. - This commit also replaces all the `<th>` elements with `<td>`. task-5048339 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226990 Forward-Port-Of: odoo/odoo#224784
Changing a customer’s country could crash checkout when the same shopper had reward-enabled carts open on multiple websites. This fix lets Odoo update pricing and loyalty rewards across those carts correctly, avoiding an interruption to the shopping experience.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have 2 eCommerce sites; 2. have a user with an open cart in both sites; 3. have a reward applied in one or both of carts; 4. have a fiscal position applicable…
Versions -------- - 16.0+ Steps ----- 1. Have 2 eCommerce sites; 2. have a user with an open cart in both sites; 3. have a reward applied in one or both of carts; 4. have a fiscal position applicable to the user's address; 5. change the user's country to one with a different fiscal position. Issue ----- > ValueError: Expected singleton: sale.order(1, 2) Cause ----- As of commit ede8846987a98, fiscal positions get recomputed on address changes. When a fiscal position changes, the `_recompute_prices` method gets called on all open carts. This method does not include an `ensure_one` check, so it should be able to handle multiple sales orders. However, the `sale_loyalty` override will call `_update_programs_and_rewards` on `self` if any reward line is encountered. This method does have an `ensure_one` check, leading to the error. Solution -------- Rewrite the override as a loop, so it can handle multiple records in `self`. opw-5017669 Forward-Port-Of: odoo/odoo#224225
5 changes
Enhancements to existing features
Accounting KPI reporting now includes posted bank journal entries linked to unreconciled bank statements. This gives businesses a more complete view of pending bank activity and helps avoid understated account indicators.
Original PR description
### [REF] account: reorganize kpi.provider tests The account test_kpi_provider was already getting complicated, and this commit aims to simplify it by breaking it into smaller tests that show more clearly what is expected. Task-id: 5062431 ### [IMP] account: make kpi.provider report unreconciled bank statements The `kpi.provider:get_account_kpi_summary` method should include posted moves of a bank journal that are related to an unreconciled bank statement. Task-id: 5062431 Forward-Port-Of: odoo/odoo#227744 Forward-Port-Of: odoo/odoo#227605
Resolved issues and error corrections
Follow-up PDF reports now correctly include attachments stored as remote links or in cloud storage. This prevents report generation failures and helps users reliably produce customer follow-up documents regardless of where files are stored.
Original PR description
### Issue PDF reports fail when attachments are remote URLs or cloud storage resources. The to_pdf_stream() method expects local file data but receives boolean values from remote attachments, causing a TypeError. ### Solution Download remote resources before processing them in PDF reports. This ensures all attachments have accessible data regardless of storage type. ### Affected Reports (enterprise): - account_followup.report_followup_print_all [Community PR](https://github.com/odoo/odoo/pull/226094) OPW-5036638 Forward-Port-Of: odoo/enterprise#94975 Forward-Port-Of: odoo/enterprise#94477
PDF report generation now downloads remote or cloud-stored attachments before including them. This prevents errors when printing vendor bills or expense sheets that reference files stored outside Odoo, improving reliability for businesses using cloud storage links.
Original PR description
### Issue PDF reports fail when attachments are remote URLs or cloud storage resources. The `to_pdf_stream()` method expects local file data but receives boolean values from remote attachments,…
### Issue PDF reports fail when attachments are remote URLs or cloud storage resources. The `to_pdf_stream()` method expects local file data but receives boolean values from remote attachments, causing a TypeError. ### Solution Download remote resources before processing them in PDF reports. This ensures all attachments have accessible data regardless of storage type. ### Affected Reports - `account.report_original_vendor_bill` - Vendor bill reports - `hr_expense.report_expense_sheet` - Expense sheet reports ### Affected Versions - 18.0+ (17.0 theoretical; cloud_storage wasn't implemented, so doesn't make sense) ### Reproduction Steps #### Option A: HR Expense Report 1. Create HR expense record 2. Add attachment with type=url/cloud_storage pointing to valid PDF URL 3. Link attachment to hr.expense record 4. Generate expense report → TypeError occurs #### Option B: Vendor Bill Report 1. Create vendor bill (account.move) 2. Add attachment with type=url/cloud_storage pointing to valid PDF URL 3. Link attachment to account.move record 4. Print Original Vendor Bill → TypeError occurs ### Error Details ```python TypeError: a bytes-like object is required, not 'bool' at /odoo/tools/pdf/__init__.py:220 in to_pdf_stream from /odoo/addons/hr_expense/models/ir_actions_report.py:29 ``` #### Reference Client demo: https://drive.google.com/file/d/1HUvZqZ21NiX34T2IQhuVNbLP41xSV7jq/view OPW-5036638 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227571 Forward-Port-Of: odoo/odoo#226094
Fixes an issue where tables pasted from sources like ChatGPT could cause the editor to crash or fail to select rows correctly. The editor now normalizes pasted table headers so users can edit and delete table rows reliably.
Original PR description
**Current behavior before PR:** Steps to reproduce: - Copy a table from chatGPT's response containing first row wrapped in `<thead>`. - Paste it in editor. - Select last row. - Pressing backspace leads to traceback. This issue happens because the copied table is pasted with first row wrapped in a thead element. Due to this, rows are wrongly calculated leading to traceback in removeRow method. **Desired behavior after PR is merged:** - This commit ensures that if a table has first row wrapped inside a `thead`, the row is moved from `thead` to the start of `tbody` ensuring that rows are calculated correctly. - This commit also replaces all the `<th>` elements with `<td>`. task-5048339 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226990 Forward-Port-Of: odoo/odoo#224784
This fix prevents an error when a customer has open carts on multiple eCommerce sites and their country change triggers different tax settings. Loyalty rewards are now recalculated separately for each cart, so customers can continue shopping without interruption.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have 2 eCommerce sites; 2. have a user with an open cart in both sites; 3. have a reward applied in one or both of carts; 4. have a fiscal position applicable…
Versions -------- - 16.0+ Steps ----- 1. Have 2 eCommerce sites; 2. have a user with an open cart in both sites; 3. have a reward applied in one or both of carts; 4. have a fiscal position applicable to the user's address; 5. change the user's country to one with a different fiscal position. Issue ----- > ValueError: Expected singleton: sale.order(1, 2) Cause ----- As of commit ede8846987a98, fiscal positions get recomputed on address changes. When a fiscal position changes, the `_recompute_prices` method gets called on all open carts. This method does not include an `ensure_one` check, so it should be able to handle multiple sales orders. However, the `sale_loyalty` override will call `_update_programs_and_rewards` on `self` if any reward line is encountered. This method does have an `ensure_one` check, leading to the error. Solution -------- Rewrite the override as a loop, so it can handle multiple records in `self`. opw-5017669 Forward-Port-Of: odoo/odoo#224225
1 change
Resolved issues and error corrections
Payroll users with Administrator access can now cancel completed payslips as intended. This prevents unnecessary errors and lets payroll teams manage corrections without needing full system administrator rights.
Original PR description
steps to reproduce: ------------------- 1. Install payroll 2. Create a user and grant "Administrator" access to Payroll. 3. Log in as the new user and try to cancel a 'Done' payslip. issue: ------ A UserError is raised: "Cannot cancel a payslip that is done." observation: ------------ A user with Payroll "Administrator" access is unable to cancel a payroll payslip cause of the issue: ------------------- During cancellation, the system checks whether the user is "Admin" instead of verifying if the user has Payroll "Administrator" access. https://github.com/odoo/enterprise/blob/13832d80570956e504e1c09f41acbeb0bc4baedc/hr_payroll/models/hr_payslip.py#L509-L513 solution: ---------- Check that the user has Payroll "Administrator" access. opw-5040029 Forward-Port-Of: odoo/enterprise#93831
7 changes
Resolved issues and error corrections
This update fixes an issue in Odoo Sign where users could not drag fields after uploading multiple documents. Teams can now prepare signing packets with several documents more smoothly, without field placement getting blocked.
Original PR description
Version: - saas-18.3 Steps to reproduce: - install sign - upload multiple documents - try to drag the field Issue: - Fields cannot be dragged when multiple documents are uploaded. Solution: - update the condition to check if !acive then return no need to preventdefault. Impact: - Users can now upload multiple documents and drag/drop fields without issues. Forward-Port-Of: odoo/enterprise#94959 Forward-Port-Of: odoo/enterprise#94882
Uploading documents to the Sign app now uses a PDF form-reading method compatible with newer PDF software. This prevents crashes during sign template creation and helps users continue preparing documents reliably.
Original PR description
### Issue: - The `getFields` method is not supported in the PyPDF version 3.x. - This caused an `AttributeError` when uploading a document for sign. ### Fix: - Replaced `getFields` method with `getFormTextFields`. This is more compatible than the earlier one ### Impact: - Prevents template creation crashes Forward-Port-Of: odoo/enterprise#95005
Fixed project template conversion so tasks correctly keep their template status. This prevents template tasks from being treated like regular field service work, ensuring project roles are only configured on normal tasks.
Original PR description
This feature was supposed to be introduced in 19 but got lost with the reversal of the templates refactor. When converting a project to a template, the tasks should retain their template status. Task templates in project templates are treated the same as task templates in normal projects. Project roles should be configured only on normal tasks and not on task templates. Task-5087632 Forward-Port-Of: odoo/enterprise#94849
This fixes an issue where settling a point-of-sale order for rental services could incorrectly reset delivered quantities and block valid returns. Rental service delivery quantities are now left for sales staff to manage manually, reducing errors during POS checkout and rental returns.
Original PR description
With [^1], a new constraint was introduced on sale order lines in rental to ensure the returned quantity does not exceed the delivered quantity. While this constraint is logical, it uncovered a bug…
With [^1], a new constraint was introduced on sale order lines in rental
to ensure the returned quantity does not exceed the delivered quantity.
While this constraint is logical, it uncovered a bug in the integration
between rental, POS, and stock. Specifically, when a POS order is
settled, the `pos.order.sync_from_ui` method reconciles the models.
If the rented product is a service, no picking is created, which means
no stock move, resetting the delivered quantity to zero. This triggers a
constraint violation if a returned quantity already exists (e.g., 0 >=
positive).
This commit applies the following fixes:
- If the SOL product is a service, we do not update its delivered
quantity as it is managed manually by the salesperson on the SOL
directly.
- Additionally, we remove the constraint to allow more flexibility.
opw-5076638
[^1]: https://github.com/odoo/enterprise/pull/88689
[^2]: https://github.com/odoo/enterprise/pull/90510
Forward-Port-Of: odoo/enterprise#94357This update fixes several small issues in accounting audits and reports, including opening aged receivable checks correctly, keeping audit scroll position, and using the right reporting period. It also improves audit usability by allowing audit names to be edited, showing the last message in balance views, and making duplicated labels more consistent.
Original PR description
- Removed " from the description of the age receivable followup check template - Age receivable checks can now be openned (before it said Invalid code) - Fix Account Status Badge colors not present on reports - Keep the scroll position on audit checks (Cycle) - Remove dead code _get_state_field in l10n_in_reports - Use the right period when opening a report from a check in an audit - Adding (copy) when duplicating a return type - Add the possibility to edit the name of the Audits - Add the last message column in the balance list view of the audit - Allow only the audit and use the right view when opening the returns from the accounting dashboard - Using copy instead of Copy when duplicating taxes Forward-Port-Of: odoo/enterprise#94806
Bank reconciliation can now match payments using shorter sales order references such as SO0001. This helps businesses reconcile bank transactions more reliably without waiting for longer reference numbers.
Original PR description
Matching on references was limited to matching words > 8, to increase reliability, but the default sequence for sale orders is 6 characters (SO0001), so they would never be found unless we reach SO1000000 -_- Forward-Port-Of: odoo/enterprise#94821 Forward-Port-Of: odoo/enterprise#93640
Canadian CPA005 payment files now use the batch payment name as the originator cross-reference, helping ensure each payment in a batch has a unique identifier. This prevents files from being rejected by banks such as CIBC and RBC when references are blank or duplicated.
Original PR description
… Reference No is blank on non-unique CPA0005 Alphanumeric Originator's Cross Reference No is blank on non-unique Impacted versions: 17.2 17.3 17.4 18.0 18.1 18.2 18.3 18.4 master Steps to reproduce: create a new batch payment create cpa005 payment file rejected by CIBC and RBC Current behavior: Uses payment_reference which is blank or non-unique Causes bank to reject on non-unique status Expected behavior: To have every batch payment reference (name of payment) be unique through the batch
35 changes
Enhancements to existing features
Users can now sort list view columns based on supported Properties fields, making it easier to organize and analyze records. The update also improves how property definitions are saved internally, reducing test complexity and making the feature more reliable.
Original PR description
#### [FIX] core: Ensure proper flushing of property definitions The get_property_definition() method was not flushing the properties definition field. This oversight made it necessary to explicitly call flush_all() in every properties test. By ensuring that get_property_definition() now correctly flushes the definition, the method becomes more robust, and many tests can be simplified. #### [IMP] web: Make properties fields sortable in the list view In list views, columns for specific Properties fields aren't selectable for sorting. However, the back-end can already sort scalar properties. This change modifies record.js to add the sortable attribute to properties added as fields.
New companies will no longer inherit payment provider credentials or automatically publish providers that still need proper setup. This reduces configuration mistakes and also lets users unpublish disabled payment providers when needed.
Original PR description
**[IMP] payment_*: set copy=False on credential fields** Since different companies typically require distinct credentials, we avoid copying them during company creation by setting copy=False on all credential fields. Additionally, because credentials are necessary for proper setup, payment providers should not be published automatically when a new company is created. opw-5083526 --- **[FIX] payment: allow unpublishing a disabled provider** A user error was incorrectly raised when unpublishing a disabled payment provider, as the check was not considering the published status before raising the error. Such a scenario was possible when, for example, a provider was duplicated while being published, as the state would be set to 'disabled', while the published status was left unchanged.
Accounting KPI summaries now include posted bank journal entries linked to unreconciled bank statements. This gives businesses a more complete view of pending bank activity and supports more reliable financial monitoring.
Original PR description
### [REF] account: reorganize kpi.provider tests The account test_kpi_provider was already getting complicated, and this commit aims to simplify it by breaking it into smaller tests that show more clearly what is expected. Task-id: 5062431 ### [IMP] account: make kpi.provider report unreconciled bank statements The `kpi.provider:get_account_kpi_summary` method should include posted moves of a bank journal that are related to an unreconciled bank statement. Task-id: 5062431 Forward-Port-Of: odoo/odoo#227744 Forward-Port-Of: odoo/odoo#227605
Invoices created from sales orders now include the sales order number as the reference when no customer reference is already provided. This helps businesses match invoices and prepayments more reliably, while payment memos are also cleaned to reduce incorrect automatic matches.
Original PR description
Unless there's already a customer reference, we need the SO name to be able to match any prepayment --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227089 Forward-Port-Of: odoo/odoo#224999
Discuss calls now use the same enhanced meeting layout in picture-in-picture mode as they do in fullscreen. This gives users access to more meeting features, such as panels and chat, while keeping the call in a floating window.
Original PR description
Before this commit, picture-in-picture in discuss call had only the call view in the picture-in-picture window. Recently the fullscreen uses meeting view, which has call view in addition to panels and other features such as chat. This commit makes picture-in-picture use the new meeting view, so that the picture-in-picture mode has more features. Before <img width="2552" height="1317" alt="Screenshot 2025-09-15 at 14 46 33" src="https://github.com/user-attachments/assets/d7e5ad67-fd68-4a65-9a19-b8ce11b9f66f" /> After <img width="2559" height="1323" alt="Screenshot 2025-09-15 at 14 51 45" src="https://github.com/user-attachments/assets/e6cbc12d-2753-42c9-ab73-aaf4abcc6f1e" />
Resolved issues and error corrections
Fixed project template conversion so task templates keep their intended template status. This helps field service teams use project templates consistently while ensuring project roles are only set on regular tasks, reducing setup errors.
Original PR description
This feature was supposed to be introduced in 19 but got lost with the reversal of the templates refactor. When converting a project to a template, the tasks should retain their template status. Task templates in project templates are treated the same as task templates in normal projects. Project roles should be configured only on normal tasks and not on task templates. Task-5087632
Fixes project templates so normal tasks and task templates are shown and handled correctly after a project is converted into a template. This prevents template-related filters from hiding regular tasks and ensures project roles are only configured on normal tasks, reducing confusion for users managing reusable project setups.
Original PR description
This feature was supposed to be introduced in 19 but got lost with [the reversal](https://github.com/odoo/odoo/pull/225953) of [the templates refactor](https://github.com/odoo/odoo/pull/220311). When converting a project to a template, the tasks should retain their template status. Task templates in project templates are treated the same as task templates in normal projects. Project roles should be configured only on normal tasks and not on task templates. Task-5087632
Uploading documents for Sign could fail when the system used a newer PDF library version. This change updates the PDF field-reading approach so users can create Sign templates without crashes.
Original PR description
### Issue: - The `getFields` method is not supported in the PyPDF version 3.x. - This caused an `AttributeError` when uploading a document for sign. ### Fix: - Replaced `getFields` method with `getFormTextFields`. This is more compatible than the earlier one ### Impact: - Prevents template creation crashes
Dialogs such as camera or microphone permission prompts now remain visible when users join a meeting. This prevents confusion and helps users complete required confirmations without leaving the call view.
Original PR description
The meeting view allows focusing on an ongoing call, removing any distraction with a full screen call view. To do so, the overlay service is used, and the call view takes the whole screen. However, other components, such as confirmation dialogs also use the overlay service. As a result, dialogs are sometimes hidden behind the meeting view. This commit ensures the meeting view won't hide other overlays by reducing it's z-index. Steps to reproduce: - Reset your mic/camera permission. - Start a meeting. - The call permission dialog is hidden by the meeting view. task-5095114
Subscription invoices that include combo products can now be created and confirmed without triggering validation errors. This prevents failed manual invoices and automatic payment processing for affected subscription orders.
Original PR description
Currently, an error is produced while creating an invoice for a subscription order with combo products, and it can be triggered in two different ways. 1. Directly create an invoice. - Create and…
Currently, an error is produced while creating an invoice for a subscription order
with combo products, and it can be triggered in two different ways.
1. Directly create an invoice.
- Create and confirm a subscription with a combo product.
- Create an invoice for this subscription and try to confirm it.
- Validation error shown in display and error generated in log
2. When cron "Payment: Post-process transactions" trigger:
- Enable the Automatic Invoice option in the Subscription settings.
- Activate a demo payment provider (e.g. Demo: Payment Provider).
- Create and confirm a subscription that includes a combo product.
- Click on "Pay" to process the subscription payment.
- An error occurs when the above-mentioned cron is triggered, and it
tries to create an invoice for a subscription order.
Error: `new row for relation "account_move_line" violates check constraint
"account_move_line_check_accountable_....`
This issue arises during the creation of an account move line for deferred entries for
the 'Combo Product' column of the original invoice (subscription):
- At [1], `deferred_start_date` and `deferred_end_date` were added to all invoice line values within `_prepare_invoice_line` used to create the original invoice
- Then, at [2], during confirmation of the `original invoice`, the code attempts to generate `deferred entries` for for move where any move lines that has a `deferred_start_date`
- At code line [3], during the generation of deferred entries, an account move line is created without an associated `account_id`
- During `display_type` computation at [Code](https://github.com/odoo/odoo/blob/9ec4e0d3c5f1aaff0b36dc5def1e69b8285c3be1/addons/account/models/account_move_line.py#L480-L484), `line.move_id.is_invoice()` evaluates to `False`. As a result, the line is assigned a `display_type` as a 'product'.
- Since `display_type` is 'product' and `account_id` is missing, it violates the following check constraint at [Code](https://github.com/odoo/odoo/blob/9ec4e0d3c5f1aaff0b36dc5def1e69b8285c3be1/addons/account/models/account_move_line.py#L451): `CHECK(display_type IN ('line_section', 'line_note') OR account_id IS NOT NULL)`
This commit fixes the issue by preventing the addition of the `deferred_start_date` and `deferred_end_date` keys for invoice lines whose corresponding sale order lines have products of type 'combo' at [1].
[1]:- https://github.com/odoo/enterprise/blob/9642f7d8026149a6524e036c523b65ccbdf17258/sale_subscription/models/sale_order_line.py#L448-L449
[2]:- https://github.com/odoo/enterprise/blob/9642f7d8026149a6524e036c523b65ccbdf17258/account_accountant/models/account_move.py#L113-L114
[3]:- https://github.com/odoo/enterprise/blob/9642f7d8026149a6524e036c523b65ccbdf17258/account_accountant/models/account_move.py#L309
sentry-6763423503
Forward-Port-Of: odoo/enterprise#90989Projects created from sales orders now automatically enable milestones when any ordered product is billed by milestone. This prevents sales and project teams from having to manually correct project settings and supports accurate milestone-based invoicing.
Original PR description
This commit fixes two issues related to the milestones settings of generated projects in SO: First issue: * Steps to reproduce: - Create a product whose invoicing is based on milestones - Add this…
This commit fixes two issues related to the milestones settings of generated projects in SO:
First issue:
* Steps to reproduce:
- Create a product whose invoicing is based on milestones
- Add this product to an SO
- Confirm the SO
- Create a project from the action button in the SO form view ('Create a Project'), with or without a project template
- The generated project does not have the milestone setting enabled
* Expected behavior:
=> When creating a project from the SO in which there is at least 1 product with invoicing based in milestone, the setting "Milestone" should be checked by default
Second issue:
* Steps to reproduce:
- Create a product with an invoice policy based on milestones
- Create another product with another policy
=> Both products must be configured to create a project on SO confirmation, without a project template
- Create a new SO with both products as SOLs
=> Set the second product (other policy) in first sequence, then the first product (milestones based) in second sequence, as the order of SOLs
- Confirm the SO
- The generated project does not have the milestone setting enabled
* Expected behavior:
=> The generated project should have the milestone setting enabled, as at least one product with an invoicing policy based on milestones has triggered the generation of that project
task-5090253
version: 19.0
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prWhen items from a receipt are moved into a new wave transfer, their related quality checks are now moved or recreated on the correct transfer. This prevents staff from missing required quality checks or completing them from the wrong receipt, improving accuracy in warehouse quality control.
Original PR description
*{quality_control,stock}_picking_batch ### Steps to reproduce: - Got to Quality > Quality control > Control Point - Create a quality control point: - Operation: receipt - Control per quantity or…
*{quality_control,stock}_picking_batch
### Steps to reproduce:
- Got to Quality > Quality control > Control Point
- Create a quality control point:
- Operation: receipt
- Control per quantity or product
- Create a and confirm a receipt transfer with 2 products
- Go to the receipt list view > select your receipt > Wheel action > Add to wave > Add to a new wave > Add only one of the move line to the wave
#### > A new picking is created and the move line reassigned to it but the related quality check picking_id is not updated.
> In particular, there is no "quality check" button on the new picking and the "quality check" button of the first picking allows you to process a QC related to the wave transfer.
### Cause of the issue:
While the move lines or move are can be moved to a new picking during the `_add_to_wave` call:
https://github.com/odoo/odoo/blob/605e47a85561614c17fe2e6f59618610f87c69bb/addons/stock_picking_batch/models/stock_move_line.py#L69-L90 Nothing is done with respect to the quality check which pciking_id field is not computed:
https://github.com/odoo/enterprise/blob/d73f7ef6fe61ccddbe1fe4e32c1670611ba3c5d2/quality/models/quality.py#L185
### Fix:
While the quality check measured on move_line are linked to a move line, the quality checks measured on products and operation are not. For the first kind, we rely on an override of the write method of stock move lines to reassign the check to the apporpiate picking. For the other kinds, we add a post batch hook to unlink the obsolete checks and recreate the appropiate one. Note that since operation and product types are created during the action confirm of moves and since certain moves will be created and auto confirm during the new picking creation here: https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock_picking_batch/models/stock_move_line.py#L90 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L857 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L1263-L1267 https://github.com/odoo/enterprise/blob/b99d7073a34b24d4d3b863278e68f292fdd3c0b0/quality_control/models/stock_move.py#L12-L15 we rely on the `extra_move_mode` to avoid quality check creation during this step (as they will be created in the hook).
Enterprise: https://github.com/odoo/enterprise/pull/92951
opw-5009635
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#224947
Forward-Port-Of: odoo/odoo#223852The website payment methods snippet now uses standard browser caching instead of storing data in the visitor session. This lets administrators see payment method changes after reloading while regular customers still benefit from faster page loading through a 7-day cache.
Original PR description
The "Supported Payment Methods" snippet introduced in [^1] was designed to cache payment methods to minimize server calls. However, this cache was stored in session storage, meaning it wasn't…
The "Supported Payment Methods" snippet introduced in [^1] was designed to cache payment methods to minimize server calls. However, this cache was stored in session storage, meaning it wasn't invalidated on page reloads. While this behavior worked well for regular customers, it was problematic for admins who needed to see backend changes reflected immediately upon reloading the page. This commit shifts the caching logic to rely on the HTTP caching mechanism. This change eliminates a significant amount of frontend code and centralizes the logic in the backend. The new approach disables caching for logged-in internal users while enforcing caching for regular customers visiting the website. Since payment methods are not expected to change frequently, a 7-day cache policy is enforced. After this period, the client must revalidate with the server, ensuring any inconsistencies are resolved in a timely manner. Additionally, a safeguard has been added to the snippet to prevent warnings in the console. task-2889752 [^1]: https://github.com/odoo/odoo/pull/213234
When receipt items are moved into a new wave or picking, their related quality checks are now moved or recreated on the correct transfer. This prevents teams from missing quality checks on the new transfer or processing checks from the wrong receipt.
Original PR description
*{quality_control,stock}_picking_batch ### Steps to reproduce: - Got to Quality > Quality control > Control Point - Create a quality control point: - Operation: receipt - Control per quantity or…
*{quality_control,stock}_picking_batch
### Steps to reproduce:
- Got to Quality > Quality control > Control Point
- Create a quality control point:
- Operation: receipt
- Control per quantity or product
- Create a and confirm a receipt transfer with 2 products
- Go to the receipt list view > select your receipt > Wheel action > Add to wave > Add to a new wave > Add only one of the move line to the wave
#### > A new picking is created and the move line reassigned to it but the related quality check picking_id is not updated.
> In particular, there is no "quality check" button on the new picking and the "quality check" button of the first picking allows you to process a QC related to the wave transfer.
### Cause of the issue:
While the move lines or move are can be moved to a new picking during the `_add_to_wave` call:
https://github.com/odoo/odoo/blob/605e47a85561614c17fe2e6f59618610f87c69bb/addons/stock_picking_batch/models/stock_move_line.py#L69-L90 Nothing is done with respect to the quality check which pciking_id field is not computed:
https://github.com/odoo/enterprise/blob/d73f7ef6fe61ccddbe1fe4e32c1670611ba3c5d2/quality/models/quality.py#L185
### Fix:
While the quality check measured on move_line are linked to a move line, the quality checks measured on products and operation are not. For the first kind, we rely on an override of the write method of stock move lines to reassign the check to the apporpiate picking. For the other kinds, we add a post batch hook to unlink the obsolete checks and recreate the appropiate one. Note that since operation and product types are created during the action confirm of moves and since certain moves will be created and auto confirm during the new picking creation here: https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock_picking_batch/models/stock_move_line.py#L90 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L857 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L1263-L1267 https://github.com/odoo/enterprise/blob/b99d7073a34b24d4d3b863278e68f292fdd3c0b0/quality_control/models/stock_move.py#L12-L15 we rely on the `extra_move_mode` to avoid quality check creation during this step (as they will be created in the hook).
Community: https://github.com/odoo/odoo/pull/223852
opw-5009635
Forward-Port-Of: odoo/enterprise#93995
Forward-Port-Of: odoo/enterprise#92951The replenishment action now works even when buying or manufacturing routes are set on the warehouse instead of directly on the product. This lets users replenish products from the forecast report again and choose valid buy or manufacture options when suppliers or bills of materials are available.
Original PR description
Steps to reproduce: - Create a product - Open the forecast report - Click "Replenish" Issue: Cannot replenish as now by default the buy/manufacture routes are set on the warehouse and no longer on the product itself We can simply remove the check on the route in the wizard, as now the procurement is smarter and can find the appropriate rules. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves several accounting audit and reporting workflows, including opening aged receivable checks correctly, preserving audit scroll position, and showing clearer audit balance information. It also tidies duplicate naming and dashboard filtering so users see the right records and more consistent labels.
Original PR description
- Removed " from the description of the age receivable followup check template - Age receivable checks can now be openned (before it said Invalid code) - Fix Account Status Badge colors not present on reports - Keep the scroll position on audit checks (Cycle) - Remove dead code _get_state_field in l10n_in_reports - Use the right period when opening a report from a check in an audit - Adding (copy) when duplicating a return type - Add the possibility to edit the name of the Audits - Add the last message column in the balance list view of the audit - Allow only the audit and use the right view when opening the returns from the accounting dashboard - Using copy instead of Copy when duplicating taxes
This fixes inventory valuation reporting so date-based values and average-cost products are handled correctly, even when some category settings are incomplete. It also makes it easier to backdate stock movements from the list view, helping businesses keep stock and accounting records aligned.
Original PR description
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
Odoo now recognizes Ecuadorian vendor invoice XML files downloaded from the SRI even when the invoice is wrapped inside a CDATA section. This allows vendor bill uploads to populate the bill details correctly, reducing manual entry and upload failures for Ecuadorian companies.
Original PR description
### Issue: Ecuadorian customer can download their invoice's XML from the SRI, but the file contains the invoice in a wrapper tag (`<![CDATA[ ... ]]>`) that prevent the extraction of the data to fill…
### Issue: Ecuadorian customer can download their invoice's XML from the SRI, but the file contains the invoice in a wrapper tag (`<![CDATA[ ... ]]>`) that prevent the extraction of the data to fill the vendor bill form view. #### Steps to reproduce: - Install "l10n_ec_edi" and switch to an Ecuadorian company - Have a file downloaded from the SRI. - Go to Accounting > Vendor > Bills - Click "Upload" and select the file - The generated move is not populated with the data ### Cause: We are expecting the XML to not be in the tag `CDATA` and it gets ignored. ### Solution: The change is in `_get_import_file_type` to detect the new type of file as `'l10n_ec.factura'`. The CDATA content can be fetched by getting the content of the tag `comprobante`. We then try to convert the content of `comprobante` to XML. If it's possible, we have an XML on which we can do the same check as before to know if it's an Ecuadorian invoice. We then replace the `file_data['xml_tree']` by the content of `CDATA` to have the correct XML for the data extraction. opw-5004636 Forward-Port-Of: odoo/enterprise#94184
This fix makes selecting and clicking icon-based website snippets behave more predictably. It prevents unwanted text highlighting, toolbar behavior, and editing errors around social media, sharing, and rating snippets, helping website editors avoid confusing interactions.
Original PR description
task-5066301
This update fixes urgent issues in subcontracting workflows, especially around purchase receipts, production orders, serial or lot generation, and subcontractor resupply. It helps prevent duplicate or incorrect resupply transfers, ghost manufacturing orders, and confusing subcontracting screens, making fulfillment more reliable for businesses using subcontracted manufacturing.
Original PR description
This PR fixes some urgent bugs in the new subcontracting introduced in [1]. Please refer to the individual commits for details. [1] https://github.com/odoo/odoo/pull/218377 task-5072277 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Vendor bill and expense sheet PDF reports can now include attachments stored as remote links or in cloud storage. This prevents report generation failures and helps users reliably print reports regardless of where supporting documents are stored.
Original PR description
### Issue PDF reports fail when attachments are remote URLs or cloud storage resources. The `to_pdf_stream()` method expects local file data but receives boolean values from remote attachments,…
### Issue PDF reports fail when attachments are remote URLs or cloud storage resources. The `to_pdf_stream()` method expects local file data but receives boolean values from remote attachments, causing a TypeError. ### Solution Download remote resources before processing them in PDF reports. This ensures all attachments have accessible data regardless of storage type. ### Affected Reports - `account.report_original_vendor_bill` - Vendor bill reports - `hr_expense.report_expense_sheet` - Expense sheet reports ### Affected Versions - 18.0+ (17.0 theoretical; cloud_storage wasn't implemented, so doesn't make sense) ### Reproduction Steps #### Option A: HR Expense Report 1. Create HR expense record 2. Add attachment with type=url/cloud_storage pointing to valid PDF URL 3. Link attachment to hr.expense record 4. Generate expense report → TypeError occurs #### Option B: Vendor Bill Report 1. Create vendor bill (account.move) 2. Add attachment with type=url/cloud_storage pointing to valid PDF URL 3. Link attachment to account.move record 4. Print Original Vendor Bill → TypeError occurs ### Error Details ```python TypeError: a bytes-like object is required, not 'bool' at /odoo/tools/pdf/__init__.py:220 in to_pdf_stream from /odoo/addons/hr_expense/models/ir_actions_report.py:29 ``` #### Reference Client demo: https://drive.google.com/file/d/1HUvZqZ21NiX34T2IQhuVNbLP41xSV7jq/view OPW-5036638 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227571 Forward-Port-Of: odoo/odoo#226094
Follow-up PDF reports now work when attached files are stored as remote links or in cloud storage. This prevents report failures and helps users reliably generate customer follow-up documents regardless of where attachments are stored.
Original PR description
### Issue PDF reports fail when attachments are remote URLs or cloud storage resources. The to_pdf_stream() method expects local file data but receives boolean values from remote attachments, causing a TypeError. ### Solution Download remote resources before processing them in PDF reports. This ensures all attachments have accessible data regardless of storage type. ### Affected Reports (enterprise): - account_followup.report_followup_print_all [Community PR](https://github.com/odoo/odoo/pull/226094) OPW-5036638 Forward-Port-Of: odoo/enterprise#94975 Forward-Port-Of: odoo/enterprise#94477
This fixes an issue where already-used serial numbers could reappear when adding delivery lines after deleting suggested lines. Warehouse users will now see the correct available serial numbers, reducing picking mistakes and inventory inconsistencies.
Original PR description
Steps to reproduce the bug: Create a storable product “P” tracked by serial number Create a receipt for 100 units with serial numbers sn.001 to sn.100 Create a delivery for 10 units, Odoo assigns serial numbers from sn.001 to sn.010, Validate Create a delivery for 3 units, Odoo assigns serial numbers from sn.011 to sn.013, Delete the 3 move lines, Add a line: you will see again the serial numbers sn.001 to sn.010 in the list Origin: This pr : https://github.com/odoo/odoo/pull/216035 removed the 'on_hand' & 'in_stock' without removing their uses (search_default_*) Fix: Ensure a correct domain when adding a line. opw-5075144 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where previously used serial numbers could reappear when adding delivery lines after deleting automatically assigned lines. This helps warehouse users select only valid available stock, reducing picking mistakes and inventory inconsistencies.
Original PR description
Steps to reproduce the bug: Create a storable product “P” tracked by serial number Create a receipt for 100 units with serial numbers sn.001 to sn.100 Create a delivery for 10 units, Odoo assigns serial numbers from sn.001 to sn.010, Validate Create a delivery for 3 units, Odoo assigns serial numbers from sn.011 to sn.013, Delete the 3 move lines, Add a line: you will see again the serial numbers sn.001 to sn.010 in the list Origin: This pr : https://github.com/odoo/odoo/pull/216035 removed the 'on_hand' & 'in_stock' without removing their uses (search_default_*) Fix: Ensure a correct domain when adding a line. opw-5075144
This change prevents rental service products sold through POS from incorrectly resetting delivered quantities when no stock movement exists. It avoids blocking order settlement or returns in cases where salespeople manage service delivery manually, improving reliability for rental workflows.
Original PR description
With [^1], a new constraint was introduced on sale order lines in rental
to ensure the returned quantity does not exceed the delivered quantity.
While this constraint is logical, it uncovered a bug in the integration
between rental, POS, and stock. Specifically, when a POS order is
settled, the `pos.order.sync_from_ui` method reconciles the models.
If the rented product is a service, no picking is created, which means
no stock move, resetting the delivered quantity to zero. This triggers a
constraint violation if a returned quantity already exists (e.g., 0 >=
positive).
This commit applies the following fixes:
- If the SOL product is a service, we do not update its delivered
quantity as it is managed manually by the salesperson on the SOL
directly.
- Additionally, we remove the constraint to allow more flexibility.
opw-5076638
[^1]: https://github.com/odoo/enterprise/pull/88689
[^2]: https://github.com/odoo/enterprise/pull/90510This update resolves several user-facing issues across accounting, inventory, manufacturing, point of sale, email, calendar, website editing, and Saudi e-invoicing. It improves reliability by preventing errors, correcting financial calculations, preserving saved data, and making reports and interface actions behave as expected.
Original PR description
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
Bank reconciliation can now match common sales order references such as SO0001, which were previously ignored because they were too short. This helps payments link to the right documents more reliably and reduces manual reconciliation work.
Original PR description
Matching on references was limited to matching words > 8, to increase reliability, but the default sequence for sale orders is 6 characters (SO0001), so they would never be found unless we reach SO1000000 -_- Forward-Port-Of: odoo/enterprise#94717 Forward-Port-Of: odoo/enterprise#93640
This update fixes how purchase requests, sales-linked purchases, manufacturing, and stock reception reports handle planned dates, deadlines, and document links. It helps teams avoid duplicate purchase lines, keep supplier deadlines accurate, and access related business documents correctly from reception reports.
Original PR description
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
Fixed an issue where adding products to an empty online cart could push the cart summary to the bottom of the page instead of keeping it beside the cart. This improves the shopping experience by ensuring the cart layout updates correctly when items are added, including through quick reorder.
Original PR description
When the cart was previously empty, adding products (e.g., via the quick reorder feature) caused the cart summary to display incorrectly at the bottom of the page. This happened because the left column's default width spans the entire screen when the cart is empty, and adding products did not update the column widths. As a result, the left column retained a full width which left no space for the cart summary on the right. This commit resolves the issue by ensuring the cart columns are updated dynamically when the cart content changes.
This fixes an Accounting issue where confirming a customer invoice could fail if the journal used European payment references and included non-alphanumeric characters in its code. The change validates the journal code before generating the payment reference, preventing invoice confirmation errors for affected configurations.
Original PR description
Currently, an error occurs when confirming a customer invoice that uses a journal with an invalid configuration. **Steps to Reproduce:** 1) Install Accounting app.(with Demo) 2) Navigate to…
Currently, an error occurs when confirming a customer invoice that uses a journal with an invalid configuration. **Steps to Reproduce:** 1) Install Accounting app.(with Demo) 2) Navigate to Accounting>Configuration>Journals 3) Open existing 'Sales' journal and make following changes: - set Sequence Prefix: INV- - In the Advanced Settings Page, set 'Communication Standard' as 'European' and save the journal. 4) Create a Customer Invoice with this Sales Journal and click on `Confirm`. **Error :** `ValueError: invalid literal for int() with base 36: '-'` **Root Cause:** Since [this commit](https://github.com/odoo/odoo/pull/212169/commits/e4a09467a20f282d28baa09091c10a6aea6d0094#diff-cc13d9842e166c12738b659e0478ceb8b1b15734442c1e090252919e7efb6ed7), On following above steps, The value of 'number' received at [1] looks like 'INV-000003' due to which on further computation of this value at [1] causing an error. **Fix:** prevent crash by adding a additional check on methods `_get_invoice_reference_euro_invoice` and `_get_invoice_reference_euro_partner` to validate the journal's short code. [1]- https://github.com/odoo/odoo/blob/2646790e7e31b4c600e39f2d5c87f0744b1578b0/addons/account/tools/structured_reference.py#L20-L26 **sentry-6860586611** Forward-Port-Of: odoo/odoo#227557 Forward-Port-Of: odoo/odoo#225987
Creating a project from a template with subtasks now assigns people to the correct tasks based on the configured roles. This prevents users from being placed on the wrong child tasks and keeps new project data consistent.
Original PR description
Before this commit, when we created a project from a template with task with subtask, the mapping of the role/user was not correctly applied. This lead to inconsistent data at the project creation such as setting users on the child tasks randomly instead of correctly setting it on the parent task Source of the issue: We wrongly assumed that the task order of the project copied was the same as the original project and thus used the original project task's list in order to set the user on the copied tasks. Solution: Keep the role_ids on the copied tasks and use that data to set the correct user using the wizard mapping. The role_ids are set to False once the data are correctly set. task-5094321 Forward-Port-Of: odoo/odoo#227654
Customers who paid an invoice or order can now update their billing address when no country was previously set. This prevents checkout or portal account issues where the country field was incorrectly locked, reducing support friction and failed address updates.
Original PR description
After paying an invoice or sale order, a customer without a billing country cannot update the country in their billing address because the form is disabled by the portal's country edition rule. **Steps to reproduce:** 1. Create a customer without a billing country. 2. Generate an invoice or sale order for that customer. 3. Pay the invoice/order (possible with some payment providers). 4. Go to the customer portal and try to update the billing address. The country field is disabled, preventing the customer from setting their country. This fix ensures that if the partner has no country set, the field remains editable even when normal country edition restrictions apply. This issue also affects the `website_sale` module, specifically the checkout process, where the country field may be blocked if not handled properly. Forward-Port-Of: odoo/odoo#227353
This fix prevents an error when a customer has open carts on multiple eCommerce websites and their address change triggers tax or fiscal position updates. Loyalty rewards are now recalculated separately for each cart, keeping checkout available and stable.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have 2 eCommerce sites; 2. have a user with an open cart in both sites; 3. have a reward applied in one or both of carts; 4. have a fiscal position applicable…
Versions -------- - 16.0+ Steps ----- 1. Have 2 eCommerce sites; 2. have a user with an open cart in both sites; 3. have a reward applied in one or both of carts; 4. have a fiscal position applicable to the user's address; 5. change the user's country to one with a different fiscal position. Issue ----- > ValueError: Expected singleton: sale.order(1, 2) Cause ----- As of commit ede8846987a98, fiscal positions get recomputed on address changes. When a fiscal position changes, the `_recompute_prices` method gets called on all open carts. This method does not include an `ensure_one` check, so it should be able to handle multiple sales orders. However, the `sale_loyalty` override will call `_update_programs_and_rewards` on `self` if any reward line is encountered. This method does have an `ensure_one` check, leading to the error. Solution -------- Rewrite the override as a loop, so it can handle multiple records in `self`. opw-5017669 Forward-Port-Of: odoo/odoo#224225
This fix prevents certain API request parameters from being confused with reserved fields used to route calls. It helps ensure integrations and automated requests work reliably when they use parameter names that overlap with internal request handling.
Original PR description
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
Purchase order lines no longer allow users to create new units of measure directly from the line entry field. This prevents deleted or incomplete units from causing purchase order confirmation failures, making the purchasing workflow more reliable.
Original PR description
When users create a new UoM from order lines, and after deleting the newly created UoM, they try to confirm the order. Steps to reproduce: --- - Install `purchase_stock` module - Create a New PO - Add an order line -> Remove its `Unit` and create a New one - Delete newly created UoM from `Units & Packagings` - Now Confirm Order Traceback: --- - `ValueError: Expected singleton: uom.uom()` - `ZeroDivisionError: float division by zero` This error occurs because, after deleting the newly created UoM, the `product_uom_id` becomes empty, which leads to errors in multiple lines. Solution: --- We are restricting users from creating a UoM from purchase order lines, as already done in other modules (e.g., stock, account, …). sentry-6746792383, 6853969554 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225475
5 changes
Enhancements to existing features
Accounting KPI summaries now include posted bank journal entries linked to unreconciled bank statements. This gives businesses a more accurate view of pending bank activity and improves confidence in financial reporting metrics.
Original PR description
### [REF] account: reorganize kpi.provider tests The account test_kpi_provider was already getting complicated, and this commit aims to simplify it by breaking it into smaller tests that show more clearly what is expected. Task-id: 5062431 ### [IMP] account: make kpi.provider report unreconciled bank statements The `kpi.provider:get_account_kpi_summary` method should include posted moves of a bank journal that are related to an unreconciled bank statement. Task-id: 5062431 Forward-Port-Of: odoo/odoo#227661 Forward-Port-Of: odoo/odoo#227605
Resolved issues and error corrections
Payroll users with Administrator access can now cancel completed payslips as intended. This removes an incorrect permission check that blocked authorized payroll staff and interrupted normal payroll corrections.
Original PR description
steps to reproduce: ------------------- 1. Install payroll 2. Create a user and grant "Administrator" access to Payroll. 3. Log in as the new user and try to cancel a 'Done' payslip. issue: ------ A UserError is raised: "Cannot cancel a payslip that is done." observation: ------------ A user with Payroll "Administrator" access is unable to cancel a payroll payslip cause of the issue: ------------------- During cancellation, the system checks whether the user is "Admin" instead of verifying if the user has Payroll "Administrator" access. https://github.com/odoo/enterprise/blob/13832d80570956e504e1c09f41acbeb0bc4baedc/hr_payroll/models/hr_payslip.py#L509-L513 solution: ---------- Check that the user has Payroll "Administrator" access. opw-5040029 Forward-Port-Of: odoo/enterprise#93831
This update prevents an error that could occur when a customer has open carts on multiple eCommerce sites and changes their address. Loyalty rewards and cart pricing are now recalculated safely across multiple carts, helping customers continue checkout without interruption.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have 2 eCommerce sites; 2. have a user with an open cart in both sites; 3. have a reward applied in one or both of carts; 4. have a fiscal position applicable…
Versions -------- - 16.0+ Steps ----- 1. Have 2 eCommerce sites; 2. have a user with an open cart in both sites; 3. have a reward applied in one or both of carts; 4. have a fiscal position applicable to the user's address; 5. change the user's country to one with a different fiscal position. Issue ----- > ValueError: Expected singleton: sale.order(1, 2) Cause ----- As of commit ede8846987a98, fiscal positions get recomputed on address changes. When a fiscal position changes, the `_recompute_prices` method gets called on all open carts. This method does not include an `ensure_one` check, so it should be able to handle multiple sales orders. However, the `sale_loyalty` override will call `_update_programs_and_rewards` on `self` if any reward line is encountered. This method does have an `ensure_one` check, leading to the error. Solution -------- Rewrite the override as a loop, so it can handle multiple records in `self`. opw-5017669 Forward-Port-Of: odoo/odoo#224225
Purchase entries in India's GSTR-3B report now include credit notes, receipts, and other relevant purchase records so totals are accurate. Purchase-related lines were also removed from the POS-specific report area because point-of-sale activity is not related to purchase records, reducing incorrect reporting.
Original PR description
Currently, purchase entries are not displaying the correct data because the credit notes and receipts were not included. This PR removes purchase-related data from `l10n_in_reports_gstr_pos` (as POS has no relation to purchase records) and ensures that credit note data and other purchase records are properly displayed in the GSTR-3B report. **opw**-5079401 Forward-Port-Of: odoo/enterprise#95027 Forward-Port-Of: odoo/enterprise#94582
This fix ensures Odoo VoIP sends the correct connection information when using secure web calling. As a result, users can reliably receive incoming calls in setups that use secure WSS connections.
Original PR description
### Before this PR Using voip with WSS, it can't receive calls because the current transport is not sent to the PBX. ### After this PR: The right transport is sent
2 changes
Resolved issues and error corrections
The GSTR-3B report now includes purchase credit notes, receipts, and other purchase records so reported values are accurate. Purchase-related report data was also removed from the POS reporting area because POS does not handle purchase records, reducing the risk of misleading tax figures.
Original PR description
Currently, purchase entries are not displaying the correct data because the credit notes and receipts were not included. This PR removes purchase-related data from `l10n_in_reports_gstr_pos` (as POS has no relation to purchase records) and ensures that credit note data and other purchase records are properly displayed in the GSTR-3B report. **opw**-5079401 Forward-Port-Of: odoo/enterprise#94582
This fixes a crash that could occur when a customer had open carts on multiple eCommerce sites and changed their address. Loyalty rewards are now recalculated separately for each cart, keeping checkout flows stable when tax or fiscal rules change.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have 2 eCommerce sites; 2. have a user with an open cart in both sites; 3. have a reward applied in one or both of carts; 4. have a fiscal position applicable…
Versions -------- - 16.0+ Steps ----- 1. Have 2 eCommerce sites; 2. have a user with an open cart in both sites; 3. have a reward applied in one or both of carts; 4. have a fiscal position applicable to the user's address; 5. change the user's country to one with a different fiscal position. Issue ----- > ValueError: Expected singleton: sale.order(1, 2) Cause ----- As of commit ede8846987a98, fiscal positions get recomputed on address changes. When a fiscal position changes, the `_recompute_prices` method gets called on all open carts. This method does not include an `ensure_one` check, so it should be able to handle multiple sales orders. However, the `sale_loyalty` override will call `_update_programs_and_rewards` on `self` if any reward line is encountered. This method does have an `ensure_one` check, leading to the error. Solution -------- Rewrite the override as a loop, so it can handle multiple records in `self`. opw-5017669 Forward-Port-Of: odoo/odoo#224225