Thursday, September 18, 2025
30 changes · 19.0
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