Odoo Changelog — 2026-01-21

Wednesday, January 21, 2026

25 changes · 18.0

Improvements(1)

Enhancements to existing features

[IMP] account_edi_ubl_cii_tax_extension: Complete the VAT exemption reason codes (EN16931)

Core18.0account_edi_ubl_cii_tax_extension

This update adds a comprehensive list of VAT exemption reason codes (VATEX) to the account_edi_ubl_cii_tax_extension module. This ensures greater accuracy and compliance with European regulations regarding VAT exemptions, particularly related to EN16931 standards. It improves the system's ability to correctly process and report on VAT exemptions.

Original PR description

The list is there but not exhaustive.

Make the exhaustive list of VAT exemption reason codes (VATEX) available.

task-5443294

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

#VAT#Exemption#EN16931#Tax

Bug Fixes(24)

Resolved issues and error corrections

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

PR #101462

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…

***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] l10n_vn_edi_viettel: taxAmount decimal

PR #244647

Core18.0l10n_vn_edi_viettel

This update resolves an issue where invoices sent to Viettel's SInvoice system were failing due to incorrect tax amount formatting. The change ensures the tax amount is calculated using the currency's rounding method, aligning with SInvoice's requirements and preventing errors.

Original PR description

When sending an invoice to SInvoice (Viettel), the API raises an `INVALID_DECIMAL_POINT_TAX_MONEY` error if the tax amount contains excessive decimal places (e.g., 100.02999999999997).

This occurs because the tax amount is currently calculated using simple subtraction (`total - subtotal`). Due to standard floating-point precision issues, this can result in unrounded values that the API rejects.

The tax amount calculation is now updated to explicitly use the currency's rounding method, ensuring the value is accepted by SInvoice.

