Odoo Changelog — 2025-09-08

Monday, September 8, 2025

24 changes

Branch: saas-18.4

8 changes

Bug Fixes(8)

Resolved issues and error corrections

Fix add to cart button

PR #225162

Coresaas-18.4html_builderwebsiteMEDIUM

This fixes an issue in the website builder where product variant options could appear at the wrong time when configuring an Add to Cart button. It makes the editor behavior more reliable for users building online shop pages.

Original PR description

### [FIX] html_builder: avoid recomputing item value equal to undefined

With initial [website builder refactor], state of `useGetItemValue` is
recomputed too often if it is equal to undefined. This commit fixes to
comparison to check if the key is in the map.

[website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2
task-4367641

### [FIX] html_builder: fix add to cart button options

With 4e25350bde07ca4267887aa612b538bac0b3c6eb, `useDomState` became
async, thus reading it in `getValue` in a dependency definition became
incorrect.

With this commit, `BuilderMany2One` uses only the synchronous part for
the dependency value computation

Steps to reproduce:
- Open website builder (with website_sale)
- Drop the inner snippet "Add to Cart Button"
- Choose a "Product" that has variants (for example "Conference Chair")
- Bug: the option for the variant is not shown
- Remove the choice
- Bug: the option for variant now appears

task-4367641

#website_builder#ecommerce#add_to_cart#product_variants

[FIX] account_edi_ubl_cii: prevent error when creating invoice for pos order

PR #223343

Coresaas-18.4account_edi_ubl_ciiMEDIUM

Creating an invoice from a Point of Sale order could fail when the product had no taxes and the customer used Singapore e-invoicing. The fix treats missing tax as zero, allowing the invoice to be created normally and avoiding disruption at checkout reconciliation.

Original PR description

Currently, an error occurs when a user creates the invoice for a POS order. Steps to Reproduce: - Install the `point_of_sale` module. - Start a `Point of Sale session`. - Go to `Products` > create a…

Currently, an error occurs when a user creates the invoice for a POS order.

Steps to Reproduce:

- Install the `point_of_sale` module.
- Start a `Point of Sale session`.
- Go to `Products` > create a product without `Sales Taxes and Purchase Taxes`, and in the `Point of Sale` tab, select your `POS session category`.
- Go to `Customers` > `create a customer` and In the `Invoicing tab` of the customer, select `Singapore BIS Billing 3.0 SG` in the `eInvoice format` field.
- Go to the Point of Sale session and validate an order with the newly created product.
- Go back from the session, open the newly created order in Orders and select the newly created customer in the Customer field, and click the `Invoice button`.

`AttributeError: 'NoneType' object has no attribute 'amount'`

This error occurs after [this commit](https://github.com/odoo/odoo/commit/840bd1832edcc7815b8df70ec52dca10ef978fae), When a user creates an invoice for a POS order, the system calculates the tax_category_code [1], and if the product does not have any type of tax, then an error occurs here [2].

This commit ensures that if the tax is not present, it treats the tax amount as 0 as in [3] and returns the tax_category_code safely.

[1]- https://github.com/odoo/odoo/blob/2627168eea8562477f600c97c42d443a072ddccc/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py#L432

[2]- https://github.com/odoo/odoo/blob/2627168eea8562477f600c97c42d443a072ddccc/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_sg.py#L23

[3]- https://github.com/odoo/odoo/blob/9ea122e605366d076a2d6798dce63f1011a579da/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py#L434-L435

sentry-6814145551

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#pos#invoicing#e-invoicing#singapore

[FIX] l10n_es_edi_verifactu: fix the regime key dropdown

PR #225770

Coresaas-18.4l10n_es_edi_verifactuMEDIUM

Fixes an issue where Spanish Veri*Factu invoice users could not select a required regime key because the dropdown appeared empty. The hidden supporting field is now included in the invoice view so the available choices are calculated correctly, helping users complete compliant invoices without manual workarounds.

Original PR description

### Issue:
The dropdown for the regime key doesn't show any value, even when it's supposed to.

### Steps to reproduce:
- Install "l10n_es_edi_verifactu" and switch to a Spanish company
- Create an invoice for a Spanish partner with the tax "21% G (Goods)" for example
- In the page "Veri*factu" the field "Veri*Factu Regime Key" has a dropdown but no values to choose from

### Cause:
This field uses the widget `dynamic_selection` which applies a filter on the possible values of the selection. This filter is simply the field `l10n_es_edi_verifactu_available_clave_regimens` which is computed from the list of possible values and the tax_ids on the invoice. As this field is computed and non stored but do not appear in the view, it is never recomputed, so the dropdown shows no values.

### Solution:
Add the field in the view, and make it invisible.

opw-5039271

Forward-Port-Of: odoo/odoo#225478

#VeriFactu#Spain#invoicing#dropdown

[FIX] sale_stock: show lots on inter-company invoices

PR #225692

Coresaas-18.4sale_stockMEDIUM

Invoices for sales between companies now correctly show the related lot and serial numbers when that setting is enabled. This ensures inter-company customers receive the same traceability information as other customers, improving invoice accuracy and compliance with tracking processes.

Original PR description

### Steps to reproduce: - In the settings enable: "show serial numbers/lot on invoice" - Create a product tracked by SN and put SN001 in stock - With company 1, create and confirm an SO for company 2…

### Steps to reproduce:

- In the settings enable: "show serial numbers/lot on invoice"
- Create a product tracked by SN and put SN001 in stock
- With company 1, create and confirm an SO for company 2 (`partner_id`)
- Validate the delivery (using SN001)
- Create and confirm the invoice associated to the SO.
- Print the delivery
#### > The lots and serial numbers are not displayed but they would be for any other customer type.

### Cause of the issue:

Since 17.2 (commit 08536d687880ca6d9ad5c37b639c0ad4c2599d74), the `location_dest_id` of a delivery for a inter-company partner is set to the `Inter-company transit` location:
https://github.com/odoo/odoo/blob/23e63f4394c72939286e00d54ffd5da98d034d24/addons/stock/data/stock_data.xml#L54-L60 However, the lots are only displayed on the invoice if the usage of either the location or destination of the move line is `customer`: https://github.com/odoo/odoo/blob/23e63f4394c72939286e00d54ffd5da98d034d24/addons/sale_stock/models/stock.py#L60-L64 which fails for the `Inter-company transit` which is a transit location.

opw-4962700
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#223455
Forward-Port-Of: odoo/odoo#222492

#invoicing#serial numbers#lots#inter-company#traceability

[FIX] base, test_orm: avoid non-stored fields in default Calendar view

PR #222636

Coresaas-18.4basetest_ormMEDIUM

Fixes an error that could prevent users from enabling the Calendar view in Studio for Employees. The system now avoids unsuitable date fields when automatically creating calendar views, improving reliability without changing user workflows.

Original PR description

**Steps to reproduce:** - Install `hr` and `web_studio` - Go to Employees → click Studio icon. - Click on Views → try to activate Calendar view. **Observation:** - You will get a traceback…

**Steps to reproduce:**
- Install `hr` and `web_studio`
- Go to Employees → click Studio icon.
- Click on Views → try to activate Calendar view.

**Observation:**
- You will get a traceback 
`ValueError: Cannot convert hr.version.date_end to SQL because it is not stored
`
**Issue:**
- Since saas-18.4, the `hr_version` model introduced `date_start` and `date_end` fields, which are non-stored computed fields.
https://github.com/odoo/odoo/blob/21f18b1a6fdbf1a01c3dda83acfa66addd01a759/addons/hr/models/hr_version.py#L139-L140
- These field names overlap with the default date field names (`date_start` and `date_end`) used when generating Calendar views. So, the Calendar view tried to use a non-stored field, and it caused the error.
https://github.com/odoo/odoo/blob/21f18b1a6fdbf1a01c3dda83acfa66addd01a759/odoo/addons/base/models/ir_ui_view.py#L2591-L2630

**Solution:**
- Add an extra check in `set_first_of` to ensure that only stored fields are considered when selecting the default date field for Calendar views.

opw-4967654


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#calendar#studio#employees#stability

[FIX] hr_fleet: adapt employee driver for multi company

PR #225754

Coresaas-18.4hr_fleetMEDIUM

This fix ensures that when the same contact is linked to employees in different companies, a vehicle is assigned to the employee from the vehicle's company. It prevents incorrect driver records in fleet vehicles and assignment logs for multi-company setups.

Original PR description

There is a bug when multiple employees from different companies are linked to the same contact. Steps to reproduce:
- Create two employees, in two different companies that relate to the same contact (partner)
- In one of the two companies, create a vehicle and assign it to the partner created
- The field driver_employee_id in the vehicle and assignation log will be assigned to one of the two employees, without taking care of the company of the car

To fix this, the domain should also contain the company of the car, and must match the company of the employee.

task-4978443

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#221154

#fleet#employees#multi-company#vehicle assignment

[FIX] pos_urban_piper: provider gets enable automatically

PR #93691

Enterprisesaas-18.4pos_urban_piperMEDIUM

Disabled Urban Piper delivery providers now remain disabled when a point of sale session is resumed. This prevents unwanted provider reactivation and avoids unnecessary update requests, helping staff continue selling with the correct delivery setup.

Original PR description

Steps to reproduce:
- Configure urban piper in pos.config
- Open Register
- You could see a notification that providers are online on your config
- Disable any one provider.
- Go to backend.
- Click Continue Selling

Issue:
- Despite disabling the provider, all providers get enabled as soon as we resume the pos.config

Cause:
- Not updating togglestate properly while going to the backend.
- Unnecessary api request when resuming session.

Fix:
- Not removing the toggleState from local storage as the user go to the backend
- When the user resumes the session, restrict api request for location update.
-  Remove dependency from local storage and handling all through backend only.

task- 4962969

Forward-Port-Of: odoo/enterprise#93119
Forward-Port-Of: odoo/enterprise#90987

#POS#Urban Piper#delivery providers#session resume

[FIX] data_cleaning: Fix Discard Button Issue Due to Many2one Field R…

PR #93606

Enterprisesaas-18.4data_cleaningMEDIUM

Fixed an issue in Data Cleaning where the discard button in deduplication could reload the page without removing the selected record. This restores the expected workflow for users managing duplicate records after a recent system change.

Original PR description

…efactor. Currently, the discard button is not working correctly when trying to discard a record in the deduplication feature. Steps to replicate: - Go to: Data Cleaning > Configuration >…

…efactor.

Currently, the discard button is not working correctly when trying to discard a record in the deduplication feature.

Steps to replicate:
- Go to: Data Cleaning > Configuration > Deduplication.
- Open any Deduplication Rules > Deduplicate > select any record or directly click on the discard button. (Make sure at least one record is available in list view.)
- Click `discard` on top left.

Issue:
`It will load the page but not discard the record.`

This is not work because of a recent [refactor](https://github.com/odoo/odoo/pull/205486) where the data of a `many2one` will be an object rather than an array. (task-[3547961](https://www.odoo.com/odoo/project/49/tasks/3547961))

The discard button in the deduplication feature was not working correctly after a recent refactor in Odoo SaaS version 18.4. Previously (in SaaS 18.3), the record.data.group_id many2one field was represented as an array. The discard logic was written to access the group ID as record.data.group_id.

After the refactor, the record.data.group_id field is now represented as an object. Thus, record.data.group_id became undefined, which made parseInt() return NaN. Because of this, the application failed to identify the correct group and records to discard, causing the discard action to silently fail and only reload the page without discarding any records.

`The issue is also occurring in the runbot.`

Summary:
This change ensures that the discard button correctly identifies the group and record IDs to discard records.

The lines that returns object is [this](https://github.com/odoo/odoo/blob/564348a5172ea98b38c903686c21d007d0e57b48/addons/web/static/src/model/relational_model/utils.js#L517-L523).

cause of code : https://github.com/odoo/enterprise/blob/7d020d73762a17386cae4b68c15a5d59a51fb480/data_cleaning/static/src/views/data_merge_list_view.js#L67

reference pr:- https://github.com/odoo/enterprise/pull/90157

**saas~18.4**
<img width="1914" height="564" alt="image" src="https://github.com/user-attachments/assets/d8079d6b-abad-4367-b9d5-9055ee4f8cfa" />

**saas~18.3**
<img width="1907" height="545" alt="image" src="https://github.com/user-attachments/assets/8add0c64-a6ce-40bd-9df9-ca5de5ab9ac8" />

OPW:- [5043092](https://www.odoo.com/odoo/project/70/tasks/5043092)
UPG:- [3116896](https://upgrade.odoo.com/odoo/upgrade.request/3116896)

#deduplication#discard#data cleaning

Branch: saas-18.3

11 changes

Bug Fixes(11)

Resolved issues and error corrections

[FIX] hr_holidays: avoid collision between similar TimeOffs

PR #225443

Coresaas-18.3hr_holidaysMEDIUM

This fixes an issue where overlapping time off requests with different public holiday settings could cause an error when a public holiday was edited or created. HR teams can now manage public holidays without disrupting approved leave records for employees sharing the same calendar.

Original PR description

When two timeoff (one with Ignore Public Holidays and the other without) have the same dates, if you modify a public holidays that happend during that time, it will trigger a traceback. Steps to…

When two timeoff (one with Ignore Public Holidays and the other without) have the same dates, if you modify a public holidays that happend during that time, it will trigger a traceback.

Steps to reproduce:
-------------------
* Marc demo and Abigail Peterson using the same calendar
* Create a "Paid time off" leave for marc demo: June 19 - June 20
* Create a "Extra time off" for abigail: same date
* Update Time off type "Extra Time Off" to "Ignore Public Holidays"
* Approve both leave request previously created
* Create public holidays on June 19 --> traceback

Observation:

When both time off have the same dates it will overide the value in the dictonary https://github.com/odoo/odoo/commit/0d846ecd1ec7ff5149d580d3494b1a4bab1e68d2#diff-38469def2f870bb866f971f57797dd7c21b6a95d52a8eae72f832f0eea2434f9R464 and when it will try to call the employe_id it will trigger the traceback https://github.com/odoo/odoo/commit/f72ac3a14d76d4fb53ec3a092d08afafe4c35888#diff-38469def2f870bb866f971f57797dd7c21b6a95d52a8eae72f832f0eea2434f9R561

Why the fix:
------------
Added a new key on work_days_data to avoid the collision of two similar timeoffs.

opw-4933820

Forward-Port-Of: odoo/odoo#221942

#time off#public holidays#leave management

[FIX] hr_holidays_attendance: fix infinite extra hours time off bug

PR #225623

Coresaas-18.3hr_holidays_attendanceMEDIUM

Fixed an issue where extra hours time off could be approved after refusal without reducing the available extra hours balance. This prevents employees from repeatedly using the same extra hours and keeps leave balances accurate.

Original PR description

Steps to reproduce:
- On the time off dashboard, create a new leave with the type "Extra hours"
- Click on the request again, refuse the request
- Click on the request, and now approve the time off -If you now try to create a new time off with the type "Extra hours", you'll notice that the duration of the previously "refused then approved" time off is not taken into account

Reason:
The action tied to the "Approve" button was wrongly named in the inherited hr_leave model of the hr_holidays_attendance module, which prevented the computation for the approval to be taken into account.

How it was fixed:
Correcting the name allowed the function to be called properly and the calculation is now performed correctly.

Task ID: 5051271

Forward-Port-Of: odoo/odoo#224992

#time off#extra hours#attendance#leave balance

[FIX] l10n_es_edi_verifactu: fix the regime key dropdown

PR #225750

Coresaas-18.3l10n_es_edi_verifactuMEDIUM

Spanish Veri*Factu invoices now correctly display the available regime key options in the dropdown. This prevents users from being blocked or confused when completing required invoice compliance details.

Original PR description

### Issue:
The dropdown for the regime key doesn't show any value, even when it's supposed to.

### Steps to reproduce:
- Install "l10n_es_edi_verifactu" and switch to a Spanish company
- Create an invoice for a Spanish partner with the tax "21% G (Goods)" for example
- In the page "Veri*factu" the field "Veri*Factu Regime Key" has a dropdown but no values to choose from

### Cause:
This field uses the widget `dynamic_selection` which applies a filter on the possible values of the selection. This filter is simply the field `l10n_es_edi_verifactu_available_clave_regimens` which is computed from the list of possible values and the tax_ids on the invoice. As this field is computed and non stored but do not appear in the view, it is never recomputed, so the dropdown shows no values.

### Solution:
Add the field in the view, and make it invisible.

opw-5039271

Forward-Port-Of: odoo/odoo#225478

#Spain#VeriFactu#invoicing#dropdown

[FIX] sale_stock: show lots on inter-company invoices

PR #225675

Coresaas-18.3sale_stockMEDIUM

Inter-company sales invoices now correctly show the related lot and serial numbers when that option is enabled. This prevents missing traceability details on invoices between companies, aligning them with invoices for regular customers.

Original PR description

### Steps to reproduce:

- In the settings enable: "show serial numbers/lot on invoice"
- Create a product tracked by SN and put SN001 in stock
- With company 1, create and confirm an SO for company 2 (`partner_id`)
- Validate the delivery (using SN001)
- Create and confirm the invoice associated to the SO.
- Print the delivery
#### > The lots and serial numbers are not displayed but they would be for any other customer type.

### Cause of the issue:

Since 17.2 (commit 08536d687880ca6d9ad5c37b639c0ad4c2599d74), the `location_dest_id` of a delivery for a inter-company partner is set to the `Inter-company transit` location:
https://github.com/odoo/odoo/blob/23e63f4394c72939286e00d54ffd5da98d034d24/addons/stock/data/stock_data.xml#L54-L60 However, the lots are only displayed on the invoice if the usage of either the location or destination of the move line is `customer`: https://github.com/odoo/odoo/blob/23e63f4394c72939286e00d54ffd5da98d034d24/addons/sale_stock/models/stock.py#L60-L64 which fails for the `Inter-company transit` which is a transit location.

opw-4962700
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#223455
Forward-Port-Of: odoo/odoo#222492

#invoicing#serial numbers#lots#inter-company#traceability

[FIX] hr_holidays: show correct working schedule on time off calendar view

PR #225838

Coresaas-18.3hr_holidaysMEDIUM

The Time Off calendar now shows the selected employee's working schedule instead of the schedule of the person viewing it. This prevents managers and HR users from seeing incorrect days off when reviewing another employee's time off calendar.

Original PR description

Steps to reproduce:
- In the Employee app, select an employee with a different working schedule than yours
- Click on the "Time Off" Smartbutton
- Switch from Kanban to Calendar view
- The displayed working schedule is yours and not the employee's (easier to see if you and the employee have different days off)

Reason:
The employee_id field in the context used by the Python method was null instead of an ID, which caused the Python method to default to not use the employee's working schedule but the working schedule of the user viewing it.

How it was fixed:
By using a different field already present in the context, the employee's ID is correctly retrieved and used to display the calendar.

Task ID: 4987732

#time off#calendar#employee schedule

[FIX] hr_fleet: adapt employee driver for multi company

PR #225731

Coresaas-18.3hr_fleetMEDIUM

This fix ensures that when a vehicle is assigned to a contact shared by employees in different companies, Odoo selects the employee from the same company as the vehicle. This prevents incorrect driver records and assignment logs in multi-company fleet setups.

Original PR description

There is a bug when multiple employees from different companies are linked to the same contact. Steps to reproduce:
- Create two employees, in two different companies that relate to the same contact (partner)
- In one of the two companies, create a vehicle and assign it to the partner created
- The field driver_employee_id in the vehicle and assignation log will be assigned to one of the two employees, without taking care of the company of the car

To fix this, the domain should also contain the company of the car, and must match the company of the employee.

task-4978443

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#221154

#fleet#multi-company#employee#driver assignment

[FIX] mrp_mps: close edit production popup when opening BOM form

PR #90424

Enterprisesaas-18.3mrp_mpsMEDIUM

When users open a Bill of Materials from the Master Production Schedule edit popup, the popup now closes automatically. This prevents a confusing leftover popup and avoids an error when users cancel it after navigating away.

Original PR description

Before this commit: ------------------------- Clicking the BOM field in the edit production schedule pop-up on the MPS page redirected the user to the BOM form view, but the pop-up remained open in…

Before this commit:
-------------------------
Clicking the BOM field in the edit production schedule pop-up on the MPS page
redirected the user to the BOM form view, but the pop-up remained open in the
background. If the user then clicked Cancel on the pop-up, it created a
traceback error.

Steps to reproduce:
-------------------------
1. Install 'mrp_mps' module.
2. Go to Planning → Master Production Schedule.
3. Click the pencil icon next to a product.
4. In the pop-up, click the BOM value to navigate to the BOM.
5. Notice that the pop-up stays open even after redirection, and closing the
   pop-up raises a traceback error.

Cause of the issue
-------------------------
When your onClose arrow function directly executes
this.reload(productionScheduleId) without curly braces, it immediately hands
over the outcome of that function call to the dialog system. Since this.reload
is an asynchronous operation with multiple sequential return values, its
immediate outcome may not be a final value.

After this commit:
-----------------------
The pop-up is automatically closed when navigating to the BOM form view from the
BOM field in the Edit Production Schedule popup, ensuring a cleaner and more
intuitive user experience.

Task Id: 4886331

#master production schedule#bill of materials#popup#user experience

[FIX] hr_appraisal: manager should be able to create appraisal

PR #87831

Enterprisesaas-18.3hr_appraisalMEDIUM

Managers can now create employee appraisals as expected. This removes a workflow blocker for performance review management and adds test coverage to help prevent the issue from returning.

Original PR description

fixed with https://github.com/odoo/enterprise/commit/d4b708d22c0c3768cbb50bd5a43e91db419ff277

added test to cover the use case

opw-4794641

#appraisals#managers#performance reviews

[FIX] pos_iot: devices status search read delay fix

PR #92685

Enterprisesaas-18.3pos_iotMEDIUM

Point of Sale now checks connected IoT device status less often, reducing unnecessary background activity. This helps improve performance for businesses with large product databases while keeping device monitoring available.

Original PR description

We currently check the status of the connected devices every 5s. This is used in only a short selection of the devices and the delay is unnecessarily short.
For databases with a lot of products this can unnecesarily slow down their PoS

This PR increases the loop until 60s
opw-5006302

Forward-Port-Of: odoo/enterprise#92615

#point-of-sale#iot#performance

[FIX] stock_barcode_mrp: scan kit and separate comp no backorder

PR #93947

Enterprisesaas-18.3stock_barcode_mrpMEDIUM

Fixed a barcode transfer issue where lot-tracked kit components could be combined with the same component listed separately. This prevents unnecessary backorders when warehouse staff scan and validate the correct quantities.

Original PR description

**Problem:** when the components of a kit are tracked by lot, and that a picking is made of the components of a kit (exploded from the kit) and separatly one of the components on its own: if we open…

**Problem:**
when the components of a kit are tracked by lot, and that a picking is made of the components of a kit (exploded from the kit) and separatly one of the components on its own: if we open the picking in barcode, the line of the component separated and line of the components of the kit are grouped, which leads to an unwanted backorder creation when validating

**Steps to reproduce:**
- create two products tracked by lot (comp A and comp B)
- set an on hand quantity for both
- create a storable product (final product) and create a BOM
- in the BOM add comp A and comp B
- create an internal transfer for 1 final product and 1 comp B
- click on "mark as todo"
- open this transfer in barcode, we see that the two lines from the comp B are grouped
- scan the source location, click on +1 and +2 button to fulfill the quantities and validate

**Current behavior:**
a backorder is created

**Expected behavior:**
no backorder should be created as we entered the right quantities of the picking

**Cause of the issue:**
the lines from comp B should not have been grouped in the barcode picking.
When doing the same scenario but with product not tracked those lines are not grouped

opw-4998766

Forward-Port-Of: odoo/enterprise#93759
Forward-Port-Of: odoo/enterprise#93262

#barcode#inventory#manufacturing#kits#backorders

[FIX] pos_urban_piper: provider gets enable automatically

PR #93680

Enterprisesaas-18.3pos_urban_piperMEDIUM

This fixes an issue where UrbanPiper delivery providers that staff disabled were automatically re-enabled after returning from the backend and continuing sales. Provider status is now preserved centrally, reducing unexpected changes and avoiding unnecessary update requests when resuming a POS session.

Original PR description

Steps to reproduce:
- Configure urban piper in pos.config
- Open Register
- You could see a notification that providers are online on your config
- Disable any one provider.
- Go to backend.
- Click Continue Selling

Issue:
- Despite disabling the provider, all providers get enabled as soon as we resume the pos.config

Cause:
- Not updating togglestate properly while going to the backend.
- Unnecessary api request when resuming session.

Fix:
- Not removing the toggleState from local storage as the user go to the backend
- When the user resumes the session, restrict api request for location update.
-  Remove dependency from local storage and handling all through backend only.

task- 4962969

Forward-Port-Of: odoo/enterprise#93119
Forward-Port-Of: odoo/enterprise#90987

#pos#urban-piper#delivery#provider-status

Branch: master

1 change

Bug Fixes(1)

Resolved issues and error corrections

[FIX] ai: conditional ai module installation

PR #93903

Enterprisemasteraiai_auto_installMEDIUM

The AI module will now only install automatically when the required database support is available. This avoids setup problems for Odoo installations on systems that do not have pgvector installed, reducing deployment friction.

Original PR description

Since https://github.com/odoo/enterprise/pull/93271, the ai module is auto_install.
This however introduce problems because most computers running odoo doesn't have
pgvector installed.

In this PR, we're now conditionally auto installing the ai module by introducing this
new module with the same dependency as the ai module.

#ai#installation#pgvector

Branch: 18.0

4 changes

Bug Fixes(4)

Resolved issues and error corrections

[FIX] account_edi_ubl_cii: fix error when sending partially paid credit note

PR #223527

Core18.0account_edi_ubl_ciiMEDIUM

This fixes an error that blocked users from sending partially paid credit notes through electronic invoicing. Businesses can now complete the credit note sending process without a traceback in affected localization flows.

Original PR description

When User sends the partially paid credit note, A traceback will appear.

Steps to reproduce the error:
- Install ``l10n_co_dian`` module with demo data and switch to CO Company
- Create a Credit note > Confirm > Register a partial payment > Send > Send

Traceback:
``ValueError: The following child node is not defined in the template: CreditNote/cac:PrepaidPayment``

https://github.com/odoo/odoo/blob/7136383f47f3f86bc803efaa3837f4879b211b11/addons/account_edi_ubl_cii/tools/ubl_21_credit_note.py#L26
Here, ``cac:PrepaidPayment`` node is missing in the CreditNote.
So, It will raise the above traceback when sending the credit note.

sentry-6814211355

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#credit-notes#electronic-invoicing#payments

[FIX] core: wrong filtered domain result for relation field

PR #225799

Core18.0coreMEDIUM

This change corrects how Odoo evaluates access rules when a linked record field is empty. It prevents valid records from being incorrectly blocked during creation or recalculation, improving reliability for company-based access rules.

Original PR description

* STEP TO REPRODUCE: * -Model B , have **m2o** field call **'a'** from Model A, **'a'** field is not required and is a compute store field -Model B have company rule **[('a.company_id', 'in',…

* STEP TO REPRODUCE: 
* -Model B , have **m2o** field call **'a'** from Model A, **'a'** field is not required and is a compute store field
-Model B have company rule **[('a.company_id', 'in', company_ids + [False])]**
-After create B record but without **'a'** field or trigger compute of 'a' field that make it become false, we will get access rule error because: **[('a.company_id', 'in', company_ids + [False])]** will transform into **[('a', 'any', [('company_id', 'in', company_ids + [False])])]** , but note that **'a'** field is empty during computation which make the result become wrong because we call filtered_domain again when **'comparator' == any**, the **'self'** in it is the relation value which is 'a' field (empty record so return self)

* SOLUTION: only when all relational value of self have value then we should use any comparator

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

#access rules#relations#company rules

[FIX] l10n_cl_edi_factoring: fix message_post syntax

PR #92035

Enterprise18.0l10n_cl_edi_factoringMEDIUM

This fix corrects an error in how factoring-related messages are posted and improves handling when Chilean tax authority responses are empty. When a response is invalid, the system now refreshes its authentication token, helping maintain a more reliable connection to SII.

Original PR description

Before the PR:
Besides The syntax of message_post was wrong, there are situations where the response from SII is empty.
After de PR:
Fixed syntax in message_post and clear the token if the response was empty. This improves de connection by getting a new authentication from SII (new token) whenever the response is not a valid one.

#Chile#factoring#SII#EDI#authentication

[FIX] sale_subscription: generate EDI documents only once

PR #93881

Enterprise18.0sale_subscriptionMEDIUM

This fix prevents subscription payments made through the portal from generating and sending the same EDI-signed invoice twice when automatic invoicing is enabled. Businesses using electronic invoicing localizations should see fewer duplicate documents and cleaner invoice processing.

Original PR description

Versions
--------
- 18.0+

Steps
-----
1. Use a localization that uses EDI-signed invoices;
2. enable `sale.automatic_invoice` via `ir.config_parameter`;
3. pay for a subscription via the portal.

Issue
-----
Invoice is generated twice.

Cause
-----
Commit 7c5fd63729c1 added automatic EDI invoice signing for subscriptions paid via portal. This assumed that the `sale.automatic_invoice` parameter remained unset. If this parameter is set, the invoice is already generated when post-processing a transaction in `sale`.

Solution
--------
Don't send invoices whose `is_move_sent` field is set to `True`.

Also, don't set `from_cron` to `True` on automatic payments, as this is only intended for moves that have `sending_data` filled by `account.move.send.batch.wizard`.

opw-4648189

#subscriptions#invoicing#EDI#portal payments