Odoo Changelog — 2025-08-13

Wednesday, August 13, 2025

6 changes · master

Bug Fixes(6)

Resolved issues and error corrections

[FIX] sale_subscription: fix wrong next_invoice_date after resume

Enterprisemastersale_subscriptionMEDIUM

Subscriptions that were paused and manually invoiced now resume with the correct next billing date. This prevents businesses from skipping billing periods or invoicing against dates that were already handled manually.

Original PR description

Version:

- saas-18.4

Before:

- If a subscription was paused and a manual invoice was created, resuming the
   subscription would set the next invoice date incorrectly.
- It would often pick a date that had already been invoiced manually, skipping
   over the pause period.
- This happened because the user_pause_start is not reset after posting the
   manual invoice.

After:

- Now, when a manual invoice is posted during a pause, the pause state is
   cleared right away.
- This makes sure the next_invoice_date is calculated properly when the
   subscription is resumed, without missing the pause period.

Impact:

- Fixes issues where subscriptions skipped billing periods after a manual invoice
   during a pause.
- Keeps the billing period accurate when pausing and resuming subscriptions.

Steps to reproduce:

- Create and confirm a subscription.
- Pause the subscription.
- Post a manual invoice.
- Resume the subscription.


task-4946268

Forward-Port-Of: odoo/enterprise#90395

#subscriptions#billing#invoicing#pause-resume

Saas 18.4 sale renting planning fix xbo

PR #92260

Enterprisemastersale_planningsale_renting_planningMEDIUM

Rental orders now create and publish planning shifts more reliably, including creating one shift per unit when products are ordered by unit. The update also prevents staff from adding shifts to rental order lines that are already fully planned, helping avoid overbooking and planning errors.

Original PR description

## [FIX] sale_renting_planning: make sure shift generated by RO is published ## [FIX] sale_renting_planning: generate shifts when confirming rental order based on uom Before this commit, when the…

## [FIX] sale_renting_planning: make sure shift generated by RO is published

## [FIX] sale_renting_planning: generate shifts when confirming rental order based on uom

Before this commit, when the user creates room product to generate
shifts when a rental order is confirmed with that product, we expect to
generate one shift per quantity ordered if the UoM is Unit instead of
Hours/Days.

This commit improves the shifts generation to take into account the UoM
set on the SOL linked to rental order confirmed. That is, if the UoM set
is Unit then one slot per unit ordered of the product will be generated.
Otherwise, one shift will be generated for the SOL as it is currently
the case.

## [FIX] sale_renting_planning: make sure to not overload the rental service

Before this commit, when the user creates a new shift and clicks on `Add
to Last Order` the shift will be added to the SOL contained one of
products linked to the role set on the shift. The problem is we don't
check if there is still something to plan for that SOL.

This commit makes sure the SOL to set to the shift has something to plan
to be sure it is not overloaded.

task-4916537

Forward-Port-Of: odoo/enterprise#91327

#rental#planning#shifts#overbooking

[FIX] l10n_fr_fec_import: prevent override of the name

PR #92254

Enterprisemasterl10n_fr_fec_importMEDIUM

This fix prevents the French FEC import from overwriting account names when multiple accounts share similar codes but have different labels. It helps preserve accounting data accuracy during imports and avoids manual corrections after importing files.

Original PR description

Steps to reproduce:
- import a fec with different account 164*** with different names

Issue:
All the account's name will be overriden

Cause:
Before 18.0, apparently, code and name were joined and was not an issue

solution:
update the code to the new logic by filtering out the name from the override (`_apply_template`)

opw-4690284

Forward-Port-Of: odoo/enterprise#92149
Forward-Port-Of: odoo/enterprise#86809

#French accounting#FEC import#account names

[FIX] pos_blackbox_be: keep multiple employee clock-ins across devices

PR #92138

Enterprisemasterpos_blackbox_beMEDIUM

The POS Belgian blackbox module now keeps existing employee clock-ins when another employee clocks in from a different device. This prevents accidental clock-outs during device synchronisation, helping stores track staff attendance accurately.

Original PR description

- Fixes an issue where clocking in a second employee on a different device would automatically clock out the first one. This was due to `self` being unset during POS session leading to incorrect loading of `users_clocked_ids` and `employees_clocked_ids`.
- The issue was appearing when `pos_session._post_read_pos_data` is triggered from `pos_config.notify_synchronisation`.

task-id: 4902090

Forward-Port-Of: odoo/enterprise#89273

#pos#attendance#synchronisation

[FIX] stock_fleet_enterprise: use correct map view in action

PR #92045

Enterprisemasterstock_fleet_enterpriseMEDIUM

Batch transfer route planning now opens the intended map view, restoring the ability to rearrange pickings from that screen. This helps logistics teams organize deliveries correctly without being sent to a map view that does not support the needed ordering.

Original PR description

Commit ade5e5085df2 move the `default_order` value as it was defined in the wrong module. Consequence is the map view defined in `stock_enterprise` cannot be reordered anymore. This is an issue as the one in `stock_fleet_enterprise` is never used. The action window is patched to take a picking map view but without specifying witch one.

This commit force the map view defined in `stock_fleet_enterprise` to be used in the action of `stock_fleet_enterprise`.

Consequence is that the picking can be rearranged again in the map view coming from a batch transfer and not coming from the picking list.

Forward-Port-Of: odoo/enterprise#91999

#inventory#fleet#batch transfers#map view

[FIX] sale_timesheet_enterprise : Show total hours of validated timesheets only

PR #92301

Enterprisemastersale_timesheet_enterpriseMEDIUM