task-[5484845](https://www.odoo.com/odoo/project/967/tasks/5484845)

#invoice#viettel#sinvoice#tax

[FIX] l10n_vn: update default accounts on import VAT taxes

PR #244434

Core18.0l10n_vn

This update corrects errors in VAT import billing by adjusting the default accounts used when creating invoices. Specifically, the account number 33312 was updated, resolving incorrect journal entries. This ensures accurate financial reporting for VAT transactions.

Original PR description

Due to the change of account 33312 from liability to payable, the journal entries generated when creating bills with VAT import taxes were incorrect.

This fix updates the default account on the following taxes:
- tax_purchase_import_10
- tax_purchase_import_8
- tax_purchase_import_5

task-5695253

#VAT#accounting#taxes#Vietnam

[FIX] account: strip out dots from VAT numbers

PR #244696

Core18.0account

This update fixes an issue where Odoo was creating duplicate vendor contacts when receiving invoices with slightly different VAT number formats (with or without dots). Now, Odoo will correctly identify and link invoices with the same VAT number, regardless of formatting variations, ensuring accurate record-keeping.

Original PR description

Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number Current behavior before PR: If you have two incoming vendor bills (over a period of time)…

Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number

Current behavior before PR:
If you have two incoming vendor bills (over a period of time) where the first bill has these details:
- VAT number: `BE0477472701`
- Name: `Odoo`

And the second bill (e.g three months later) has these details:
- VAT number: `BE0477.472.701`
- Name: `Odoo S.A`

Odoo will do something interesting and will create a second new contact.
The reason is because the fallback on `name` from `res.partner` fails (since "Odoo S.A" is not equal to "Odoo".
However, the `vat` number matching also fails! Since the VAT number "BE0477.472.701" is not identical to "BE0477472701".
Throughout Odoo however VAT numbers are parsed and stored without dots in it.
The function `_retrieve_partner_with_vat` however is an exception because the `vat` number here is sanitized for spaces but not for dots.
Because of the combination of no exact match on neither `name` nor `vat` it now creates a second contact although the VAT number is technically the same.

Desired behavior after PR is merged:
Both an incoming vendor bill with `0477.472.701` and `0477472701` match to the same contact even if there are dots in it and if the name of the company is different.

P.S: please find two sample XML's here:
[sample_odoo_sa_bill.xml](https://github.com/user-attachments/files/24718225/sample_odoo_sa_bill.xml)
[sample_odoo_bill.xml](https://github.com/user-attachments/files/24718226/sample_odoo_bill.xml)

If you upload both back to back on a default V19 you will see two contacts.
After this code change you will only see one contact where both bills are mapped to the same contacts.

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

Forward-Port-Of: odoo/odoo#244572

#VAT#Vendor Bills#Accounting

[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…

**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] mail: typo in search_highlight tests

PR #244832

Core18.0mail

This update corrects a typographical error in the tests for the search highlight feature within Odoo. This ensures the search functionality operates correctly and reliably, preventing potential issues with how search results are displayed to users. The fix improves the overall stability and accuracy of the search experience.

Original PR description

Intoduced by https://github.com/odoo/odoo/pull/118794

Forward-Port-Of: odoo/odoo#244720

#search#testing#bug fix

[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] calendar: prevent context loss on recurring event deletion

PR #243487

Core18.0calendar

This update resolves an issue where deleting a recurring calendar event caused the application to reset filters and lose context-specific settings, disrupting subsequent record creation. The fix prevents a full page reload, ensuring filters and relevant fields are preserved after event deletion.

Original PR description

Deleting a recurring calendar event triggers a full page reload, which resets the view to default, clearing active filters and causing context-dependent fields (like "Resources") to disappear during subsequent record creation.

### Steps to reproduce

1. Filter the Calendar view (e.g., "Everybody").
2. Delete a recurring event.
3. Observe the page reload and filter reset.
4. Try to create a new record; context-specific fields are missing.

The issue occurs because the deletion action forces a browser refresh (location.reload()), wiping the web client's in-memory state. This state holds the active filters and context keys necessary for rendering specific fields. When cleared, the application reverts to its default configuration.

opw-5433604

#calendar#recurring events#user experience

[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…

**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] l10n_it_edi: prevent crash on zero-amount foreign currency invoices

PR #244423

Core18.0l10n_it_edi

This update fixes a potential crash in the Italian EDI invoicing process when invoices are created with zero amounts in a foreign currency (like USD). The fix prevents a division-by-zero error during currency conversion, ensuring invoices can be generated correctly. This improves stability and avoids disruptions for users.

Original PR description

**Steps to reproduce:**
1. Install the `l10n_it_edi` and switch to IT company
2. Go to Accounting → Invoice.
3. Create an invoice add partner and change the currency to USD
4. Add a product and apply tax and discount of 100% and confirm
3. Click on Send

**Issue:**
A ZeroDivisionError is raised during the Italian EDI XML generation. 
`ZeroDivisionError: float division by zero`

**Cause:**
The conversion rate is computed by dividing `amount_total` by `amount_total_signed` without handling the case where `amount_total_signed` is `0.0`.

**Solution:**
Skip the conversion rate computation when the signed total amount is zero, preventing the division by zero

**opw-5481821**

#it_edi#currency#invoice

[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] pos_online_payment: restrict providers for the pos

PR #230819

Core18.0pos_online_payment

This update prevents the use of Amazon Payment Services in Odoo's self-order point-of-sale system. The issue stemmed from Amazon's requirement for customer identification, which isn't reliably available in self-order scenarios. This change ensures compatibility and prevents errors during payment processing.

Original PR description

Currently, it's impossible to use Amazon Payment Services as a online payment provider in the self order. We face a "Signature mismatch" error. Steps to reproduce: ------------------- * Set up the…

Currently, it's impossible to use Amazon Payment Services as a online payment provider in the self order. We face a "Signature mismatch" error.

Steps to reproduce:
-------------------
* Set up the payment porvider Amazon Payment Services
* Create an online pos payment method using Amazon as provider
* Set this payment method as the online method for a self
* Place an order in the self
* Try to pay it
> Observation: When the page is redirected to provider's checkout
  page an error occurs, "Signature mismatch"

Why the fix:
------------
Amazon Payment Services (APS) requires a customer to be identified in order to send its email into the request's signature. It is working fine on the website since during the checkout it will ask for the customer information and create a partner related.

In the point of sale we cannot guarentee to have a customer registered on the order. Even worse for the self and kiosk, no customer will be registered.

Since this provider is not compatible we do not allow it to be used with pos online payment methods.

opw-5053492

#payments#pos#amazon#error

[FIX] documents: fix a test failing on the runbot

PR #105027

Enterprise18.0documents

A recent test was failing intermittently due to an issue with the way redirect URLs were being handled. This update corrects the test to account for both absolute and relative URLs, ensuring consistent test results. This resolves a technical problem that could have impacted the stability of the Odoo Enterprise system.

Original PR description

Bug
===
On some runs, the redirect URL is absolute and not relative, (eg: `http://127.0.0.1:8069/web/signup?db=...`) and so the test needs to be adapted.

Task-5857520

#test#redirect#stability

[FIX] account_reports: prevent PDF export error when partner name is empty

PR #105025

Enterprise18.0account_reports

This update resolves an error that occurred when generating PDF reports for accounting, specifically when a contact didn't have a name assigned. The fix ensures that the report exports correctly regardless of whether a contact has a name or not, improving the reliability of the reporting process.

Original PR description

Currently, an error occurs when exporting an accounting report to PDF if any of the selected contacts do not have a name. **Steps to reproduce:** - Install the `account_reports` and `contacts`…

Currently, an error occurs when exporting an accounting report to 
PDF if any of the selected contacts do not have a name.

**Steps to reproduce:**
- Install the `account_reports` and `contacts` modules.
- Go to Contacts and open any contact (e.g., Azure Interior).
- Click `Add` > `Save & Close`, then `save` the contact.
- Navigate to Accounting > Reporting > Aged Receivable.
- Click `Partners` button and select the newly created contact (e.g., `Azure Interior, Other Address`).
- Click `PDF` to export the report.

**Error:**
`TypeError: sequence item 0: expected str instance, bool found`

**Root Cause:**
At [1], `options['selected_partner_ids']` is built using `partner.name`, which may 
be `False` for unnamed contacts. At [2], the `partner_value` list may therefore 
contain `False` entries coming from `options['selected_partner_ids']`. When 
calling `', '.join(partner_value)`, an error is raised because the list contains 
`non-string` (`bool`) values.

**Fix:**
This commit prevents errors when exporting reports to PDF and ensures 
that partner names are displayed in the report the same way as in the 
partner selection widget.

[1]:
https://github.com/odoo/enterprise/blob/a0ec2fcdc043cf52f1a646e84b9b97466072d47f/account_reports/models/account_report.py#L745

[2]:
https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/account_reports/data/pdf_export_templates.xml#L84-L93

opw-5467321

Forward-Port-Of: odoo/enterprise#103828

#reporting#contacts#pdf

[FIX] account: batch merges are not decided by the right key

PR #242863

Core18.0account

This update fixes an issue where payment batching wasn't consistently merging related inbound and outbound payments. Previously, the system created duplicate payments for transactions like refunds and bills to the same bank. Now, the system intelligently combines these into a single payment, streamlining the accounting process and reducing manual effort.

Original PR description

When we register payments for a list of journal entries, the `account.payment.register` wizard computes batches and sometimes merge them together.

For instance, this allows to create a single payment if there is an outbound (a bill to pay) and an inbound (a refund to receive) payment to the same bank for the same partner. Instead of creating two payments of -1000 and +500, we only create one of -500.

Currently, this mechanism does not always work. That's because the `batch_key` used to decide whether to merge or not refers to a value that is not updated in the loop.

Related ticket: opw-5401372

#payments#accounting#efficiency

[FIX] web: color slider getting reset

PR #236644

Core18.0webweb_editor

This update fixes a bug in the color picker within the Odoo editor where selecting a color would unexpectedly reset the slider to red. The change prevents unnecessary UI updates during color selection, ensuring a smoother and more reliable color picking experience for users.

Original PR description

**Current behavior before PR:**

In editor's custom gradient picker, if `#FFFFFF` is picked from the very top of picker area, the color slider is reset to color `red`. This happens because when moving picker pointer to the top of area, `selectedColor` prop is updated to `#FFFFFF`, which calls `onWillUpdateProps` callback. As result, `convertRgbToHsl` sets hue value 0 for `#FFFFFF`, setting color slider to red.

**Desired behavior after PR is merged:**

This commit ensures that in `onWillUpdateProps` callback, `setSelectedColor` should not get called if `newSelectedColor` is the same as `this.colorComponents.cssColor` to prevent updating UI twice while picking the color.

task-5170041




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

#UI#color picker#editor

[FIX] web_editor: allow non-admin editor user to save Unsplash image

PR #244831

Core18.0html_editorwebsite

This update resolves an issue preventing non-administrator website editors from successfully saving images they upload from Unsplash. The fix ensures the user creating the image has the necessary permissions, improving the editor's functionality and workflow. It addresses a security warning related to user access rights.

Original PR description

Scenario: - Setup Unsplash and install website - Set a user as "Website: Editor and Designer" - Login as that user and go to any website page with a qweb view - Go to edit mode and drop Text-Image in…

Scenario:

- Setup Unsplash and install website
- Set a user as "Website: Editor and Designer"
- Login as that user and go to any website page with a qweb view
- Go to edit mode and drop Text-Image in a view
- Replace the image with an unsplash image and then save

Result: the save fails without any message shown, and there is a
security access WARNING in the logs.

Note: a similar scenario can be done for a restricted editor that is
editing a HTML field it has write access to.

Issue: to save a model with res_id 0, we need to either be admin
(base.group_system) or the record creator. Since
9c9c58a5a10101532cbf046d21d4a63c2b7d2838 to bypass the mimetype
neutering of happening, we create the attachment as SUPERUSER.

Then when we modify the attachment url (for unsplash images), we have no
access right to the attachment since we are not the creator.

Fix: create the attachment with the current user, and only use
SUPERUSER to set the mimetype if it was neutered (ie. the user doesn't
have write access right to ir.ui.view, which in normal use case should
only happen for "Restricted Editor"). This way the image is created by
the user that uploaded it and not SUPERUSER.

opw-4850611
opw-5387258
opw-5489219

Forward-Port-Of: odoo/odoo#219472

#website#editor#image#Unsplash

[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] sale_pdf_quote_builder: prevent error when uploading invalid pdf file

PR #230712

Core18.0sale_pdf_quote_builder

This update fixes a problem that previously prevented users from uploading invalid PDF files (like encrypted or incomplete ones) to the quote builder. Now, the system gracefully handles these files, preventing errors and ensuring users can continue to create quotation documents. This improves the overall reliability of the sales process.

Original PR description

Currently, an error occurs when uploading `encrypted or incomplete` PDF files (missing EOF marker) while creating a quotation document header or footer. **Steps to reproduce:** - Install the…

Currently, an error occurs when uploading `encrypted or incomplete` 
PDF files (missing EOF marker) while creating a quotation document 
header or footer.

**Steps to reproduce:**
- Install the `sale_pdf_quote_builder` module.
- Navigate to: Sales > Configuration > Headers/Footers.
- Upload encrypted file [1], or incomplete file [2].

**Error:**
`PyPDF2.errors.DependencyError: PyCryptodome is required for AES algorithm`
`PyPDF2.errors.PdfReadError: EOF marker not found`

**Root cause:**
At [3], `_get_form_fields_from_pdf` and `_ensure_document_not_encrypted` directly 
call `pdf.PdfFileReader`, when it fails to read or decrypt the file, Python raises 
an error.

**Fix:**
This commit prevents errors when users upload unreadable or encrypted PDF files.

[1]:
https://drive.google.com/file/d/1moSlwXHkqcV6_7zHBNhLMLi-9Ye_xDGJ/view?usp=sharing

[2]:
https://drive.google.com/file/d/16O4LLH8dL0RWmbOx4HrcooFUyesWaVi-/view?usp=sharing

[3]:
https://github.com/odoo/odoo/blob/694f1d0fb03b56dd41a59eb676e56622634cc91b/addons/sale_pdf_quote_builder/utils.py#L11

sentry-6928220164
opw-5227601

#pdf#quotes#sales

[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

[FIX] account_edi_ubl_cii: allow negative discounts for Peppol BIS 3

PR #244679

Core18.0account_edi_ubl_cii

This update resolves a technical issue related to exporting negative discounts in Peppol BIS 3 (UBL 2.1) invoices. Previously, Odoo incorrectly formatted these discounts, leading to calculation errors. The change now correctly identifies negative discounts as surcharges, ensuring compliance with PEPPOL standards and accurate invoice generation.

Original PR description

In Peppol BIS 3 (UBL 2.1), negative discounts are logically treated as Surcharges (Charges) rather than Allowances.

Previously, Odoo exported negative discounts as an Allowance with a negative amount and a numeric reason code (95). This violated:

BR-CL-20 / PEPPOL-EN16931-CL003: Coded charge reasons must belong to the UNCL 7161 (alphabetic) list when ChargeIndicator is 'true'.

PEPPOL-EN16931-R120: The line net amount calculation failed due to the negative sign in the calculation.

Solution:
Dynamically toggles ChargeIndicator based on the discount sign. Swaps AllowanceChargeReasonCode to 'ADK' (Surcharge) for negative discounts.

task-5432024

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

#accounting#EDI#Peppol#UBL