Odoo Changelog — 2026-01-06

Tuesday, January 6, 2026

6 changes · 17.0

Bug Fixes(6)

Resolved issues and error corrections

[FIX] project : made users required for private project.

Core17.0projectMedium

This update resolves an issue where users would encounter access errors when creating new private tasks without a project or assigned users. The fix ensures that at least one user is required when creating a private task, preventing the access error and streamlining the task creation process.

Original PR description

When users would follow the following step as they are makeing a private task,  they would be hit by an incorrect access error.

Steps to reproduce:
1.Open the form view to create a new task.
2.Clear the Project field. When empty, it should display the Private placeholder. 3.Ensure no user is assigned to the task.
4.Create the private task.
5.An access rights error occurs, stating that the user does not have permission to create the record.

⚠️ Note:
This access rights error only occurs when the task is created directly as private. If a task is created normally and then its project_id and user_ids are removed afterward, no access rights error occurs.

Root cause:
When a task is created without a project_id and without assigned users, Odoo checks access rights on creation. Since no project members or assigned users exist, no user has access to the record, including the creator. This results in an access rights error during creation.

This issue does not occur when modifying an existing task because, after creation, the creator is automatically added as a follower. As a follower, the creator retains access to the task even if it has no project and no assigned users.

Fix (implemented):
Tasks that have no assigned users and are not linked to any project (private tasks) did not make sense, as they were effectively assigned to nothing.
To address this, we now require at least one user to be assigned to a task when it is not attached to a project.  This change was made inside of the "project_task_view.xml" file in the "view_task_form_2" record


