Odoo Changelog — 2026-01-21

Wednesday, January 21, 2026

10 changes · 18.0

Bug Fixes(10)

Resolved issues and error corrections

[FIX] mrp_mps: compute product ratio when reordering with MPS

Enterprise18.0mrp_mpsMEDIUM

This update fixes an error in the Master Production Schedule (MPS) calculation for kit products sourced from a second warehouse. Previously, the system incorrectly squared the reorder amount, leading to excessive component orders. This change ensures accurate component quantities are ordered, preventing overstocking and improving production efficiency.

Original PR description

***Behavior:***
In a setting with a second warehouse that is supplied by the first one. Creating a product that uses that ressuply route,
and then adding it to the bom of a kit product will make it so that when ordering the kit product to the second warehouse from the MPS, the system will create an order for an exponential amount of components.

When calling action_replenish, kit products for which the components don't have an MPS entry will have their product_ratio computed to know how many components to reorder. However the current formula is wrong or outdated and ends up returning the squared amount.

***Steps to reproduce:***
- Create a second warehouse.
- Check Resuply From 'First Warehouse' (this will unarchive a route)
- Create a product that uses that route for reordering.
- Create a second product
- Create a kit for that product BOM composed of the first product make sure the amount of component is more than 1
- In the Master Production Schedule: Add the kit product and make sure it is produced in the second warehouse with the unarchived route.
- Add any amount to reorder in 'Replenishment' then click the Order button.
- If you go to deliveries and look for your component, you'll see the amount of component per kit squared multiplied by the reordered kit amount.

opw-5351460

#production#inventory#mps#kit products

[FIX] l10n_ch_hr_payroll_elm_transmission: Adapt 2026 single canton import

PR #104950

Enterprise18.0l10n_ch_hr_payrollMEDIUM

This update corrects a problem with importing tax rates for Swiss payroll (l10n_ch_hr_payroll) related to the 2026 tax year and single canton reporting requirements. The change ensures accurate tax calculations and reporting compliance for Swiss businesses using this module.

Original PR description

Forward-Port-Of: odoo/enterprise#104333

#payroll#tax#switzerland#elm#ch

[FIX] purchase: correct unit price and discount when adding POL via catalog

PR #244522

Core18.0purchaseMEDIUM

This update fixes an issue where the unit price on Purchase Order Lines created through the vendor catalog wasn't accurately reflecting the vendor's discount. The fix ensures the correct discount is applied and displayed, leading to accurate pricing calculations and improved order accuracy. This impacts how purchase orders are priced when using the catalog feature.

Original PR description

**Steps to reproduce:**

- Install the `purchase_stock` module.
- Create a product and configure a Vendor Pricelist for a vendor.
Include a discount on the vendor pricelist line.
- Create a Purchase Order for the same vendor.
- In the Purchase Order, add a Purchase Order Line using
the catalog (vendor catalog popup) and add a configured product.

**Observed behavior:**
- The unit price on the Purchase Order Line becomes vendor `unit price − discount`
The `discount` field remains empty, causing incorrect price calculations.

---
**Example**
---

Product-A - > Vendor Price list - > Vendor - > Test Vendor, Unit price = 100 and discount 10

- Create PO with `Test Vendor` and add a Product to POL via catalog then

**Current behavior:**
Product - A , qty - >1, unit price -> 90, discount->0% , subtotal ->90

**Expected behavior :**
Product-A , qty->1, unit_price->100, discount->10%, subtotal->90

---

**Cause:**
- The catalog selection applies the vendor pricelist discount directly to
the unit price instead of populating the discount field.

**Fix:**
- Use the vendor pricelist's price as the `unit_price` and apply
vendor pricelist discount to the discount field on the Purchase Order Line.

