Monday, January 26, 2026
20 changes · 19.0
Enhancements to existing features
This update improves how product prices are displayed in Odoo by adding a new method. This allows for more flexible and customizable price label formatting, ensuring consistent and accurate pricing information for customers. This change was approved through a legal agreement and is a standard improvement to the product.
Original PR description
Add `_get_price_label_base_str()` method in order to exend it @Tecnativa --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243861
Resolved issues and error corrections
This update resolves an issue that occurred during Odoo upgrades when the l10n_id module was installed. The migration script was incorrectly creating extra tax lines, leading to errors. This fix ensures a smoother upgrade process and prevents data inconsistencies.
Original PR description
Encountered an issue during upgrade from v16 with existing l10n_id installed on the DB. The script will try to force create the tax and create extra `repartition_line_ids` which is causing multiple "base" line to be added and trigger the `ValidationError`. Upgrade request: [3442445](https://upgrade.odoo.com/odoo/request/3442445) Upgrade task: [5314508]( https://www.odoo.com/odoo/70/tasks/5314508) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237897
This update fixes a bug preventing the login date from being correctly recorded for users authenticating via LDAP. Previously, the system didn't track when LDAP users logged in, now the 'Latest Authentication' field in user profiles accurately reflects the login timestamp. This ensures accurate user activity tracking.
Original PR description
## Summary This PR fixes a bug where the `login_date` field is not updated when users authenticate via LDAP. **Fixes:** #244847 ## Problem When a user logs in via LDAP authentication, the…
## Summary
This PR fixes a bug where the `login_date` field is not updated when users authenticate via LDAP.
**Fixes:** #244847
## Problem
When a user logs in via LDAP authentication, the `login_date` (Latest Authentication) field remains empty or keeps its old value. This happens because the `_login` method in `auth_ldap` returns early after successful LDAP authentication, bypassing the standard call to `_update_last_login()` that normally happens in the base `res.users` implementation.
## Technical Analysis
In `addons/auth_ldap/models/res_users.py`, the `_login` method:
1. Catches `AccessDenied` from the base implementation
2. Attempts LDAP authentication
3. On success, immediately returns the auth dictionary
This bypasses `user._update_last_login()` which is called in `odoo/addons/base/models/res_users.py` after credential verification.
## Solution
Modified the LDAP login flow to:
1. Extract `uid` from `_get_or_create_user()`
2. Call `_update_last_login()` on the user before returning
3. Return the auth dictionary with the extracted `uid`
```python
uid = Ldap._get_or_create_user(conf, login, entry)
# Update last_login as it would be done in base _login method
user = self.env['res.users'].browse(uid)
user.with_user(user)._update_last_login()
return {
'uid': uid,
'auth_method': 'ldap',
'mfa': 'default',
}
```
## Testing
Added a test assertion to verify that a `res.users.log` entry is created after LDAP login, which populates the `login_date` field.
## Steps to Verify
1. Install `auth_ldap` module
2. Configure a valid LDAP server
3. Log in with an LDAP user
4. Check Settings > Users & Companies > Users
5. ✅ The "Latest Authentication" field should now show the login timestamp
---
[Gittensor contribution - GlobalStar117]This update resolves an issue where applying text colors to lists in the HTML editor didn't correctly color the list markers. The fix ensures that text color classes remain on list items, resulting in consistent and accurate color matching for list markers. This improves the overall user experience when formatting lists.
Original PR description
### Steps to reproduce: - Create a list and type some text. - Press Ctrl + A and apply a text color from the toolbar. - Observe that the list marker is not colored. ### Description of the issue/feature this PR addresses: - `getFonts` looked for the closest element with a text color class, and this also matched `<li>` elements. When a `<li>` was selected, its text color class was removed and moved to a new <font> element created inside the `<li>`. - As a result, the color class was removed from the list item itself, which broke list marker coloring. ### Desired behavior after PR is merged: - Text color classes remain on list item, so list markers are colored correctly. task-5454639 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243005
This update resolves an issue where customer names containing reserved words (like 'constructor') caused errors in reporting. The change uses a safer object creation method to prevent these errors, ensuring customer names can be used without disrupting reporting functionality. This improves data accuracy and reliability.
Original PR description
Steps:
- Have a customer named "constructor" (or any valid json prototype key value)
- Install `sale_management`
- Create a sale order with "constructor"
- Open Reporting -> Customers
- Traceback `Caused by: TypeError: groupedDataPoints[key].push is not a function`
This problem occurs because we use the client name directly in an object, and “constructor” already exists in all objects but is not initialized correctly, which raises a traceback.
One solution is to use `let object = Object.create(null)` instead of `let object = {}`, which prevents inheritance of `Object.prototype` properties.
https://github.com/odoo/odoo/blob/5e74f04ff35ed3efa25be295567be41f42024692/addons/web/static/src/views/graph/graph_model.js#L451-L457
opw-5474691
Forward-Port-Of: odoo/odoo#245369
Forward-Port-Of: odoo/odoo#245206This update resolves issues with the Point of Sale tour testing process, ensuring it consistently functions correctly. It includes improvements to the tour's navigation and fixes a generic dialog title, enhancing the user experience. These changes contribute to a more reliable and user-friendly Point of Sale system.
Original PR description
In this commit, we add few steps in the tour to ensure the tour take always the good way. Few python assertions between has been added to know where the unit test fails (easier to debug). We take advantages of this commit to fix few utils: - Dialog.cancel() was too generic. We add at least title to let the possibility to be more precise. - selectPresetTimingSlotHour() has been fixed to wait the good triggers in the DOM before the tour continues. runbot-error-id 237756 runbot-error-id 237762
This update resolves a technical issue where employee payroll fields were incorrectly marked as editable. The change ensures that employee versions align with the version settings for readonly fields, preventing unintended modifications and maintaining data integrity. This improves the reliability of payroll calculations.
Original PR description
There was an inconsistency on readonly for fields between version and employee. This removes "readonly=False" on employee for fields that are readonly on the version. Runbot error: 230983 Forward-Port-Of: odoo/enterprise#100575
This update allows users to specify splitting values using dashes (e.g., '1-2-3') in the website sale process. Previously, this format wasn't supported, limiting flexibility. This change enhances the user experience by providing a more intuitive way to define split quantities.
Original PR description
Enable the use of values with dashes. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the Link Tracker module would fail to save records when a URL was entered in the 'Code' field. The fix ensures that URLs entered in this field adhere to Odoo's URL validation rules, preventing the error and allowing users to correctly save link tracker records. This improves the reliability of the Link Tracker functionality.
Original PR description
Saving a link tracker record fails when the user enters a URL in the Code field. Steps to reproduce the error: - Install ``link_tracker`` module - Create a new link tracker record with Target Link >…
Saving a link tracker record fails when the user enters a URL in the Code field. Steps to reproduce the error: - Install ``link_tracker`` module - Create a new link tracker record with Target Link > Save - Edit the record and set Code: ``https://demo.com`` > Save Traceback: ```py ValueError: Extra URL must use same scheme and host as base, and begin with base path ``` https://github.com/odoo/odoo/blob/af4365421bc7ba990420789c12c98270d723fa1a/addons/link_tracker/models/link_tracker.py#L77 After this commit: https://github.com/odoo/odoo/commit/977e62d91f3e8235e251e9d21b08f53db1856c6b, When the user sets the code as ``https://demo.com``, Error will be raised from [1], because the extra URL must use same scheme and host as base, and must begin with the base path. [1]: https://github.com/odoo/odoo/blob/af4365421bc7ba990420789c12c98270d723fa1a/odoo/tools/urls.py#L55-L58 sentry-7022131826 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a visual issue where product attribute sections with single values displayed incorrectly. The change refines a CSS selector to ensure the attribute section is only hidden when appropriate, resolving empty borders and improving the overall product display. This ensures a cleaner and more professional look for product pages.
Original PR description
Before this commit, when a product attribute with display_type 'pills' has only one non-custom value, the parent li.variant_attribute is correctly hidden. However, the CSS :has() selector still matched the inner li.o_variant_pills, causing the attributes section to display with empty borders. This commit refines the selector to only match pills outside of variant_attribute elements (UOM pills). task-5852515 | Current (19.0) | After | |--------|--------| | <img width="809" height="395" alt="image" src="https://github.com/user-attachments/assets/64519161-e552-492f-b010-d1353b07f80a" /> | <img width="809" height="395" alt="image" src="https://github.com/user-attachments/assets/6022e371-18eb-4d2a-99d0-da3c94b291d0" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where multiple schedulers within Odoo were sometimes incorrectly assigning the same project plan. The change ensures that each scheduler correctly identifies and uses a unique plan, preventing potential conflicts and ensuring accurate project tracking. This improves the reliability of scheduling workflows.
Original PR description
Description of the issue/feature this PR addresses: Same pattern as in https://github.com/odoo/odoo/pull/189843 but for _compute_plan_id method --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243307
This update fixes a potential issue where a lengthy warning message could inadvertently close unrelated dialogs during the restaurant order closing process. The change replaces a generic closing function with a more targeted approach, ensuring that only the intended warning message is closed, improving the user experience. This prevents disruptions and ensures a smoother order completion.
Original PR description
Before this commit, the function closePrintingWarning use Dialog.confirm() that is a generic function to close a dialog by clicking on .btn-primary. This function can thus close an other unwanted modal (because warning can take a very long time to appears). Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where refund orders incorrectly displayed positive prices in reports. The fix ensures that refund order prices are accurately reflected in reporting, preventing misrepresentation of financial transactions. Starting with version 19.0, refund orders are now handled correctly.
Original PR description
When doing a refund the price is positive in the reporting. Steps to reproduce: ------------------- * Open pos session * Make an order * Refund the order * Go backend and look at the order reporting > Observation: if the product sold was 100$, the report shows 200$ in positive Why the fix: ------------ orderSign exist only in the js side resulting in values to be positive. We know multiply the prices in the report by 1 or -1 if the order is a refund or not. This fix works because starting from 19.0 pos refund orders cannot have anything else than refund product. opw-5483471
This update fixes an error in how Odoo calculates resource working hours. Previously, hours were summed, which resulted in inaccurate totals. Now, the calculation is based on the actual duration of each shift, ensuring more precise hour tracking for resources. A new test has been added to verify this correction.
Original PR description
previous behavior: - total duration (hours/week) is computed as sum of `hour_to - hour_from` for each line current behavior: - made hours duration computed depending on the duration of each line instead of `hour_to - hour_from` (because the correct `hour_to` and `hour_from` get computed afterwards) - added a test for duration based calendar to check if `hours_per_week` is computed correctly task-id: task-5059812
This update resolves a visual glitch in the time-off interface for Belgian employees. Previously, sickness relapse fields appeared unexpectedly after approving time off. The fix adjusts the layout to properly position these fields, ensuring a consistent and user-friendly experience.
Original PR description
Bug production steps: Select employee works in Belgium company, go to timeoff and approve >= 1 months time off and select new timeoff after 1-2 days and there Sickness Relapse fields occur in the shifted UI. Bug cause: The field sickness_relapse added after attach file part, before there was label for the attach file part and it was occupying 2 columns, after removing column it occupies only 1 and the first part of the boolean sickness relapse fields come next to the attach file part. Bug solution: Make the colspan 2 for the attach file part, by that way the sickness_relapse will start from the below line. task - 5493425 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 Forward-Port-Of: odoo/odoo#243753
This update fixes an issue where the tax code (9) was missing from Datev exports for expense journal entries when using 19%I tax. The problem stemmed from how payment amounts were aggregated during the export process. This ensures accurate tax reporting for German companies when exporting financial data to Datev.
Original PR description
Currently, when using 19%I tax in vendor bills, the tax code (9) is shown correctly in the BU-Schlüssel section of the datev export. This however is not the case for expense journal entries. Steps to reproduce: - With DE Company setup - Create an Expense as follows: - Included taxes: 19% I - Paid by: Company - Create report > Submit to Manager > Approve > Post Journal entries - Open General Ledger and export Datev Data Issue: Tax code will be missing from the exported entry. This occurs because, when processing payment move lines, amounts and accounts are aggregated, losing track of the source tax. opw-5388791 Forward-Port-Of: odoo/enterprise#105435 Forward-Port-Of: odoo/enterprise#102548
This update resolves an issue where image snippets weren't consistently updating across the website builder. The fix ensures that the correct image element is always used when processing snippets, leading to more reliable image display and functionality. This improves the user experience when adding images to website pages.
Original PR description
[FIX] html-builder, *: update snippet at each snippet dropped handler *: website In the `ImageSnippetOptionPlugin`, at the `on_snippet_dropped_handlers` call, the `snippetEl` received as argument is replaced by the image selected by the user in the media dialog. The problem is that the call to subsequent handlers is done with `snippetEl` that is not an element of the DOM anymore. This commit fixes this by updating `snippetEl` if needed after each call to a `on_snippet_dropped_handlers` handler. task-5785233 Forward-Port-Of: odoo/odoo#243766
This update fixes a bug where tax return names and status indicators weren't correctly translated when a new language was installed in Odoo. The solution automatically generates translations for all existing tax return names upon language installation, ensuring consistent and accurate reporting across multiple languages. This improves the user experience for international users.
Original PR description
**Commit 1:** [FIX] account_reports: translation of account returns states Steps to reproduce: - Open the tax returns - Set an account opening date to generate some returns - Add another language to…
**Commit 1:** [FIX] account_reports: translation of account returns states Steps to reproduce: - Open the tax returns - Set an account opening date to generate some returns - Add another language to the database and select it -> The states of the returns (the little bubble in the kanban cards) aren't translated even though the translation is present in the pot and po files. **Commit 2:** [FIX] account_reports: translation of date in returns title Steps to reproduce: - Have 2 languages on the db - Generate the tax returns by going to Accounting/Tax Returns and set the opening date - Switch to the second language -> The period displayed in the name of each return isn't translated **Commit 3:** [FIX] account_reports: translate account returns name after lang installation Steps to reproduce: - Generate the tax returns by going to Accounting/Tax Returns and set the opening date - Install another language -> The names of the returns aren't translated in the new language. Solution: When installing a new language, generates the translation of the title for all existing returns task-5421659
This update resolves a visual issue where the camera button displayed a warning message for channels that didn't require camera access. Now, the warning is only shown for channels configured for video-full-screen mode, streamlining the user experience and avoiding unnecessary alerts for typical voice calls.
Original PR description
Only channels that have cameraPermission of `prompt` should show the red and warning. If the permission is `denied` or `granted`, no badge should be shown. task-5263066 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This pull request corrects a technical error where the Greek language code was incorrectly identified as 'gr'. It also adds missing translation modules for Cyprus and Greece, ensuring that Odoo supports these languages correctly. This improves the user experience for customers and partners who speak Greek.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245524 Forward-Port-Of: odoo/odoo#244684