The portal now shows total hours based only on validated timesheets when that invoicing policy is selected. This prevents customers from seeing inflated hours that include unvalidated work, keeping task totals consistent with the timesheet lines displayed.

Original PR description

### Steps to reproduce:
	- Set timesheets inovicing policy to 'Validated Timesheets Only'
	- From the portal go to any task that has some validated timesheet and some other not
	- Notice that the lines shown is the validated ones only but the Hours spent includes the non-validated ones too

### Current behavior before PR:
The total hours spent for timesheets in portal view when setting the invoicing policy to 'Validate Timesheets Only' is calculated wrongly as it takes the non validated ones into account.

This is happening as when passing the values to the view we pass 'task_sudo' variable which will have the SUPERUSER as the env.user

https://github.com/odoo/odoo/blob/saas-17.2/addons/project/controllers/portal.py#L569

so it won't pass the condition if the user is portal or not https://github.com/odoo/enterprise/blob/saas-17.2/sale_timesheet_enterprise/models/project_task.py#L33:L35 and it will calculate all the timesheet without taking validation into condisderation.

### Desired behavior after PR is merged:
As we are using those computed fields only in portal views so we don't have to check if the user is portal user as even if an internal user is showing the same view for testing he should be able to see the same data as the portal user.

opw-4193842

Forward-Port-Of: odoo/enterprise#70557

#timesheets#portal#validated hours#invoicing

Version: - saas-18.4 Before: - If a subscription was paused and a manual invoice was created, resuming the subscription would set the next invoice date incorrectly. - It would often pick a date that had already been invoiced manually, skipping over the pause period. - This happened because the user_pause_start is not reset after posting the manual invoice. After: - Now, when a manual invoice is posted during a pause, the pause state is cleared right away. - This makes sure the next_invoice_date is calculated properly when the subscription is resumed, without missing the pause period. Impact: - Fixes issues where subscriptions skipped billing periods after a manual invoice during a pause. - Keeps the billing period accurate when pausing and resuming subscriptions. Steps to reproduce: - Create and confirm a subscription. - Pause the subscription. - Post a manual invoice. - Resume the subscription. task-4946268 Forward-Port-Of: odoo/enterprise#90395

## [FIX] sale_renting_planning: make sure shift generated by RO is published ## [FIX] sale_renting_planning: generate shifts when confirming rental order based on uom Before this commit, when the user creates room product to generate shifts when a rental order is confirmed with that product, we expect to generate one shift per quantity ordered if the UoM is Unit instead of Hours/Days. This commit improves the shifts generation to take into account the UoM set on the SOL linked to rental order confirmed. That is, if the UoM set is Unit then one slot per unit ordered of the product will be generated. Otherwise, one shift will be generated for the SOL as it is currently the case. ## [FIX] sale_renting_planning: make sure to not overload the rental service Before this commit, when the user creates a new shift and clicks on `Add to Last Order` the shift will be added to the SOL contained one of products linked to the role set on the shift. The problem is we don't check if there is still something to plan for that SOL. This commit makes sure the SOL to set to the shift has something to plan to be sure it is not overloaded. task-4916537 Forward-Port-Of: odoo/enterprise#91327

Steps to reproduce: - import a fec with different account 164*** with different names Issue: All the account's name will be overriden Cause: Before 18.0, apparently, code and name were joined and was not an issue solution: update the code to the new logic by filtering out the name from the override (`_apply_template`) opw-4690284 Forward-Port-Of: odoo/enterprise#92149 Forward-Port-Of: odoo/enterprise#86809

- Fixes an issue where clocking in a second employee on a different device would automatically clock out the first one. This was due to `self` being unset during POS session leading to incorrect loading of `users_clocked_ids` and `employees_clocked_ids`. - The issue was appearing when `pos_session._post_read_pos_data` is triggered from `pos_config.notify_synchronisation`. task-id: 4902090 Forward-Port-Of: odoo/enterprise#89273

Commit ade5e5085df2 move the `default_order` value as it was defined in the wrong module. Consequence is the map view defined in `stock_enterprise` cannot be reordered anymore. This is an issue as the one in `stock_fleet_enterprise` is never used. The action window is patched to take a picking map view but without specifying witch one. This commit force the map view defined in `stock_fleet_enterprise` to be used in the action of `stock_fleet_enterprise`. Consequence is that the picking can be rearranged again in the map view coming from a batch transfer and not coming from the picking list. Forward-Port-Of: odoo/enterprise#91999

### Steps to reproduce: - Set timesheets inovicing policy to 'Validated Timesheets Only' - From the portal go to any task that has some validated timesheet and some other not - Notice that the lines shown is the validated ones only but the Hours spent includes the non-validated ones too ### Current behavior before PR: The total hours spent for timesheets in portal view when setting the invoicing policy to 'Validate Timesheets Only' is calculated wrongly as it takes the non validated ones into account. This is happening as when passing the values to the view we pass 'task_sudo' variable which will have the SUPERUSER as the env.user https://github.com/odoo/odoo/blob/saas-17.2/addons/project/controllers/portal.py#L569 so it won't pass the condition if the user is portal or not https://github.com/odoo/enterprise/blob/saas-17.2/sale_timesheet_enterprise/models/project_task.py#L33:L35 and it will calculate all the timesheet without taking validation into condisderation. ### Desired behavior after PR is merged: As we are using those computed fields only in portal views so we don't have to check if the user is portal user as even if an internal user is showing the same view for testing he should be able to see the same data as the portal user. opw-4193842 Forward-Port-Of: odoo/enterprise#70557