---
`NOTE` - This issue is resolved from version 18.2, In this [Commit](https://github.com/odoo/odoo/pull/227695/commits/6b91f393353bcdaeed076d58dcac3149ed587e77#diff-1281da5f4d0a3daaf162a2e6456469537d1b74b8034437783c9c717307aa8fcd)

---
opw-5217345

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

Forward-Port-Of: odoo/odoo#235968

#purchase#catalog#pricing

[FIX] l10n_ch_hr_payroll: salary certificate period

PR #104965

Enterprise18.0l10n_ch_hr_payrollMEDIUM

This update automatically adjusts the start and end dates for salary certificate reporting in the Odoo Switzerland module. Previously, these dates were fixed, but now they dynamically pull from the configured data, ensuring accurate reporting and compliance with Swiss tax regulations. This change simplifies the process for businesses operating in Switzerland.

Original PR description

make Period until and from dynamic from data

Forward-Port-Of: odoo/enterprise#104903

#payroll#reporting#Switzerland#tax

[FIX] mrp: compute operation duration using the new workcenter

PR #239021

Core18.0mrpMEDIUM

This update fixes an issue where the Gantt progress bar displayed an incorrect estimated duration for work orders after changing their assigned workcenter. The previous calculation used the old workcenter's efficiency, leading to inaccurate progress tracking. This ensures the Gantt chart accurately reflects the expected completion time.

Original PR description

**Issue** Changing the workcenter of a workorder to another with a different time efficiency does not correctly update `date_finished`, causing the Gantt progress bar to show an incorrect expected…

**Issue**
Changing the workcenter of a workorder to another with a different time efficiency does not correctly update `date_finished`, causing the Gantt progress bar to show an incorrect expected duration.

**Steps to reproduce**
1. Create two workcenters marked as alternatives (100% and 50% efficiency).
2. Create a BOM operation that produces 100 products with a 1h expected duration each, on the 100% workcenter.
3. Create and plan an MO using this BOM.
4. In Planning > Planning by Workcenter (Gantt), drag the workorder to the 50% efficiency workcenter. → Expected duration remains 100h instead of 200h.
5. Drag the same workorder back to the 100% workcenter. → Expected duration becomes 200h instead of 100h.

**Cause**
`date_finished` is recomputed in `write()` using the *previous* workcenter’s efficiency, because the duration calculation happens before the new `workcenter_id` is applied: https://github.com/odoo/odoo/blob/18.0/addons/mrp/models/mrp_workorder.py#L471

Since the Gantt progress bar uses the interval [`[date_start, date_finished]`](https://github.com/odoo/enterprise/blob/18.0/mrp_workorder/models/mrp_workorder.py#L672C13-L674C107) to compute the expected duration (via `_web_gantt_progress_bar_workcenter_id`), the displayed duration becomes wrong.

opw-5224272

#gantt#workcenter#production planning

[FIX] mrp: use work center availability to compute total expected workorder duration

PR #240617

Core18.0mrpMEDIUM

This update fixes an issue where manufacturing order end dates were incorrectly calculated, assuming work centers operated 24/7. The change now accurately considers work center availability, ensuring more precise scheduling and reducing potential scheduling errors. This improves the accuracy of production timelines.

Original PR description

**Issue**
The scheduled end date of a manufacturing order incorrectly assumes that the work center operates 24 hours a day.

**Steps to reproduce**
1. Create a manufacturing order with:
   - A work order with an expected duration of 1440 minutes.
   - A work center configured to work 8 hours per day.
2. Observe that the scheduled end date is computed as if the work center operates 24h/day resulting in an end date 1 day instead of 4 after the starting date.

**Cause**
The `date_finish` computation:
https://github.com/odoo/odoo/blob/680085b55728dcb000e7bb4277bb83b0e4e2ce91/addons/mrp/models/mrp_production.py#L745C1-L746C105
does not take into account neither the work center’s calendar nor the workorder dependency when estimating the duration.

**Solution**
Use `_get_first_available_slot`:
https://github.com/odoo/odoo/blob/5d75037d4f81d71a50394c3d390c420967766731/addons/mrp/models/mrp_workcenter.py#L332
to consider workcenter availability, inspired from when a workorder is planned:
https://github.com/odoo/odoo/blob/5d75037d4f81d71a50394c3d390c420967766731/addons/mrp/models/mrp_workorder.py#L527
**Additionnal notes**
- If a workcenter of at least one workorder is unavailable, just fallback on the previous computation.
- The solution does not take workorder dependencies into account due to related technical limitation see https://github.com/odoo/odoo/pull/232805 for an earlier attempt to handle dependencies.
- Our test rely on the assertAlmostEqual for the same reason than https://github.com/odoo/odoo/commit/e6c958ca226bd8ef7e518243c93e40b92b9b5919

opw-[5084120](https://www.odoo.com/web#id=5084120&view_type=form&model=project.task)

#manufacturing#production#scheduling

[FIX] microsoft_calendar: make Graph timeout configurable

PR #244461

Core18.0microsoft_calendarMEDIUM

This update fixes a potential issue where Microsoft calendar synchronization could fail due to a short timeout when communicating with Microsoft's services. Now, administrators can adjust a system setting to increase the timeout, allowing for more reliable synchronization, especially in environments with slower connections or large calendars. This prevents duplicate events from being created.

Original PR description

**Description of the issue/feature this PR addresses:** Microsoft calendar synchronization may fail in environments with slower Microsoft Graph responses or large calendars because Graph API calls…

**Description of the issue/feature this PR addresses:**

Microsoft calendar synchronization may fail in environments with slower Microsoft Graph responses or large calendars because Graph API calls triggered after commit use a fixed 3-second timeout. This can lead to repeated synchronization failures even though the operation would succeed with slightly more time.

Additionally, when creating events, the Microsoft Graph request may time out after the event is successfully created on Microsoft’s side but before the response containing the event ID is returned. In this case, Odoo does not store the ID of the event and may create the same event again during the next sync, resulting in duplicate events.

**Current behavior before PR:**

Microsoft Graph requests (insert, update, delete) are executed with a hardcoded 3-second timeout. If the Graph API response takes longer:
• the synchronization fails,
• and in the case of event creation, Odoo may not receive the Microsoft event ID even though the event was created remotely, which can lead to duplicate events in Odoo.

**Desired behavior after PR is merged:**

The Microsoft Graph request timeout is configurable via the optional system parameter `microsoft_calendar.graph_timeout`.

If the parameter is not set, the behavior remains unchanged (default 3 seconds).
Administrators can increase the timeout to allow successful synchronization in slower environments or with large datasets, reducing synchronization failures and avoiding duplicate event creation caused by missing Microsoft IDs.

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

Forward-Port-Of: odoo/odoo#241921

#calendar#microsoft#synchronization#reliability

[FIX] test_appointment_full: make Graph timeout configurable

PR #104916

Enterprise18.0enterpriseMEDIUM

This update resolves a potential issue with Microsoft calendar synchronization in slower environments. Previously, a fixed 3-second timeout for Graph requests caused failures. Now, the timeout is configurable, increasing the reliability of calendar syncing and ensuring smoother operation.

Original PR description

Microsoft calendar sync can fail in slower environments due to a fixed 3s timeout for Graph requests triggered after commit.

See community changes for details.

#calendar#sync#microsoft

[FIX] portal_rating: allow ios rating

PR #234308

Core18.0portal_ratingMEDIUM

This update resolves an issue where iOS users were unable to save custom star ratings for product reviews. The fix prevents a technical glitch that caused the rating to reset to the default 4-star value before submission. This ensures a consistent and reliable review experience for all users, regardless of their device.

Original PR description

## Versions
18.0+

## Issue
On iOS devices, when submitting a product review with a custom star rating, the selected value would revert to the default (4 stars) before submission.

## Steps to reproduce
*On a laptop*
- Open Editor mode on a product eCommerce page:
  - Select any product element (e.g. click on the price);
  - Activate customer ratings and save.

*On a physical Apple mobile device (iPhone or iPad) or on an iOS emulator via XCode (only on MacOS)*
- Go to the product's eCommerce page:
  - Move down to the "Customer Reviews" section and un-toggle it:
    - Write down a review;
    - Click on any star rating but 4;
    - Send.

## Cause
`mouseleave` event is triggered before the rating is saved and resets the rating to the default 4-star one.

## Solution
Only trigger `mouseleave` event on devices handling them correctly and post the number of visible stars on the form.

opw-5142682

#rating#ios#mobile#customer reviews

[FIX] spreadsheet: update o_spreadsheet to latest version

PR #244977

Core18.0spreadsheetMEDIUM

This update improves the Odoo spreadsheet library with several fixes and enhancements. It addresses issues related to exporting, calculations, and error handling, ensuring more reliable spreadsheet generation. This impacts the functionality of reports and data exports within Odoo.

Original PR description

### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/0c9401570e [REL] 18.0.55 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/0c9401570e [REL] 18.0.55 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/5ae3755deb [FIX] Actions: ensure the sequence is applied on action children [Task: 5452669](https://www.odoo.com/odoo/2328/tasks/5452669)
https://github.com/odoo/o-spreadsheet/commit/7f5195e2c8 [PERF] evaluation: don't spread single element matrix [Task: 5491138](https://www.odoo.com/odoo/2328/tasks/5491138)
https://github.com/odoo/o-spreadsheet/commit/aa0f10a1e0 [FIX] evaluation: remove spread relation [Task: 5491138](https://www.odoo.com/odoo/2328/tasks/5491138)
https://github.com/odoo/o-spreadsheet/commit/6f72a86b1f [FIX] vectorization: fix error message on size mismatch [Task: 5331324](https://www.odoo.com/odoo/2328/tasks/5331324)
https://github.com/odoo/o-spreadsheet/commit/8cca473e89 [IMP] xlsx: export clip [Task: 5368130](https://www.odoo.com/odoo/2328/tasks/5368130)
https://github.com/odoo/o-spreadsheet/commit/f1ca9a35c5 [IMP] export: export align left when the cell content is a number; [Task: 5368130](https://www.odoo.com/odoo/2328/tasks/5368130)
https://github.com/odoo/o-spreadsheet/commit/3e4f1eefb4 [FIX] header_size: wrong row size from wrapped number [Task: 4878338](https://www.odoo.com/odoo/2328/tasks/4878338)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

#spreadsheet#export#report

***Behavior:*** In a setting with a second warehouse that is supplied by the first one. Creating a product that uses that ressuply route, and then adding it to the bom of a kit product will make it so that when ordering the kit product to the second warehouse from the MPS, the system will create an order for an exponential amount of components. When calling action_replenish, kit products for which the components don't have an MPS entry will have their product_ratio computed to know how many components to reorder. However the current formula is wrong or outdated and ends up returning the squared amount. ***Steps to reproduce:*** - Create a second warehouse. - Check Resuply From 'First Warehouse' (this will unarchive a route) - Create a product that uses that route for reordering. - Create a second product - Create a kit for that product BOM composed of the first product make sure the amount of component is more than 1 - In the Master Production Schedule: Add the kit product and make sure it is produced in the second warehouse with the unarchived route. - Add any amount to reorder in 'Replenishment' then click the Order button. - If you go to deliveries and look for your component, you'll see the amount of component per kit squared multiplied by the reordered kit amount. opw-5351460

**Steps to reproduce:** - Install the `purchase_stock` module. - Create a product and configure a Vendor Pricelist for a vendor. Include a discount on the vendor pricelist line. - Create a Purchase Order for the same vendor. - In the Purchase Order, add a Purchase Order Line using the catalog (vendor catalog popup) and add a configured product. **Observed behavior:** - The unit price on the Purchase Order Line becomes vendor `unit price − discount` The `discount` field remains empty, causing incorrect price calculations. --- **Example** --- Product-A - > Vendor Price list - > Vendor - > Test Vendor, Unit price = 100 and discount 10 - Create PO with `Test Vendor` and add a Product to POL via catalog then **Current behavior:** Product - A , qty - >1, unit price -> 90, discount->0% , subtotal ->90 **Expected behavior :** Product-A , qty->1, unit_price->100, discount->10%, subtotal->90 --- **Cause:** - The catalog selection applies the vendor pricelist discount directly to the unit price instead of populating the discount field. **Fix:** - Use the vendor pricelist's price as the `unit_price` and apply vendor pricelist discount to the discount field on the Purchase Order Line. --- `NOTE` - This issue is resolved from version 18.2, In this [Commit](https://github.com/odoo/odoo/pull/227695/commits/6b91f393353bcdaeed076d58dcac3149ed587e77#diff-1281da5f4d0a3daaf162a2e6456469537d1b74b8034437783c9c717307aa8fcd) --- opw-5217345 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235968

**Issue** Changing the workcenter of a workorder to another with a different time efficiency does not correctly update `date_finished`, causing the Gantt progress bar to show an incorrect expected duration. **Steps to reproduce** 1. Create two workcenters marked as alternatives (100% and 50% efficiency). 2. Create a BOM operation that produces 100 products with a 1h expected duration each, on the 100% workcenter. 3. Create and plan an MO using this BOM. 4. In Planning > Planning by Workcenter (Gantt), drag the workorder to the 50% efficiency workcenter. → Expected duration remains 100h instead of 200h. 5. Drag the same workorder back to the 100% workcenter. → Expected duration becomes 200h instead of 100h. **Cause** `date_finished` is recomputed in `write()` using the *previous* workcenter’s efficiency, because the duration calculation happens before the new `workcenter_id` is applied: https://github.com/odoo/odoo/blob/18.0/addons/mrp/models/mrp_workorder.py#L471 Since the Gantt progress bar uses the interval [`[date_start, date_finished]`](https://github.com/odoo/enterprise/blob/18.0/mrp_workorder/models/mrp_workorder.py#L672C13-L674C107) to compute the expected duration (via `_web_gantt_progress_bar_workcenter_id`), the displayed duration becomes wrong. opw-5224272

**Issue** The scheduled end date of a manufacturing order incorrectly assumes that the work center operates 24 hours a day. **Steps to reproduce** 1. Create a manufacturing order with: - A work order with an expected duration of 1440 minutes. - A work center configured to work 8 hours per day. 2. Observe that the scheduled end date is computed as if the work center operates 24h/day resulting in an end date 1 day instead of 4 after the starting date. **Cause** The `date_finish` computation: https://github.com/odoo/odoo/blob/680085b55728dcb000e7bb4277bb83b0e4e2ce91/addons/mrp/models/mrp_production.py#L745C1-L746C105 does not take into account neither the work center’s calendar nor the workorder dependency when estimating the duration. **Solution** Use `_get_first_available_slot`: https://github.com/odoo/odoo/blob/5d75037d4f81d71a50394c3d390c420967766731/addons/mrp/models/mrp_workcenter.py#L332 to consider workcenter availability, inspired from when a workorder is planned: https://github.com/odoo/odoo/blob/5d75037d4f81d71a50394c3d390c420967766731/addons/mrp/models/mrp_workorder.py#L527 **Additionnal notes** - If a workcenter of at least one workorder is unavailable, just fallback on the previous computation. - The solution does not take workorder dependencies into account due to related technical limitation see https://github.com/odoo/odoo/pull/232805 for an earlier attempt to handle dependencies. - Our test rely on the assertAlmostEqual for the same reason than https://github.com/odoo/odoo/commit/e6c958ca226bd8ef7e518243c93e40b92b9b5919 opw-[5084120](https://www.odoo.com/web#id=5084120&view_type=form&model=project.task)

**Description of the issue/feature this PR addresses:** Microsoft calendar synchronization may fail in environments with slower Microsoft Graph responses or large calendars because Graph API calls triggered after commit use a fixed 3-second timeout. This can lead to repeated synchronization failures even though the operation would succeed with slightly more time. Additionally, when creating events, the Microsoft Graph request may time out after the event is successfully created on Microsoft’s side but before the response containing the event ID is returned. In this case, Odoo does not store the ID of the event and may create the same event again during the next sync, resulting in duplicate events. **Current behavior before PR:** Microsoft Graph requests (insert, update, delete) are executed with a hardcoded 3-second timeout. If the Graph API response takes longer: • the synchronization fails, • and in the case of event creation, Odoo may not receive the Microsoft event ID even though the event was created remotely, which can lead to duplicate events in Odoo. **Desired behavior after PR is merged:** The Microsoft Graph request timeout is configurable via the optional system parameter `microsoft_calendar.graph_timeout`. If the parameter is not set, the behavior remains unchanged (default 3 seconds). Administrators can increase the timeout to allow successful synchronization in slower environments or with large datasets, reducing synchronization failures and avoiding duplicate event creation caused by missing Microsoft IDs. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241921

## Versions 18.0+ ## Issue On iOS devices, when submitting a product review with a custom star rating, the selected value would revert to the default (4 stars) before submission. ## Steps to reproduce *On a laptop* - Open Editor mode on a product eCommerce page: - Select any product element (e.g. click on the price); - Activate customer ratings and save. *On a physical Apple mobile device (iPhone or iPad) or on an iOS emulator via XCode (only on MacOS)* - Go to the product's eCommerce page: - Move down to the "Customer Reviews" section and un-toggle it: - Write down a review; - Click on any star rating but 4; - Send. ## Cause `mouseleave` event is triggered before the rating is saved and resets the rating to the default 4-star one. ## Solution Only trigger `mouseleave` event on devices handling them correctly and post the number of visible stars on the form. opw-5142682

### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/0c9401570e [REL] 18.0.55 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/5ae3755deb [FIX] Actions: ensure the sequence is applied on action children [Task: 5452669](https://www.odoo.com/odoo/2328/tasks/5452669) https://github.com/odoo/o-spreadsheet/commit/7f5195e2c8 [PERF] evaluation: don't spread single element matrix [Task: 5491138](https://www.odoo.com/odoo/2328/tasks/5491138) https://github.com/odoo/o-spreadsheet/commit/aa0f10a1e0 [FIX] evaluation: remove spread relation [Task: 5491138](https://www.odoo.com/odoo/2328/tasks/5491138) https://github.com/odoo/o-spreadsheet/commit/6f72a86b1f [FIX] vectorization: fix error message on size mismatch [Task: 5331324](https://www.odoo.com/odoo/2328/tasks/5331324) https://github.com/odoo/o-spreadsheet/commit/8cca473e89 [IMP] xlsx: export clip [Task: 5368130](https://www.odoo.com/odoo/2328/tasks/5368130) https://github.com/odoo/o-spreadsheet/commit/f1ca9a35c5 [IMP] export: export align left when the cell content is a number; [Task: 5368130](https://www.odoo.com/odoo/2328/tasks/5368130) https://github.com/odoo/o-spreadsheet/commit/3e4f1eefb4 [FIX] header_size: wrong row size from wrapped number [Task: 4878338](https://www.odoo.com/odoo/2328/tasks/4878338) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>