Versions : 17.0 -> master
Task [5403926](https://www.odoo.com/odoo/project/4105/tasks/5403926)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#task#project#access

[FIX] l10n_vn_edi_viettel: wrong exchange rate when issue foreign currency invoice

PR #241061

Core17.0l10n_vn_edi_viettelMedium

This update corrects a bug where the system was rejecting Vietnamese VAT invoices due to excessively long exchange rate numbers. The fix rounds exchange rates to two decimal places, aligning with documentation requirements and ensuring invoices can be properly processed. This prevents invoice creation errors and improves the accuracy of financial reporting.

Original PR description

* STEP TO REPRODUCE: create USD invoice to issue sinvoice, have currency
rate like 26337.9186666777 , when issue we will get error because too
many decimal

* SOLUTION: round exchange rate up to 2 decimal because documentation
said that is maximum

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

#vat#invoice#currency#vietnam

[FIX] hr_contract_salary: prevent access to expired or fully-signed offers

PR #101834

Enterprise17.0hr_contract_salaryMedium

This update fixes a potential issue where expired or fully-signed job offers could be accessed, leading to incorrect offer states. The system now prevents access to these offers, ensuring data integrity and a smoother applicant experience. An SQL constraint has been added to enforce valid offer validity periods.

Original PR description

This commit improves the offer validation logic to avoid invalid or unintended
signature attempts.

Fixes included:
- Block access to offers that are already fully signed, preventing applicants
  from reopening the link and unintentionally reverting the offer to a partially
  signed state.
- Add an SQL constraint on the `validity` field to disallow negative values,
  ensuring that expired/invalid offers cannot be accessed due to incorrect
  validity data.

These changes ensure that expired or fully processed offers no longer expose
active signature links and that offer validity is consistently enforced at the
database level.

task-5405456

#offers#contracts#validation

[FIX] website_sale, adding website_id in portal controller

PR #235954

Core17.0website_saleMedium

This update resolves an issue where customers on one website could access and pay with payment providers configured for a different website. The fix ensures that payment provider compatibility is correctly filtered based on the customer's website, preventing incorrect payment options from appearing in the sales portal. This improves the customer experience and ensures accurate payment processing.

Original PR description

[FIX] website_sale, adding website_id in portal controller

Version: 17.0+e

Steps to reproduce
------------------
The database has two different websites.

A payment provider is enabled for just one of them (website1).

When a sale order is created on the sales app and the customer accesses it in its portal on the website2, he is able to pay with the payment provider which is only enabled on website1.

The problem also occurs when previewing the customer’s portal view.

Why it's happening
------------------
When accessing an order via “/my/orders/<int:order\_id>”, the portal_order_page method calls _get_compatible_providers without passing the website_id. The overriding logic in website_payment then defaults to considering all activated payment methods as compatible, regardless of website restrictions.

As no website_id is provided, the overriding method from the payment_provider extension in website_payment module considers every activated payment methods as compatible.

The Fix
-------
We now add the current website's id to the method if none has been added before.


opw-5172444, “Payment provider visible on sales order portal"


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

[FIX] l10n_es_edi_verifactu_pos: ensure qr-code is present on order reprint

PR #240359

Core17.0l10n_es_edi_verifactu_posMedium

This update ensures the Verifactu QR code is consistently included on order reprints within the Spanish POS module. Previously, the QR code was missing after the initial order settlement and reprint. The fix updates the reprint process to always retrieve and include the QR code data, improving compliance and accuracy of printed receipts.

Original PR description

Step to reproduce:
- install `l10n_es_edi_verifactu_pos`
- start pos after switching company for `es`
- settle order, notice verifactu QR code is present in receipt
- from orders menu, reprint the receipt

Observation:
- when we reprint the order, qr code is missing

Cause:
- `l10n_es_edi_verifactu_qr_code` is not always present in order
- it is added later in `_postPushOrderResolve` hook (hence first time, qr code is present)
- when reprinting the invoice, this method is not called, so it is not printed

Fix:
- patch `ReprintReceiptButton` to always fetch `l10n_es_edi_verifactu_qr_code`
- so data is always present before printing

opw-5403886



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

#pos#es#edi#verifactu#qr code

[FIX] website: fix default height on image gallery

PR #126766

Core17.0websiteMedium

This update resolves an issue where the height of image gallery snippets would unexpectedly reset when images were reordered. The fix removes outdated code and ensures users can set and maintain custom heights for their gallery snippets, providing consistent control over the gallery's appearance. It also includes minor improvements to the carousel item template.

Original PR description

Steps to reproduce

Scenario A

1. Go to Website → drop an Image Gallery snippet → A default height value
appears in the `"Height"` input.

2. Select an image → change its order in the carousel → The snippet height
is automatically reset to `70%` of the screen height.

Scenario B

1. Change the height value of the snippet from the `"Height"` option.

2. Select an image → change its order in the carousel → The snippet
height is again reset (and the option value is overridden).

Issue

The original height behavior was introduced in [1] to make the slideshow
mode auto-adapt to `70%` of the viewport height.

This diff also removed height CSS for other modes where the height
should depend on the content [2]

Subsequent adaptations:

[3] added a default height (`500px`) in XML,

[4] removed it during a design refactoring,

[5] restored the possibility to control the height of the image gallery
snippet using the `"Height"` option.

Keeping the same JS logic that forces the snippet height, led to the
behavior explained above: even when the user manually sets a height, any
action triggering `slideshow()` (e.g., image reorder) forces the height
back to 70% of `window.innerHeight`.

Fix

1. Remove the outdated JS code that automatically updates the height.

2. Keep the slideshow behavior consistent with [2] by excluding it from
the height CSS removal logic.

The snippet now starts with a default height and only changes when
edited through the `"Height"` input.

Additional fixes

This commit also fixes a few minor issues in the new carousel items
template introduced in [4]: items having an `"undefined"` class, and a
missing margin style in the main snippet template.

[1]: https://github.com/odoo/odoo/commit/239b6bc0b5a2a644486737f2b0b71e7e6c0a2edf
[3]: https://github.com/odoo/odoo/commit/9069d0127c176317436b67b23ae5677dd9d53de7
[4]: https://github.com/odoo/odoo/commit/9042b1cae7b630b20e0670788b7a4ed9e4c97609
[5]: https://github.com/odoo/odoo/commit/d5d138e833344e857a420d865d4b12f1acdb0e7c

task-3414281

When users would follow the following step as they are makeing a private task, they would be hit by an incorrect access error. Steps to reproduce: 1.Open the form view to create a new task. 2.Clear the Project field. When empty, it should display the Private placeholder. 3.Ensure no user is assigned to the task. 4.Create the private task. 5.An access rights error occurs, stating that the user does not have permission to create the record. ⚠️ Note: This access rights error only occurs when the task is created directly as private. If a task is created normally and then its project_id and user_ids are removed afterward, no access rights error occurs. Root cause: When a task is created without a project_id and without assigned users, Odoo checks access rights on creation. Since no project members or assigned users exist, no user has access to the record, including the creator. This results in an access rights error during creation. This issue does not occur when modifying an existing task because, after creation, the creator is automatically added as a follower. As a follower, the creator retains access to the task even if it has no project and no assigned users. Fix (implemented): Tasks that have no assigned users and are not linked to any project (private tasks) did not make sense, as they were effectively assigned to nothing. To address this, we now require at least one user to be assigned to a task when it is not attached to a project. This change was made inside of the "project_task_view.xml" file in the "view_task_form_2" record Versions : 17.0 -> master Task [5403926](https://www.odoo.com/odoo/project/4105/tasks/5403926) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

* STEP TO REPRODUCE: create USD invoice to issue sinvoice, have currency rate like 26337.9186666777 , when issue we will get error because too many decimal * SOLUTION: round exchange rate up to 2 decimal because documentation said that is maximum 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 commit improves the offer validation logic to avoid invalid or unintended signature attempts. Fixes included: - Block access to offers that are already fully signed, preventing applicants from reopening the link and unintentionally reverting the offer to a partially signed state. - Add an SQL constraint on the `validity` field to disallow negative values, ensuring that expired/invalid offers cannot be accessed due to incorrect validity data. These changes ensure that expired or fully processed offers no longer expose active signature links and that offer validity is consistently enforced at the database level. task-5405456

[FIX] website_sale, adding website_id in portal controller Version: 17.0+e Steps to reproduce ------------------ The database has two different websites. A payment provider is enabled for just one of them (website1). When a sale order is created on the sales app and the customer accesses it in its portal on the website2, he is able to pay with the payment provider which is only enabled on website1. The problem also occurs when previewing the customer’s portal view. Why it's happening ------------------ When accessing an order via “/my/orders/<int:order\_id>”, the portal_order_page method calls _get_compatible_providers without passing the website_id. The overriding logic in website_payment then defaults to considering all activated payment methods as compatible, regardless of website restrictions. As no website_id is provided, the overriding method from the payment_provider extension in website_payment module considers every activated payment methods as compatible. The Fix ------- We now add the current website's id to the method if none has been added before. opw-5172444, “Payment provider visible on sales order portal" --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Step to reproduce: - install `l10n_es_edi_verifactu_pos` - start pos after switching company for `es` - settle order, notice verifactu QR code is present in receipt - from orders menu, reprint the receipt Observation: - when we reprint the order, qr code is missing Cause: - `l10n_es_edi_verifactu_qr_code` is not always present in order - it is added later in `_postPushOrderResolve` hook (hence first time, qr code is present) - when reprinting the invoice, this method is not called, so it is not printed Fix: - patch `ReprintReceiptButton` to always fetch `l10n_es_edi_verifactu_qr_code` - so data is always present before printing opw-5403886 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Steps to reproduce Scenario A 1. Go to Website → drop an Image Gallery snippet → A default height value appears in the `"Height"` input. 2. Select an image → change its order in the carousel → The snippet height is automatically reset to `70%` of the screen height. Scenario B 1. Change the height value of the snippet from the `"Height"` option. 2. Select an image → change its order in the carousel → The snippet height is again reset (and the option value is overridden). Issue The original height behavior was introduced in [1] to make the slideshow mode auto-adapt to `70%` of the viewport height. This diff also removed height CSS for other modes where the height should depend on the content [2] Subsequent adaptations: [3] added a default height (`500px`) in XML, [4] removed it during a design refactoring, [5] restored the possibility to control the height of the image gallery snippet using the `"Height"` option. Keeping the same JS logic that forces the snippet height, led to the behavior explained above: even when the user manually sets a height, any action triggering `slideshow()` (e.g., image reorder) forces the height back to 70% of `window.innerHeight`. Fix 1. Remove the outdated JS code that automatically updates the height. 2. Keep the slideshow behavior consistent with [2] by excluding it from the height CSS removal logic. The snippet now starts with a default height and only changes when edited through the `"Height"` input. Additional fixes This commit also fixes a few minor issues in the new carousel items template introduced in [4]: items having an `"undefined"` class, and a missing margin style in the main snippet template. [1]: https://github.com/odoo/odoo/commit/239b6bc0b5a2a644486737f2b0b71e7e6c0a2edf [3]: https://github.com/odoo/odoo/commit/9069d0127c176317436b67b23ae5677dd9d53de7 [4]: https://github.com/odoo/odoo/commit/9042b1cae7b630b20e0670788b7a4ed9e4c97609 [5]: https://github.com/odoo/odoo/commit/d5d138e833344e857a420d865d4b12f1acdb0e7c task-3414281