Daily updates from Odoo
Navigate
Branch
Sunday, March 1, 2026
14 changes
4 changes
Resolved issues and error corrections
This update fixes an issue where manually invoiced upsells weren't correctly marked as 'Fully Invoiced'. The change ensures that upsells, when invoiced based on delivered quantities, are accurately reflected with the 'Fully Invoiced' status, improving invoicing accuracy and streamlining subscription management.
Original PR description
## Issue When manually invoicing a subscription or an upsell, its *Invoice Status* would not be updated to *Fully Invoiced* (`invoiced`), and would stay as *To invoice* (`to invoice`) instead. ##…
## Issue
When manually invoicing a subscription or an upsell, its *Invoice Status* would not be updated to *Fully Invoiced* (`invoiced`), and would stay as *To invoice* (`to invoice`) instead.
## Steps to reproduce
1. Install *Subscriptions* (`sale_subscription`)
2. Create a Product P
- *Subscriptions* checked
- *Invoicing Policy*: *Delivered quantities*
3. Create a Subscription S
- Any Customer
- Any plan
- Product P (any quantity)
4. Confirm the subscription S, set the amount delivered to the quantity ordered, then create and confirm the invoice
5. On the subscription S, click *Upsell*, add the product P to the upsell, and repeat step 4 on the upsell
6. **The upsell's _Invoice Status_ is still _To Invoice_, even though we invoiced it in the previous step**
## Causes
In the `SaleOrderLine._compute_invoice_status`, the following condition skips line from orders that are not considered to be "subscriptions":
https://github.com/odoo/enterprise/blob/c33e668bbba37c34d18af8c5371ab80eedf1b965/sale_subscription/models/sale_order_line.py#L51-L62
This is the case of upsells, as explained here:
https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L193-L201
---
Updating the above condition to take upsells in account is not enough. The condition to set the `invoice_status` to `invoiced` does not work as expected either.
https://github.com/odoo/enterprise/blob/5f4bb0ca22d068247540a4dcae88905c7b312f3c/sale_subscription/models/sale_order_line.py#L77-L78
In fact, when invoicing the subscription/upsell manually, there are multiple cases where the `last_invoiced_date` will be after `today`, and the subscription will be invoiced, so its status should be `invoiced`.
| Upsell | Invoiced based on delivered quantities | last_invoiced_date |
|--------|----------------------------------------|-------------------------|
| True | True | today + 1 month |
| False | True | today |
| True | False | today + 1 month - 1 day |
| False | False | today + 1 month - 1 day |
An alternative logic is to consider the subscription to be invoiced as long as the `next_invoice_date` is not reached.
---
opw-5500585
Forward-Port-Of: odoo/enterprise#108967
Forward-Port-Of: odoo/enterprise#107967This update corrects a bug where a previously revoked portal user could incorrectly become the default public user for a new website. The fix ensures that revoked users retain their previous group assignments, preventing unintended public user behavior and addressing a potential confidentiality risk. This improves data security and consistency within the Odoo platform.
Original PR description
**Steps to reproduce:** - Go to a Contact - Go to the actions dropdown menu of the record - Grant Portal Access - Revoke that Access - Create a new Website in the same Company that Portal Access was…
**Steps to reproduce:**
- Go to a Contact
- Go to the actions dropdown menu of the record
- Grant Portal Access
- Revoke that Access
- Create a new Website in the same Company that Portal Access was granted
- That Contact's user will be set as the Public User for the new Website
- New orders and other default public user behavior will be assigned to this user
- The user will be mentionned in non-logged interactions
**Issue:**
Archived portal user are set as public user when revoked, and the default public user of a website is set on create to the first public user it finds in `_get_public_user`:
```
public_users = self.env.ref('base.group_public').sudo().with_context(active_test=False).users
public_users_for_company = public_users.filtered(lambda user: user.company_id == self)
if public_users_for_company:
return public_users_for_company[0]
```
This seems to be an issue as such user can be reactivated or be assigned to some transactions it has not made (confidentiality issue).
**Fix:**
Not sure of the best way to fix this. We could ensure new website always creates a new public user, or find a better way to use by default the `self.env.ref('base.public_user')` (or its company-specific copies) for the company of the website during creation (or in `_get_public_user`).
For now the fix archive the revoked portal user (keeping its previous non-public groups), to still be able to reactivate it later on, without mistaking it for the default public user of a company.
Also we can't remove the `with_context(active_test=False)` as default public user always seems to be disabled.
related: https://github.com/odoo/odoo/commit/83e22fd0636748c4fe1058fb93adfad2623fc31b
*Reapply the reverted fix properly to avoid template issues and blocking flows (https://github.com/odoo/odoo/pull/239477 and https://github.com/odoo/odoo/pull/236462)*
opw-4760550
Forward-Port-Of: odoo/odoo#250505
Forward-Port-Of: odoo/odoo#243056This update fixes a visual inconsistency in the Activity view by ensuring that resource avatars are displayed with the same formatting as in the Kanban view. This improves the user experience and makes the Activity view more visually aligned with other parts of the Odoo system. It's a minor fix that enhances clarity and consistency.
Original PR description
This commit adds `activity.many2many_avatar_resource` in the registry to be able to have the same render than kanban view in the activity view. task-5921961 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes issues related to the integration of Field Service with the Planning app, specifically addressing formatting of time fields and access controls. Key changes include reintroducing geolocation services and adding new views for enhanced planning management.
Original PR description
This commit improves the new field service integration and fixes some mistakes made during the merge of Field Service app inside Planning app. In this commit, - the new format duration has been used…
This commit improves the new field service integration and fixes some mistakes made during the merge of Field Service app inside Planning app. In this commit, - the new format duration has been used for allocated hours and break time fields in planning, - some planning.slot fields are hidden in the form view when field service integration is enabled to reduce the number of fields inside that view since those fields were more useful for a planning manager to prepare the intervention of his workers, - some access right errors are fixed, - the planning user can no longer edit access once field, service integration is disabled, - field service geolocation service has been re-introduced since it was removed when the timer in timesheets has been reviewed, - some terms are now correctly translated, - `planning_field_service` module is flagged as an application, - `Products` menu item has been added in planning field service, - map and activity views has been been added in all planning menu items when field service is enabled. task-5921961 Co-authored-by: Maxime de Neuville (mane) <mane@odoo.com>
2 changes
Resolved issues and error corrections
This update fixes an issue where manually invoicing subscriptions or upsells didn't always update their invoice status to 'Fully Invoiced'. The change ensures that invoices are correctly processed, regardless of whether they're a subscription or an upsell, leading to accurate financial reporting.
Original PR description
## Issue When manually invoicing a subscription or an upsell, its *Invoice Status* would not be updated to *Fully Invoiced* (`invoiced`), and would stay as *To invoice* (`to invoice`) instead. ##…
## Issue
When manually invoicing a subscription or an upsell, its *Invoice Status* would not be updated to *Fully Invoiced* (`invoiced`), and would stay as *To invoice* (`to invoice`) instead.
## Steps to reproduce
1. Install *Subscriptions* (`sale_subscription`)
2. Create a Product P
- *Subscriptions* checked
- *Invoicing Policy*: *Delivered quantities*
3. Create a Subscription S
- Any Customer
- Any plan
- Product P (any quantity)
4. Confirm the subscription S, set the amount delivered to the quantity ordered, then create and confirm the invoice
5. On the subscription S, click *Upsell*, add the product P to the upsell, and repeat step 4 on the upsell
6. **The upsell's _Invoice Status_ is still _To Invoice_, even though we invoiced it in the previous step**
## Causes
In the `SaleOrderLine._compute_invoice_status`, the following condition skips line from orders that are not considered to be "subscriptions":
https://github.com/odoo/enterprise/blob/c33e668bbba37c34d18af8c5371ab80eedf1b965/sale_subscription/models/sale_order_line.py#L51-L62
This is the case of upsells, as explained here:
https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L193-L201
---
Updating the above condition to take upsells in account is not enough. The condition to set the `invoice_status` to `invoiced` does not work as expected either.
https://github.com/odoo/enterprise/blob/5f4bb0ca22d068247540a4dcae88905c7b312f3c/sale_subscription/models/sale_order_line.py#L77-L78
In fact, when invoicing the subscription/upsell manually, there are multiple cases where the `last_invoiced_date` will be after `today`, and the subscription will be invoiced, so its status should be `invoiced`.
| Upsell | Invoiced based on delivered quantities | last_invoiced_date |
|--------|----------------------------------------|-------------------------|
| True | True | today + 1 month |
| False | True | today |
| True | False | today + 1 month - 1 day |
| False | False | today + 1 month - 1 day |
An alternative logic is to consider the subscription to be invoiced as long as the `next_invoice_date` is not reached.
---
opw-5500585
Forward-Port-Of: odoo/enterprise#108967
Forward-Port-Of: odoo/enterprise#107967This update corrects a bug where a previously revoked portal user could be incorrectly designated as the default public user for a new website. This prevented potential confidentiality issues and incorrect order assignments. The fix ensures revoked users are archived, maintaining their access for reactivation without impacting website functionality.
Original PR description
**Steps to reproduce:** - Go to a Contact - Go to the actions dropdown menu of the record - Grant Portal Access - Revoke that Access - Create a new Website in the same Company that Portal Access was…
**Steps to reproduce:**
- Go to a Contact
- Go to the actions dropdown menu of the record
- Grant Portal Access
- Revoke that Access
- Create a new Website in the same Company that Portal Access was granted
- That Contact's user will be set as the Public User for the new Website
- New orders and other default public user behavior will be assigned to this user
- The user will be mentionned in non-logged interactions
**Issue:**
Archived portal user are set as public user when revoked, and the default public user of a website is set on create to the first public user it finds in `_get_public_user`:
```
public_users = self.env.ref('base.group_public').sudo().with_context(active_test=False).users
public_users_for_company = public_users.filtered(lambda user: user.company_id == self)
if public_users_for_company:
return public_users_for_company[0]
```
This seems to be an issue as such user can be reactivated or be assigned to some transactions it has not made (confidentiality issue).
**Fix:**
Not sure of the best way to fix this. We could ensure new website always creates a new public user, or find a better way to use by default the `self.env.ref('base.public_user')` (or its company-specific copies) for the company of the website during creation (or in `_get_public_user`).
For now the fix archive the revoked portal user (keeping its previous non-public groups), to still be able to reactivate it later on, without mistaking it for the default public user of a company.
Also we can't remove the `with_context(active_test=False)` as default public user always seems to be disabled.
related: https://github.com/odoo/odoo/commit/83e22fd0636748c4fe1058fb93adfad2623fc31b
*Reapply the reverted fix properly to avoid template issues and blocking flows (https://github.com/odoo/odoo/pull/239477 and https://github.com/odoo/odoo/pull/236462)*
opw-4760550
Forward-Port-Of: odoo/odoo#250505
Forward-Port-Of: odoo/odoo#2430563 changes
Resolved issues and error corrections
This update fixes an issue where manually invoicing subscription upsells didn't correctly update their invoice status. The change ensures that upsells are properly marked as 'Fully Invoiced' after invoicing, resolving a discrepancy in the system's tracking of payment status. This improves the accuracy of subscription billing.
Original PR description
## Issue When manually invoicing a subscription or an upsell, its *Invoice Status* would not be updated to *Fully Invoiced* (`invoiced`), and would stay as *To invoice* (`to invoice`) instead. ##…
## Issue
When manually invoicing a subscription or an upsell, its *Invoice Status* would not be updated to *Fully Invoiced* (`invoiced`), and would stay as *To invoice* (`to invoice`) instead.
## Steps to reproduce
1. Install *Subscriptions* (`sale_subscription`)
2. Create a Product P
- *Subscriptions* checked
- *Invoicing Policy*: *Delivered quantities*
3. Create a Subscription S
- Any Customer
- Any plan
- Product P (any quantity)
4. Confirm the subscription S, set the amount delivered to the quantity ordered, then create and confirm the invoice
5. On the subscription S, click *Upsell*, add the product P to the upsell, and repeat step 4 on the upsell
6. **The upsell's _Invoice Status_ is still _To Invoice_, even though we invoiced it in the previous step**
## Causes
In the `SaleOrderLine._compute_invoice_status`, the following condition skips line from orders that are not considered to be "subscriptions":
https://github.com/odoo/enterprise/blob/c33e668bbba37c34d18af8c5371ab80eedf1b965/sale_subscription/models/sale_order_line.py#L51-L62
This is the case of upsells, as explained here:
https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L193-L201
---
Updating the above condition to take upsells in account is not enough. The condition to set the `invoice_status` to `invoiced` does not work as expected either.
https://github.com/odoo/enterprise/blob/5f4bb0ca22d068247540a4dcae88905c7b312f3c/sale_subscription/models/sale_order_line.py#L77-L78
In fact, when invoicing the subscription/upsell manually, there are multiple cases where the `last_invoiced_date` will be after `today`, and the subscription will be invoiced, so its status should be `invoiced`.
| Upsell | Invoiced based on delivered quantities | last_invoiced_date |
|--------|----------------------------------------|-------------------------|
| True | True | today + 1 month |
| False | True | today |
| True | False | today + 1 month - 1 day |
| False | False | today + 1 month - 1 day |
An alternative logic is to consider the subscription to be invoiced as long as the `next_invoice_date` is not reached.
---
opw-5500585
Forward-Port-Of: odoo/enterprise#108614
Forward-Port-Of: odoo/enterprise#107967This update fixes an issue where users couldn't download attachments sent via mass emails (like event invitations). The fix ensures attachments are correctly linked to the related event record, granting the necessary access for download. This improves the user experience when receiving and managing event communications.
Original PR description
**Steps to reproduce:** - Install Event app - Log as a user with Events/Administrator rights - Ensure its Administration rights are not set to Settings - Go to an open Event - Add a new attendee with mail - Ticket is automatically sent, and logged in chatter - User doesn't have the rights to download the file from the chatter **Issue:** User has no 'read' access to `ir.attachment` due to a missing related record (res_model and res_id are set to "mail.message" and 0 instead of the `event.registration` record). It can be bypassed when the user also has system rights (or is the sender) and it works properly when sending manually the mail. **Fix:** Reapply the fix used in 19.0+. (We could also hide the attachment in chatter when it is not linked properly) related: https://github.com/odoo/odoo/commit/19c78b2585cec9473ad2d2ab9101235c45a03314 opw-5349820 Forward-Port-Of: odoo/odoo#250894 Forward-Port-Of: odoo/odoo#247346
This fix resolves an issue where a revoked portal user could inadvertently become the default public user for a new website. This prevented potential confidentiality risks and ensures proper order assignment. The update preserves the ability to reactivate the user while correcting the default public user assignment process.
Original PR description
**Steps to reproduce:** - Go to a Contact - Go to the actions dropdown menu of the record - Grant Portal Access - Revoke that Access - Create a new Website in the same Company that Portal Access was…
**Steps to reproduce:**
- Go to a Contact
- Go to the actions dropdown menu of the record
- Grant Portal Access
- Revoke that Access
- Create a new Website in the same Company that Portal Access was granted
- That Contact's user will be set as the Public User for the new Website
- New orders and other default public user behavior will be assigned to this user
- The user will be mentionned in non-logged interactions
**Issue:**
Archived portal user are set as public user when revoked, and the default public user of a website is set on create to the first public user it finds in `_get_public_user`:
```
public_users = self.env.ref('base.group_public').sudo().with_context(active_test=False).users
public_users_for_company = public_users.filtered(lambda user: user.company_id == self)
if public_users_for_company:
return public_users_for_company[0]
```
This seems to be an issue as such user can be reactivated or be assigned to some transactions it has not made (confidentiality issue).
**Fix:**
Not sure of the best way to fix this. We could ensure new website always creates a new public user, or find a better way to use by default the `self.env.ref('base.public_user')` (or its company-specific copies) for the company of the website during creation (or in `_get_public_user`).
For now the fix archive the revoked portal user (keeping its previous non-public groups), to still be able to reactivate it later on, without mistaking it for the default public user of a company.
Also we can't remove the `with_context(active_test=False)` as default public user always seems to be disabled.
related: https://github.com/odoo/odoo/commit/83e22fd0636748c4fe1058fb93adfad2623fc31b
*Reapply the reverted fix properly to avoid template issues and blocking flows (https://github.com/odoo/odoo/pull/239477 and https://github.com/odoo/odoo/pull/236462)*
opw-4760550
Forward-Port-Of: odoo/odoo#250505
Forward-Port-Of: odoo/odoo#2430561 change
Resolved issues and error corrections
This update ensures self-order transactions in the POS system now adhere to the same data validation rules as standard POS orders. This enhancement improves data accuracy and reliability, reducing potential errors and inconsistencies in self-service order processing.
Original PR description
This commit improves the data validation of pos self order by using the same validation as the one used for regular pos order. Forward-Port-Of: odoo/enterprise#108538
1 change
Resolved issues and error corrections
This update fixes an issue where manually invoiced subscriptions and upsells didn't correctly reflect their 'Fully Invoiced' status. The change ensures that invoices are properly marked as invoiced, regardless of whether they're based on delivered quantities or are added as upsells, improving invoicing accuracy.
Original PR description
## Issue When manually invoicing a subscription or an upsell, its *Invoice Status* would not be updated to *Fully Invoiced* (`invoiced`), and would stay as *To invoice* (`to invoice`) instead. ##…
## Issue
When manually invoicing a subscription or an upsell, its *Invoice Status* would not be updated to *Fully Invoiced* (`invoiced`), and would stay as *To invoice* (`to invoice`) instead.
## Steps to reproduce
1. Install *Subscriptions* (`sale_subscription`)
2. Create a Product P
- *Subscriptions* checked
- *Invoicing Policy*: *Delivered quantities*
3. Create a Subscription S
- Any Customer
- Any plan
- Product P (any quantity)
4. Confirm the subscription S, set the amount delivered to the quantity ordered, then create and confirm the invoice
5. On the subscription S, click *Upsell*, add the product P to the upsell, and repeat step 4 on the upsell
6. **The upsell's _Invoice Status_ is still _To Invoice_, even though we invoiced it in the previous step**
## Causes
In the `SaleOrderLine._compute_invoice_status`, the following condition skips line from orders that are not considered to be "subscriptions":
https://github.com/odoo/enterprise/blob/c33e668bbba37c34d18af8c5371ab80eedf1b965/sale_subscription/models/sale_order_line.py#L51-L62
This is the case of upsells, as explained here:
https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L193-L201
---
Updating the above condition to take upsells in account is not enough. The condition to set the `invoice_status` to `invoiced` does not work as expected either.
https://github.com/odoo/enterprise/blob/5f4bb0ca22d068247540a4dcae88905c7b312f3c/sale_subscription/models/sale_order_line.py#L77-L78
In fact, when invoicing the subscription/upsell manually, there are multiple cases where the `last_invoiced_date` will be after `today`, and the subscription will be invoiced, so its status should be `invoiced`.
| Upsell | Invoiced based on delivered quantities | last_invoiced_date |
|--------|----------------------------------------|-------------------------|
| True | True | today + 1 month |
| False | True | today |
| True | False | today + 1 month - 1 day |
| False | False | today + 1 month - 1 day |
An alternative logic is to consider the subscription to be invoiced as long as the `next_invoice_date` is not reached.
---
opw-5500585
Forward-Port-Of: odoo/enterprise#108967
Forward-Port-Of: odoo/enterprise#1079672 changes
Resolved issues and error corrections
This update corrects an issue where the IoT module couldn't properly access payment tokens. By retrieving tokens directly from the pos_self_order service, the system now functions more reliably for IoT-enabled point-of-sale transactions. This ensures accurate payment processing within the enterprise system.
Original PR description
Access token is not accessible from pos_config, it should be accessed from pos_self_order service directly.
This update fixes an issue where manually invoicing subscription upsells didn't correctly update their invoice status. Previously, upsells remained marked as 'To Invoice' even after invoicing. This change ensures upsells are accurately marked as 'Fully Invoiced' when invoices are created, streamlining the billing process for subscription customers.
Original PR description
## Issue When manually invoicing a subscription or an upsell, its *Invoice Status* would not be updated to *Fully Invoiced* (`invoiced`), and would stay as *To invoice* (`to invoice`) instead. ##…
## Issue
When manually invoicing a subscription or an upsell, its *Invoice Status* would not be updated to *Fully Invoiced* (`invoiced`), and would stay as *To invoice* (`to invoice`) instead.
## Steps to reproduce
1. Install *Subscriptions* (`sale_subscription`)
2. Create a Product P
- *Subscriptions* checked
- *Invoicing Policy*: *Delivered quantities*
3. Create a Subscription S
- Any Customer
- Any plan
- Product P (any quantity)
4. Confirm the subscription S, set the amount delivered to the quantity ordered, then create and confirm the invoice
5. On the subscription S, click *Upsell*, add the product P to the upsell, and repeat step 4 on the upsell
6. **The upsell's _Invoice Status_ is still _To Invoice_, even though we invoiced it in the previous step**
## Causes
In the `SaleOrderLine._compute_invoice_status`, the following condition skips line from orders that are not considered to be "subscriptions":
https://github.com/odoo/enterprise/blob/c33e668bbba37c34d18af8c5371ab80eedf1b965/sale_subscription/models/sale_order_line.py#L51-L62
This is the case of upsells, as explained here:
https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L193-L201
---
Updating the above condition to take upsells in account is not enough. The condition to set the `invoice_status` to `invoiced` does not work as expected either.
https://github.com/odoo/enterprise/blob/5f4bb0ca22d068247540a4dcae88905c7b312f3c/sale_subscription/models/sale_order_line.py#L77-L78
In fact, when invoicing the subscription/upsell manually, there are multiple cases where the `last_invoiced_date` will be after `today`, and the subscription will be invoiced, so its status should be `invoiced`.
| Upsell | Invoiced based on delivered quantities | last_invoiced_date |
|--------|----------------------------------------|-------------------------|
| True | True | today + 1 month |
| False | True | today |
| True | False | today + 1 month - 1 day |
| False | False | today + 1 month - 1 day |
An alternative logic is to consider the subscription to be invoiced as long as the `next_invoice_date` is not reached.
---
opw-5500585
Forward-Port-Of: odoo/enterprise#108967
Forward-Port-Of: odoo/enterprise#1079671 change
Resolved issues and error corrections
This update fixes an issue where backdated leave accruals were incorrectly deducting from current periods. The change ensures that backdated leave is now properly handled by the lost surplus buffer, preventing double penalties and maintaining accurate leave balances. This resolves a previous error impacting leave calculations.
Original PR description
Backdated leaves recorded after an accrual carryover reset should be absorbed by the lost surplus buffer instead of deducting from the new period's balance. opw-5870858