Daily updates from Odoo
Friday, January 23, 2026
198 changes
11 changes
Resolved issues and error corrections
This update corrects a problem where the avatar card didn't accurately display the user's local time when viewing from different time zones. The fix ensures that the avatar card correctly reflects the user's timezone, improving the user experience across different locations. This was a minor bug impacting how users perceive time-sensitive information.
Original PR description
The `Avatar card shows local timezone` ensure partner local time is shown in the avatar card when the user that consults it has a different tz. This test also ensures that nothing is shown when timezone are the same. However, the assertion expects to find the node containing the text in the DOM while it's not rendered when both tz are the same. This commit fixes the issue. runbot-238383 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 role mentions would disappear when editing messages in Odoo. The fix ensures that role mentions are correctly preserved during the editing process, improving communication and collaboration within the system. This resolves a previous bug that prevented users from accurately referencing team members in their messages.
Original PR description
**Current behavior before PR:** Editing a message with a role mention would cause the mention to be lost. **Desired behavior after PR is merged:** Role mentions are now preserved when editing a message. task-4702960 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245080 Forward-Port-Of: odoo/odoo#218992
This update fixes an issue where keyboard navigation within the website builder's image cropping tool was unreliable. Now, users can properly validate or dismiss the cropper using keyboard shortcuts (Enter/Escape), improving the user experience and accessibility. This ensures a smoother workflow for editing website images.
Original PR description
Steps to reproduce: - Select an image in the website builder. - Open the cropping tools. - Press Enter. - Try to discard the cropper. Before this commit, focus stayed on the toolbar crop button so `Enter` opened another cropper, `Escape` closed the sidebar, and the cropper buttons were not reachable via keyboard. After this commit, the cropper grabs focus and handles `Enter/Escape` itself so keyboard interactions validate or dismiss the cropper. task-5432043 Forward-Port-Of: odoo/odoo#244484 Forward-Port-Of: odoo/odoo#240910
This update prevents duplicate 'Applicant created' messages appearing in the recruitment chatter when a new applicant is added. The previous system was creating the same log entry multiple times, leading to a cluttered view. This change ensures a cleaner and more accurate record of applicant creation events.
Original PR description
Steps to reproduce: 1. Create a new applicant in recruitment. 2. Open the applicant’s chatter. 3. See multiple “Applicant created” messages for the same creation. Bug cause: The applicant creation flow posts the `mt_applicant_new` subtype more than once (create + extra write/track), and the frontend renders the subtype description, so each duplicate post shows “Applicant created” again. Solution: - Post the `mt_applicant_new` subtype only once during applicant creation. - Avoid re-posting it in subsequent writes/tracking so chatter shows a single creation log. Task Id: 5454691 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 test bank statement imports created actual records in the database, even when the test failed. The change ensures that test imports don't trigger reconciliation processes, preventing unintended data creation. This improves the reliability of the test environment.
Original PR description
**Steps to reproduce:** - Install Accounting - Go to Accounting dashboard 1) - On "Bank" journal card, select "Import File" option in dropdown menu - Upload a file containing a lot of statements…
**Steps to reproduce:**
- Install Accounting
- Go to Accounting dashboard
1) - On "Bank" journal card, select "Import File" option in dropdown menu
- Upload a file containing a lot of statements (e.g. more than 170)
- Test the import with "Test" button
2) - Open "Bank" journal
- Select "Import records" in the cog menu
- Upload a file containing a lot of statements (e.g. more than 170)
- Test the import with "Test" button
3) - Open "Bank" journal
- Click on "Upload" button
- Upload a file containing a lot of statements (e.g. more than 170)
- Test the import with "Test" button
**Issue:**
The issue happens when the test import fails.
Even if it was a test, all the records are created in the database.
**Cause:**
During a test import the records should not be reconciled after creation.
However, by default, "auto_statement_processing" property is True and trigger the reconciliation.
When an error is raised during the test import, a rollback is made on a previous savepoint.
But a commit can be done in "_cron_try_auto_reconcile_statement_lines" method, which results in the records being created for real.
**Solution:**
Set "auto_statement_processing" property to False for Test import.
For use case 1) and 2), we make sure that we follow the same flow than use case 3).
opw-5436937
Forward-Port-Of: odoo/enterprise#104954This update fixes an issue where link styles within the HTML Editor were not consistently inheriting font sizes. Now, links automatically inherit the font size from their parent elements, creating a more visually aligned and user-friendly experience. This change prepares for a future update that will remove a specific styling variable, simplifying the design.
Original PR description
Ensure that a simple link can inherit from an ancestor `font-size` defined using the Editor toolbar, overriding the `mass_mailing` Design Tab `--link-font-size` special variable. That variable will be removed in the future, because it is more natural that a link font-size is aligned with its container. task-5868086 Forward-Port-Of: odoo/odoo#245225
This update ensures that admin users retain their intended default options when reviewing courses, regardless of edits or deletions made by other users. This prevents unintended changes to review settings and maintains a consistent experience for administrators. The change was previously addressed in another PR but has been re-implemented to avoid code duplication.
Original PR description
*: website_slides The default values for the admin user should not be changed by editing or deleting others' messages in courses. task-5326273 Forward-Port-Of: odoo/odoo#245127 Forward-Port-Of: odoo/odoo#236475
This update resolves an issue where the invite input field automatically gained focus, disrupting other dialogs like the call permission dialog. Now, the input only focuses when it's active and the user is interacting with the system. The code has also been reorganized for better testing.
Original PR description
**Current behavior before PR:** - The invite input always tried to autofocus, in turn stealing focus from dialogs like the call-permission dialog. **Desired behavior after PR is merged:** - Autofocus only when the input exists and the context is active. - Moved `mockPermissionsPrompt` to `mail_test_helpers`. **Part of task-**[5227387](https://www.odoo.com/odoo/project/1519/tasks/5227387) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236248
This update improves the speed at which scale readings are delivered, particularly in Point of Sale (PoS). By directly returning the scale result upon the initial action, the system now provides weight data immediately when the 'get weight' button is pressed. This enhances the user experience and efficiency.
Original PR description
In order to get the first scale weight faster, we now return the result directly on the action call. This also fixes the get weight button in PoS as it will now actually provide the weight.
A recent test for our live chat feature was intermittently failing due to a timing issue during high load. This change increases the test's waiting period to ensure it correctly identifies the expected behavior. This improves the reliability of our live chat testing process.
Original PR description
The `Only two quick actions are shown` live chat test awaits the first posted message because to avoid conflict with the reaction being added afterwards. To do so, the test uses the `waitForSteps` helper. However, during high load, 200ms might be too short to receive the notification, leading to the test failing. This commit increases the timeout. runbot-237587 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 resolves a technical issue that could cause Odoo upgrades to fail when setting up manual one-to-many fields. The fix ensures that Odoo properly checks if the related inverse field is set up before processing, preventing a 'KeyError' and ensuring smoother upgrades. This improves the stability and reliability of Odoo installations.
Original PR description
When ``setup`` a manual one2many field, if its ``inverse_name`` field hasn't been ``setup`` and is also a manual field which might be ``pop`` when ``setup``, the one2many field can be ``setup`` successfully. But when computing ``setup_inverses`` when ``init_models``, the ``inverse_name`` will cause a ``KeyError``. ``invf = registry[self.comodel_name]._fields[self.inverse_name]`` Reproduce: see https://github.com/odoo/odoo/pull/240085 This commit simply checks the ``setup`` for the inverse field of the one2many field. 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#245240
11 changes
New functionality added to Odoo
This update adds support for the Caribbean Guilder (XCG) as a new currency option within Odoo. It’s specifically configured as the default currency for Curaçao and Sint Maarten, expanding Odoo’s currency coverage to include these regions. This allows users to accurately record financial transactions in XCG.
Original PR description
Introduce the Caribbean Guilder (XCG) as an available currency and set it as the default currency for Curaçao and Sint Maarten. Related PR-https://github.com/odoo/enterprise/pull/104404 taskID-5490423 Forward-Port-Of: odoo/odoo#243955
This update introduces support for the Caribbean Guilder (XCG) currency within Odoo Enterprise. It sets XCG as the default currency for Curaçao and Sint Maarten, aligning our financial data with local business practices. This change improves reporting and financial accuracy for users operating in these regions.
Original PR description
Align enterprise currency data with the community with addition of new currency XCG. Related PR-https://github.com/odoo/odoo/pull/243955 taskID-5490423 Forward-Port-Of: odoo/enterprise#104404
Resolved issues and error corrections
This update corrects a technical error in the Odoo Enterprise payroll system where a function was incorrectly called. The fix ensures that document generation processes within payroll and HR operate smoothly, preventing potential disruptions to payroll processing. This resolves a previously identified issue impacting document creation.
Original PR description
Issue: `_check_create_documents` is called in 'hr_payroll' but only defined in 'documents_hr_payroll' Solution: Create a new method that will be redefined in 'documents_hr_payroll' to call `_check_create_documents` opw-5213979 Forward-Port-Of: odoo/enterprise#105099 Forward-Port-Of: odoo/enterprise#104282
This update fixes a display issue in the appointment calendar for Ukrainian and Polish users. Previously, month names were shown in the genitive case, which is incorrect. The fix ensures month names are displayed in the nominative case, aligning with standard calendar conventions and improving user experience.
Original PR description
In the appointment calendar, the "Month Year" (e.g. January 2026) is displayed at the top of the calendar selector as is standard for calendars. Unfortunately in some languages, the word month word…
In the appointment calendar, the "Month Year" (e.g. January 2026) is displayed at the top of the calendar selector as is standard for calendars. Unfortunately in some languages, the word month word used depends on grammatical situation. Steps to reproduce: - activate Ukrainian (or Polish) language - Preview (i.e. the website view) of any appointment - Change the preview into Ukrainian (or Polish) Expected result: Calendar month at top of calendar is shown in the nominative case: e.g. January 2026 = січень 2026 (in Ukrainian) Actual result: Calendar month is shown in the genitive case (e.g. "of January", as in "the 12th of January): e.g. January 2026 = січня 2026 (in Ukrainian) Fix is to switch from the "MMMM Y" format (i.e. month based on grammar context) to "LLLL Y" (i.e. stand alone month) which will use the correct month case. Ref: https://www.unicode.org/reports/tr35/tr35-dates.html#dfst-month Note that for most languages this won't make a difference since there is usually only 1 way of writing a month. opw-5474705 picture diff (for January 2026): before fix: <img width="1168" height="468" alt="image" src="https://github.com/user-attachments/assets/36754439-e664-40f3-9c5b-7c9c76cd7cca" /> after fix: <img width="1215" height="492" alt="image" src="https://github.com/user-attachments/assets/82f0665e-fe70-4b9f-b1d4-f420b52db38f" /> Forward-Port-Of: odoo/enterprise#104942
This update fixes an issue where the system was creating duplicate vendor bills when receiving the same e-invoice XML twice from an incoming mail server. The fix prevents duplicate bills from being generated, ensuring accurate financial records and avoiding potential errors. This resolves a previous reported problem (opw-5362664, opw-5409700).
Original PR description
Steps to reproduce: - With a CL Company setup - Configure an incoming mail server with DTE server option enabled - In Vendor Bills journal, enable 'Use Documents?' - Receive the same XML twice via the incoming mail server - Check created vendor bills Issue: There will be duplicated bills. Each duplicate will show the message 'E-invoice already exist: nnnnn' However, the system should avoid duplicates from being created. opw-5362664 opw-5409700
This update fixes a potential issue where minor cash differences in Point of Sale reports were incorrectly flagged due to currency rounding. The change ensures that even small discrepancies, caused by rounding, are accurately reflected, preventing the removal of legitimate cash transactions. This improves the reliability of financial reporting within Point of Sale.
Original PR description
Before this commit, when calculating the cash difference in the report, the code did not account for currency rounding. This could lead to situations where a very small cash difference, due to rounding errors, was not recognized as zero, resulting in the unintended removal of cash moves. opw-5489958 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245251
This update addresses a technical issue preventing Odoo from correctly importing a key exception class within the Requests library. The change, made by updating Requests to version 2.25.1, resolves a removal of this exception from the Requests package, ensuring Odoo continues to function smoothly. This fix impacts several Odoo modules.
Original PR description
Installing `requests==2.25.1` and using the following line of code:
from requests.exceptions import JSONDecodeError
It raises the following error:
ImportError: cannot import name 'JSONDecodeError' from 'requests.exceptions' (python3.10/site-packages/requests/exceptions.py)
It was removed from the following commit in the `requests` package:
https://github.com/psf/requests/commit/db575eeedcfdb03bf31285afd3033e301df8b685
This change fixes this error importing the original exception from `json` package
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#245075This update resolves an issue where internal users without sales permissions would encounter errors when accessing their sales orders through the /my page. The change mirrors a previous fix and ensures a smoother experience for all users, regardless of their access level. This improves stability and prevents potential disruptions to sales workflows.
Original PR description
Avoid error when internal user (no sale permissions) see Orders at /my Similar to https://github.com/odoo/odoo/commit/5ebab949a06ec338cc28e912317a74bbfb3fe6ac @Tecnativa TT60025 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245039
This update ensures that when a new partner is created during a shared sign request, the partner's name is automatically set to the signer's name, rather than using their email address. This improves data accuracy and consistency for shared agreements, simplifying record-keeping.
Original PR description
Version: - saas-18.2 Steps to reproduce: - Create a shared sign request. - Open the shared signing link and complete the signature process. - During signing, a new partner gets created for the signer if not already exists. Before: - When the user signs the shared sign request and a new partner is created, the partner name is not set and email is used as name. After: - Now, when a user signs a shared sign request and a new partner is created, the system automatically sets the partner name using the signer name. task-5776339 Forward-Port-Of: odoo/enterprise#105232 Forward-Port-Of: odoo/enterprise#104869
This update resolves an issue where the system was unnecessarily creating duplicate snapshots during the transmission of ELM data for Swiss payroll. The change ensures that a snapshot is only created if one doesn't already exist, streamlining the process and preventing potential data inconsistencies. This improves the reliability of payroll reporting in Switzerland.
Original PR description
Forward-Port-Of: odoo/enterprise#105135
This update corrects a technical issue related to how payments are processed in the HR payroll system. The fix ensures that multiple payment moves are handled correctly during registration, improving the reliability of payment processing. This change enhances the overall stability of the system.
Original PR description
There was an error where we weren't batching when we were selecting several moves at the same time when registering a payment. We fixed that and this test needs to be adapted. Forward-Port-Of: odoo/enterprise#104727
10 changes
New functionality added to Odoo
This update adds support for the Caribbean Guilder (XCG) as a new currency option within Odoo. It's specifically configured for use in Curaçao and Sint Maarten, expanding Odoo's currency capabilities to better serve businesses operating in these regions. This change allows for accurate financial reporting and transactions involving these currencies.
Original PR description
Introduce the Caribbean Guilder (XCG) as an available currency and set it as the default currency for Curaçao and Sint Maarten. Related PR-https://github.com/odoo/enterprise/pull/104404 taskID-5490423 Forward-Port-Of: odoo/odoo#243955
This update introduces support for the Caribbean Guilder (XCG) as a new currency option within Odoo Enterprise. It's now the default currency for Curaçao and Sint Maarten, aligning our financial data with local standards. This change improves reporting and transaction accuracy for businesses operating in these regions.
Original PR description
Align enterprise currency data with the community with addition of new currency XCG. Related PR-https://github.com/odoo/odoo/pull/243955 taskID-5490423 Forward-Port-Of: odoo/enterprise#104404
Resolved issues and error corrections
This update ensures that new partners created during shared sign requests automatically use the signer's name instead of their email address. This provides a more accurate and user-friendly experience when managing signers within the system. Previously, the system defaulted to using email as the partner name, which could lead to confusion.
Original PR description
Version: - saas-18.2 Steps to reproduce: - Create a shared sign request. - Open the shared signing link and complete the signature process. - During signing, a new partner gets created for the signer if not already exists. Before: - When the user signs the shared sign request and a new partner is created, the partner name is not set and email is used as name. After: - Now, when a user signs a shared sign request and a new partner is created, the system automatically sets the partner name using the signer name. task-5776339 Forward-Port-Of: odoo/enterprise#104869
This update fixes a display issue in the appointment calendar for Ukrainian and Polish users. Previously, month names were shown in the genitive case, which was incorrect. The fix ensures month names are displayed in the nominative case, aligning with standard calendar conventions and improving user experience.
Original PR description
In the appointment calendar, the "Month Year" (e.g. January 2026) is displayed at the top of the calendar selector as is standard for calendars. Unfortunately in some languages, the word month word…
In the appointment calendar, the "Month Year" (e.g. January 2026) is displayed at the top of the calendar selector as is standard for calendars. Unfortunately in some languages, the word month word used depends on grammatical situation. Steps to reproduce: - activate Ukrainian (or Polish) language - Preview (i.e. the website view) of any appointment - Change the preview into Ukrainian (or Polish) Expected result: Calendar month at top of calendar is shown in the nominative case: e.g. January 2026 = січень 2026 (in Ukrainian) Actual result: Calendar month is shown in the genitive case (e.g. "of January", as in "the 12th of January): e.g. January 2026 = січня 2026 (in Ukrainian) Fix is to switch from the "MMMM Y" format (i.e. month based on grammar context) to "LLLL Y" (i.e. stand alone month) which will use the correct month case. Ref: https://www.unicode.org/reports/tr35/tr35-dates.html#dfst-month Note that for most languages this won't make a difference since there is usually only 1 way of writing a month. opw-5474705 picture diff (for January 2026): before fix: <img width="1168" height="468" alt="image" src="https://github.com/user-attachments/assets/36754439-e664-40f3-9c5b-7c9c76cd7cca" /> after fix: <img width="1215" height="492" alt="image" src="https://github.com/user-attachments/assets/82f0665e-fe70-4b9f-b1d4-f420b52db38f" /> Forward-Port-Of: odoo/enterprise#104942
This update fixes a potential issue where small cash differences in Point of Sale reports were incorrectly flagged due to currency rounding errors. The change ensures accurate reporting by accounting for these rounding discrepancies, preventing unintended removal of cash transactions. This improves the reliability of financial reporting within Point of Sale.
Original PR description
Before this commit, when calculating the cash difference in the report, the code did not account for currency rounding. This could lead to situations where a very small cash difference, due to rounding errors, was not recognized as zero, resulting in the unintended removal of cash moves. opw-5489958 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245251
This update addresses a technical issue preventing our system from correctly importing a standard Python library. The fix involves updating the `requests` library to a compatible version and importing the necessary exception class. This ensures continued smooth operation of our integrations with external services.
Original PR description
Installing `requests==2.25.1` and using the following line of code:
from requests.exceptions import JSONDecodeError
It raises the following error:
ImportError: cannot import name 'JSONDecodeError' from 'requests.exceptions' (python3.10/site-packages/requests/exceptions.py)
It was removed from the following commit in the `requests` package:
https://github.com/psf/requests/commit/db575eeedcfdb03bf31285afd3033e301df8b685
This change fixes this error importing the original exception from `json` package
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#245075This update removes a restriction that previously limited the use of journal accounts for reconciliation. Previously, certain accounts couldn't be marked as non-reconcilable if they were used as default debit or credit accounts within a journal. This change provides greater flexibility for accounting teams to manage their accounts effectively.
Original PR description
Previously, a constraint prevented accounts from being non-reconcilable if they were used as default debit/credit accounts involved in journals. This behavior is too restrictive. This commit removes the constraint. task-5254202 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244398
This update resolves an issue where internal users without sales permissions would encounter errors when accessing their sales orders through the /my page. The change mirrors a previous fix, ensuring a smoother experience for all users within the Odoo system. This improves overall system stability and usability.
Original PR description
Avoid error when internal user (no sale permissions) see Orders at /my Similar to https://github.com/odoo/odoo/commit/5ebab949a06ec338cc28e912317a74bbfb3fe6ac @Tecnativa TT60025 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245039
This update corrects a technical issue related to the Greek language code in Odoo, ensuring accurate translations and functionality for Greek-speaking users. The team addressed a previously missed configuration, adding the correct language code (`el`) and fixing inconsistencies in translation files, improving the overall user experience for our Greek-speaking customers.
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#244830 Forward-Port-Of: odoo/odoo#244684
This update corrects a technical issue where newly released modules weren't properly included in our translation files (.weblate.json). This meant these modules were initially untranslatable. The changes add the necessary module definitions to the .weblate.json file, guaranteeing they will be available for translation and localization.
Original PR description
Modules added into stable without being properly added to .weblate.json file = never translatable. Forward-Port-Of: odoo/enterprise#104964 Forward-Port-Of: odoo/enterprise#104890
11 changes
New functionality added to Odoo
This update introduces support for the Caribbean Guilder (XCG) as a new currency option within Odoo. It's specifically designated as the default currency for Curaçao and Sint Maarten, expanding Odoo's currency coverage to include these regions. This change allows users to accurately record financial transactions in XCG.
Original PR description
Introduce the Caribbean Guilder (XCG) as an available currency and set it as the default currency for Curaçao and Sint Maarten. Related PR-https://github.com/odoo/enterprise/pull/104404 taskID-5490423 Forward-Port-Of: odoo/odoo#243955
This update introduces support for the Caribbean Guilder (XCG) currency within Odoo Enterprise. It establishes XCG as the default currency for Curaçao and Sint Maarten, aligning our financial data with the broader Odoo community. This change improves reporting and financial management for businesses operating in these regions.
Original PR description
Align enterprise currency data with the community with addition of new currency XCG. Related PR-https://github.com/odoo/odoo/pull/243955 taskID-5490423 Forward-Port-Of: odoo/enterprise#104404
Enhancements to existing features
This update removes a previous restriction that limited the ability to use certain journal accounts for reconciliation. This change provides greater flexibility for users to manage their accounting data and reconcile transactions without limitations. It's a minor improvement that enhances usability.
Original PR description
Previously, a constraint prevented accounts from being non-reconcilable if they were used as default debit/credit accounts involved in journals. This behavior is too restrictive. This commit removes the constraint. task-5254202 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244398
Resolved issues and error corrections
This update fixes a display issue in the appointment calendar for Ukrainian and Polish users. Previously, month names were incorrectly formatted in the genitive case. The fix ensures month names are displayed correctly in the nominative case, aligning with standard calendar conventions and improving user experience for these languages.
Original PR description
In the appointment calendar, the "Month Year" (e.g. January 2026) is displayed at the top of the calendar selector as is standard for calendars. Unfortunately in some languages, the word month word…
In the appointment calendar, the "Month Year" (e.g. January 2026) is displayed at the top of the calendar selector as is standard for calendars. Unfortunately in some languages, the word month word used depends on grammatical situation. Steps to reproduce: - activate Ukrainian (or Polish) language - Preview (i.e. the website view) of any appointment - Change the preview into Ukrainian (or Polish) Expected result: Calendar month at top of calendar is shown in the nominative case: e.g. January 2026 = січень 2026 (in Ukrainian) Actual result: Calendar month is shown in the genitive case (e.g. "of January", as in "the 12th of January): e.g. January 2026 = січня 2026 (in Ukrainian) Fix is to switch from the "MMMM Y" format (i.e. month based on grammar context) to "LLLL Y" (i.e. stand alone month) which will use the correct month case. Ref: https://www.unicode.org/reports/tr35/tr35-dates.html#dfst-month Note that for most languages this won't make a difference since there is usually only 1 way of writing a month. opw-5474705 picture diff (for January 2026): before fix: <img width="1168" height="468" alt="image" src="https://github.com/user-attachments/assets/36754439-e664-40f3-9c5b-7c9c76cd7cca" /> after fix: <img width="1215" height="492" alt="image" src="https://github.com/user-attachments/assets/82f0665e-fe70-4b9f-b1d4-f420b52db38f" /> Forward-Port-Of: odoo/enterprise#104942
This update fixes a technical error in the delivery IoT module that caused tracebacks when confirming print jobs. The issue stemmed from discrepancies between how print jobs are created in the front-end and the backend, particularly with WebSocket confirmations. Additionally, the update ensures compatibility with older IoT devices that don't always provide standard print identification data.
Original PR description
In `delivery_iot`, as reports are fetched in the chatter from the backend, we end up creating one print job in the front end but multiple print jobs can be sent with WebSocket in the backend. We then get a traceback when getting a second confirmation from a print job that has just been deleted from the job list. Additionally, we ensure compatibility with the stable IoT Box, that do not return a `print_id` or `iot_mac`. opw-5464957 Forward-Port-Of: odoo/enterprise#105194
This update fixes a potential issue where small discrepancies in cash reporting were incorrectly flagged as needing removal. The change ensures that currency rounding errors are now accounted for, preventing the unintended removal of legitimate cash transactions and improving the accuracy of cash difference reports. This ensures more reliable financial reporting.
Original PR description
Before this commit, when calculating the cash difference in the report, the code did not account for currency rounding. This could lead to situations where a very small cash difference, due to rounding errors, was not recognized as zero, resulting in the unintended removal of cash moves. opw-5489958 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245251
This update addresses a technical issue preventing Odoo from correctly handling responses from external services. The problem stemmed from a recent change in the 'requests' library, which removed a necessary import. By installing a specific version of 'requests' and importing the correct exception, this error is now resolved, ensuring smooth communication with external systems.
Original PR description
Installing `requests==2.25.1` and using the following line of code:
from requests.exceptions import JSONDecodeError
It raises the following error:
ImportError: cannot import name 'JSONDecodeError' from 'requests.exceptions' (python3.10/site-packages/requests/exceptions.py)
It was removed from the following commit in the `requests` package:
https://github.com/psf/requests/commit/db575eeedcfdb03bf31285afd3033e301df8b685
This change fixes this error importing the original exception from `json` package
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#245075This update corrects a technical detail related to the translation of Odoo's Greek language support. The incorrect language code ('gr') was replaced with the correct code ('el') in the system's configuration files. This ensures accurate translations for Greek-speaking users and maintains the quality of the Odoo platform.
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#244830 Forward-Port-Of: odoo/odoo#244684
This update corrects a previous issue where newly added modules to the stable version of Odoo Enterprise were not correctly marked for translation. This change adds the necessary entries to the .weblate.json file, guaranteeing that these modules will be properly translated and available for all languages. This prevents future translation delays and ensures a complete user experience.
Original PR description
Modules added into stable without being properly added to .weblate.json file = never translatable. Forward-Port-Of: odoo/enterprise#104964 Forward-Port-Of: odoo/enterprise#104890
This update resolves a technical issue where the demo data for the Mexican payroll modules incorrectly set the company and partner names during installation. This prevented proper CFDI stamping of invoices and payment complements in demo databases, ensuring the demo environment functions correctly and aligns with regulatory requirements.
Original PR description
The demo data of the Mexican payroll modules was overriding the company and partner name during installation, which can break the CFDI stamping flow for invoices and payment complements in demo databases. Forward-Port-Of: odoo/enterprise#102558
This update resolves an issue where internal users without sales permissions would encounter errors when accessing their sales orders through the /my page. The change mirrors a previous fix and ensures a smoother experience for all users, regardless of their access level. This improves overall system stability and usability.
Original PR description
Avoid error when internal user (no sale permissions) see Orders at /my Similar to https://github.com/odoo/odoo/commit/5ebab949a06ec338cc28e912317a74bbfb3fe6ac @Tecnativa TT60025 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245039
16 changes
New functionality added to Odoo
This update adds PAN and UAN fields to the employee information section within the Odoo Enterprise salary configuration tool. This change is specifically designed to improve the accuracy of statutory reporting for Indian employees, ensuring compliance with local regulations.
Original PR description
- added PAN and UAN fields to the Personal Information model. - now fields appear under the Personal Information section of the Salary Configurator. - This applies specifically to the Indian Employee Pay structure and helps capture employee statutory details during salary configuration. task-5452379
Enhancements to existing features
This update refines how work entry data is created, ensuring only relevant details are included. This change addresses a need across various Odoo localizations, streamlining data and improving efficiency. It focuses on filtering work entries based on their type, ensuring accurate reporting and management.
Original PR description
This commits adds an optional domain when creating work entries to only include the work details that are `is_work` or that don't have a work_entry_type_id, this is needed by a lot of localizations task-5076624 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update enhances the way users search for property types within the Odoo web interface. The change replaces a dropdown menu with a search-enabled select menu, allowing for faster and more intuitive property type lookups. This improvement streamlines the user experience and improves efficiency.
Original PR description
This commit replaces the property definition type dropdown by a select menu. It allows searching the property type in the input. The select menu now highlights the searched text in the option labels and supports odoomark. task-5226604
This update centralizes the logic for controlling button visibility in the MRP and Repair modules, reducing redundancy and ensuring consistency across the Community and Enterprise versions of Odoo. By standardizing visibility rules, this change simplifies future updates and maintenance, improving overall system stability.
Original PR description
Introduce computed boolean fields to represent the shared visibility conditions for the `Produce` and `Produce All` buttons in MRP and the `End Repair` button in Repair. Enterprise modules now reuse these fields instead of duplicating the logic inside the XML `invisible` attributes. This reduces code duplication, avoids inconsistencies between Community and Enterprise, and makes future overrides simpler and safer. Task ID: 4898373
Resolved issues and error corrections
This update simplifies the HTML code for buttons across several Odoo modules. By removing unnecessary 'role=button' attributes, we've improved the accessibility of the application for users with assistive technologies. This aligns with web standards and ensures a better user experience for everyone.
Original PR description
The `<button>` HTML element has by default the "role", well, "button". No need to specify it again. Reference: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/button_role 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 removes redundant accessibility settings from button elements within Odoo. The HTML standard already defines buttons with the 'button' role, so specifying it again was unnecessary. This change ensures better accessibility and aligns with web standards, improving the user experience for all Odoo users.
Original PR description
The `<button>` HTML element has by default the "role", well, "button". No need to specify it again. Reference: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/button_role
This pull request resolves a bug preventing the tour test for overtime ruleset functionality from running correctly. The fix ensures the test passes, allowing users to properly navigate and understand the overtime ruleset within the HR payroll module. This improves the reliability of the tour testing process.
Original PR description
https://runbot.odoo.com/odoo/runbot.build.error/237877
This update enforces that binary fields in Odoo must store data as bytes, addressing a previous workaround that allowed storing mutable data. This change improves data integrity and prevents unexpected behavior when fields are validated. It impacts various modules where this workaround was utilized.
Original PR description
Description of the issue/feature this PR addresses:
The field is used to sometimes some mutable data because the `convert_to_cache` does not force a particular type. That hack is used in multiple places where instead json files (or another form of cache) could be used.
Current behavior before PR:
```py
res.binary_field = val = {}
res.binary_field["ok"] = 4
assert "ok" in val
```
Desired behavior after PR is merged:
```py
res.binary_field = {} # fail because not bytes (or like bytes)
```
https://github.com/odoo/enterprise/pull/99567
task-4251301
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue where fields.Binary was being used incorrectly, leading to potential data storage inefficiencies. The change ensures fields.Binary is used appropriately for storing binary data, improving data management and reducing storage costs. This impacts several Odoo modules related to exports and data handling.
Original PR description
odoo/odoo#235832
This update fixes an error in how future time off balances are calculated for employees using hourly time off types. Previously, the system incorrectly added hours instead of the expected accrual. The change updates the system to correctly convert accruals from days to hours based on employee schedules, ensuring accurate balance forecasts.
Original PR description
Steps to Reproduce: Create an accrual plan that accrues 2 days monthly, credited at the start of the month. Create a Time Off Type with the Unit of Measure set to Hours. Create an allocation request…
Steps to Reproduce: Create an accrual plan that accrues 2 days monthly, credited at the start of the month. Create a Time Off Type with the Unit of Measure set to Hours. Create an allocation request using the above Time Off Type and Accrual Plan. Open the Time Off dashboard: a. The current available balance is displayed in hours and is correctly computed based on the employee’s working schedule. b. However, when checking the balance for a future date, the system incorrectly adds 2 hours instead of 16 hours (i.e., 2 days converted to hours based on the working schedule). Bug cause: The system incorrectly identified the unit of measure because it was still referencing the request_unit field, which defaults to 'day'. Following a recent refactor where request_unit was replaced by unit_of_measure to define Time Off Type units, this specific logic flow was left unupdated, causing it to be calculated in days instead of hours. Solution: Updated the future leaves calculation logic to use unit_of_measure instead of request_unit. This ensures that when a Time Off Type is configured in hours, accruals defined in days are correctly converted based on the employee's working schedule. Task: 5498292 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where snippet images weren't appearing on the website. The fix corrects the file paths for two key image snippets, ensuring they are correctly displayed to users. This improves the visual quality of the website.
Original PR description
The images in snippets were not displayed due to incorrect source paths. This commit fixes the paths for `s_cta_mockups` and `s_cta_mobile` snippets. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update removes an outdated workaround for cursor styles, simplifying the codebase and ensuring consistent styling across Odoo. The change improves performance and reduces potential compatibility issues as `cursor: grab` is now standard in modern browsers.
Original PR description
*: account, html_builder, html_editor, point_of_sale The `o-grab-cursor` mixin was originally introduced to handle cross-browser compatibility for the `grab` cursor style. Since `cursor: grab` is now widely supported by all modern browsers, the mixin is no longer necessary. This commit removes the mixin definition and replaces all its usages with the standard CSS property.
This update simplifies the Gantt chart's cursor style by removing an older compatibility fix. Modern browsers now support the standard 'grab' cursor, making the previous workaround unnecessary. This change improves the user experience and reduces code complexity.
Original PR description
The `o-grab-cursor` mixin was originally introduced to handle cross-browser compatibility for the `grab` cursor style. Since `cursor: grab` is now widely supported by all modern browsers, the mixin is no longer necessary. This commit removes the mixin definition and replaces all its usages with the standard CSS property. See https://github.com/odoo/odoo/pull/245027
This update ensures that all work details are now included in payroll reports for the Belgian and Hong Kong localization versions of Odoo. This change aligns with a recent update to the core Odoo platform, simplifying reporting and providing a more complete view of employee work history.
Original PR description
Based on odoo/odoo#235425, This commit removes the now-redundant override of `resource.calendar` and since the Belgian Localization is the only one that expects all work entries regardless if the work entry type is a leave or not. This commit also overrides the hook that allows us to remove the filter added on work details. task-5076624
Features or functions removed from Odoo
This update simplifies the way Discuss messages are tracked, removing a redundant feature that impacted reliability and user privacy. The change improves the accuracy of message history and streamlines the 'Seen' indicator, providing a clearer visual representation of message status.
Original PR description
enterprise: https://github.com/odoo/enterprise/pull/104332 upgrade: https://github.com/odoo/upgrade/pull/9269 * = im_livechat, test_discuss_full This commit removes the fetched feature of Discuss…
enterprise: https://github.com/odoo/enterprise/pull/104332 upgrade: https://github.com/odoo/upgrade/pull/9269 * = im_livechat, test_discuss_full This commit removes the fetched feature of Discuss messages, for the following reasons: 1. Redundancy: The original purpose of confirming server receipt is now better handled by the "pending" message state (spinner/opacity). Once a message is no longer pending, it is effectively "sent". 2. Reliability & Privacy: The previous implementation relied on a single bus notification, which when lost would lead to an inconsistent state. Fixing this reliability (by broadcasting status on connection) would negatively impact performance and, more critically, leak the presence of users who wish to appear "Offline". 3. Data Modeling: The model only tracks the last fetched ID, which is an inaccurate representation of message history if gaps exist. This commit also simplifies the "Seen" indicator to reflect this change: - single gray check: Some people have seen. - double purple checks: Seen by all channel members. task-5177299
This update simplifies the display of WhatsApp messages by removing a redundant 'fetched' indicator. This change improves reliability and privacy by preventing inaccurate tracking of user status and ensures users can appear offline. The 'Seen' indicator has also been updated for clarity.
Original PR description
community: https://github.com/odoo/odoo/pull/243853 upgrade: https://github.com/odoo/upgrade/pull/9269 This commit removes the fetched feature of Discuss messages, for the following reasons: 1.…
community: https://github.com/odoo/odoo/pull/243853 upgrade: https://github.com/odoo/upgrade/pull/9269 This commit removes the fetched feature of Discuss messages, for the following reasons: 1. Redundancy: The original purpose of confirming server receipt is now better handled by the "pending" message state (spinner/opacity). Once a message is no longer pending, it is effectively "sent". 2. Reliability & Privacy: The previous implementation relied on a single bus notification, which when lost would lead to an inconsistent state. Fixing this reliability (by broadcasting status on connection) would negatively impact performance and, more critically, leak the presence of users who wish to appear "Offline". 3. Data Modeling: The model only tracks the last fetched ID, which is an inaccurate representation of message history if gaps exist. This commit also simplifies the "Seen" indicator to reflect this change: - single gray check: Some people have seen. - double purple checks: Seen by all channel members. task-5177299
33 changes
New functionality added to Odoo
This update incorporates the latest Romanian VAT regulations, specifically the addition of 11% and 21% tax rates. The changes ensure Odoo correctly handles these new rates when calculating fiscal positions, maintaining accurate accounting and tax reporting for Romanian businesses.
Original PR description
The new 11% and 21% taxes introduced with the updated Romanian VAT law were added with this commit https://github.com/odoo/odoo/commit/2026212d0f7ffc217be3c6a2ff2abe5288c18afb , but some tax mappings were missing. This commit completes the setup by adding the required tax mappings, ensuring the new rates work correctly with fiscal positions. task-5480159 Forward-Port-Of: odoo/odoo#244745 Forward-Port-Of: odoo/odoo#243452
This update adds support for the Caribbean Guilder (XCG) as a new currency option within Odoo. It designates the XCG as the default currency for Curaçao and Sint Maarten, expanding Odoo's currency coverage to include these regions. This change allows users to accurately record transactions in XCG.
Original PR description
Introduce the Caribbean Guilder (XCG) as an available currency and set it as the default currency for Curaçao and Sint Maarten. Related PR-https://github.com/odoo/enterprise/pull/104404 taskID-5490423 Forward-Port-Of: odoo/odoo#243955
This update introduces support for the Caribbean Guilder (XCG) as a new currency option within Odoo Enterprise. It's now the default currency for Curaçao and Sint Maarten, aligning our financial data with the latest regional standards. This change ensures accurate reporting and transactions for businesses operating in these locations.
Original PR description
Align enterprise currency data with the community with addition of new currency XCG. Related PR-https://github.com/odoo/odoo/pull/243955 taskID-5490423 Forward-Port-Of: odoo/enterprise#104404
Resolved issues and error corrections
This update fixes an issue where keyboard navigation within the website builder's image cropping tool was unreliable. Now, pressing 'Enter' correctly validates or dismisses the cropper, and 'Escape' properly closes the sidebar. This provides a smoother and more accessible experience for users editing images.
Original PR description
Steps to reproduce: - Select an image in the website builder. - Open the cropping tools. - Press Enter. - Try to discard the cropper. Before this commit, focus stayed on the toolbar crop button so `Enter` opened another cropper, `Escape` closed the sidebar, and the cropper buttons were not reachable via keyboard. After this commit, the cropper grabs focus and handles `Enter/Escape` itself so keyboard interactions validate or dismiss the cropper. task-5432043 Forward-Port-Of: odoo/odoo#240910
A test within the Documents module was failing due to an issue with redirect URLs. The fix ensures that test URLs are consistently relative, resolving the problem and maintaining test stability. This ensures the Documents module continues to function correctly.
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 Forward-Port-Of: odoo/enterprise#105027
This update prevents excessive email notifications to managers when employees submit expenses. Previously, managers received emails for every state change, which was causing a flood of messages. Now, managers only receive a weekly email summarizing pending expenses awaiting their approval, streamlining the approval process and reducing inbox clutter.
Original PR description
When an employee submits an expense and assigns a manager, an approval activity is scheduled. However, email notifications are now disabled to avoid spamming the assigned managers. * Prevent notifying the expense manager when expense state changes. * Email 'Next expense is waiting your approval' is scheduled to be sent to the manager once a week if the manager has any expenses left to approve. task-4676396 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244995 Forward-Port-Of: odoo/odoo#210614
This update ensures that administrator users retain their default rating options within courses, preventing accidental changes made by other users. The change avoids duplicated fixes and streamlines the portal_rating module, improving stability and reducing potential conflicts. This protects the integrity of course ratings for administrators.
Original PR description
*: website_slides The default values for the admin user should not be changed by editing or deleting others' messages in courses. task-5326273 Forward-Port-Of: odoo/odoo#244782 Forward-Port-Of: odoo/odoo#236475
This update resolves a visual glitch on mobile websites where a horizontal scrollbar briefly appeared when the header returned to its original position after scrolling. The fix ensures the header's styling is correctly synchronized, preventing this momentary display issue. This improves the overall user experience, particularly on RTL websites.
Original PR description
There was an horizontal scrollbar that would appear for a short time after scrolling back to the top of the page. This would occur because the header would still have the "transform" property but the class "o_header_affixed" was already removed. To fix the issue, the header transform is now applied using dynamicContent, to synchronize the style and class correctly. This requires the standard header to have "transition: none" applied after it is scrolled since "translate(0, -100%)" would trigger an animation when hiding the header. task-5155878 Forward-Port-Of: odoo/odoo#241980
This update adds a 'View' button to the package history list, allowing users to directly access the details of each package created during a receiving process. Previously, users couldn't easily open the package records from this list, which has now been corrected to align with the data structure. This improves tracking and management of stock packages.
Original PR description
Steps to reproduce: - Enable packages - Do a reception with a product and put it in a pack - Open the 'Packages' stat button - View button is at the end of every line, to open the package - Go back to the picking and validate it - Open the 'Packages' stat button again Issue: There isn't any 'View' button, so we can't open the package records from here. It was done somewhat on purpose, as it's a list of `stock.package.history` and not `stock.package`, so we wouldn't open the right record. But we can simply add a button that opens the linked package instead. opw-5436847 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where mentioning portal users from different companies within Odoo caused an access error. The problem stemmed from how user read access was determined based on the currently active company. The update corrects a data storage issue that was triggering this error, ensuring portal users can be mentioned regardless of the company context.
Original PR description
* = test_discuss_full Before this commit, mentioning a portal user from another company would result in an access error. Steps to reproduce: 1. Install `hr_holidays` module. 2 Have a portal user in company A. 3. Switch the active company to company B. 4. In any chatter, try to mention said portal user. This happens because portal user read access depends on the current active company (see `res_users_rule`). The access error happens since [1], which added user information to the partner's default Store fields. [1] https://github.com/odoo/odoo/pull/212173 task-5499827
This fix ensures the sitemap generated for eCommerce categories accurately reflects only active products. Previously, it incorrectly included archived products, leading to inaccurate sitemap listings. The update adjusts the access rules to prioritize public categories with active products, resolving this issue.
Original PR description
To reproduce:
- Connect as "admin"
- Go to "Website / eCommerce / Products / eCommerce Category"
- Create a new category "Test With Archived Products"
- Go to "Website / eCommerce / Products"
- Create a product:
- name it "Test Archived"
- in "Sales" tab, under "eCommerce Shop" section, set category to:
"Test With Archived Products"
- then archive the product
- Clear the sitemap attachment and go to /sitemap.xml
The sitemap has an entry for "Test With Archived Products" but it should should not be visible as there are only archived products for that category.
Since odoo/odoo@d3fd767b0568, access rules domain are always optimized with `active_test=False`, so ensure we only return public category that have active products.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves a technical issue that could cause Odoo upgrades to fail when using manual one2many fields. Specifically, it addresses a 'KeyError' that occurred during the upgrade process when certain inverse fields weren't properly configured. This change ensures smoother and more reliable Odoo upgrades, particularly for customizations using manual one2many relationships.
Original PR description
When ``setup`` a manual one2many field, if its ``inverse_name`` field hasn't been ``setup`` and is also a manual field which might be ``pop`` when ``setup``, the one2many field can be ``setup`` successfully. But when computing ``setup_inverses`` when ``init_models``, the ``inverse_name`` will cause a ``KeyError``. ``invf = registry[self.comodel_name]._fields[self.inverse_name]`` Reproduce: see https://github.com/odoo/odoo/pull/240085 This commit simply checks the ``setup`` for the inverse field of the one2many field. 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 resolves an issue where multiple 'Applicant created' messages were appearing in the applicant's chatter log when a new applicant was created. The fix ensures that the log entry is only created once, improving the clarity and accuracy of applicant communication within the system. This prevents confusion and streamlines the recruitment process.
Original PR description
Steps to reproduce: 1. Create a new applicant in recruitment. 2. Open the applicant’s chatter. 3. See multiple “Applicant created” messages for the same creation. Bug cause: The applicant creation flow posts the `mt_applicant_new` subtype more than once (create + extra write/track), and the frontend renders the subtype description, so each duplicate post shows “Applicant created” again. Solution: - Post the `mt_applicant_new` subtype only once during applicant creation. - Avoid re-posting it in subsequent writes/tracking so chatter shows a single creation log. Task Id: 5454691
This update corrects a display issue in the applicant recruitment reports module. Incorrect stage names were appearing in chatter messages, preventing users from seeing the 'Stage changed' label. The fix ensures accurate stage name display and proper tracking of applicant stage transitions.
Original PR description
…records in hr_recruitment_reports demo data Steps to reproduce: 1. Load demo data for hr_recruitment_reports module 2. Check applicant records in chatter 3. Observe that stage change messages don't…
…records in hr_recruitment_reports demo data Steps to reproduce: 1. Load demo data for hr_recruitment_reports module 2. Check applicant records in chatter 3. Observe that stage change messages don't show "Stage changed" label 4. Review mail.tracking.value records for applicant stage changes 5. Observe incorrect stage name "Initial Qualification" instead of "Qualification" Bug cause: mail.message records for applicant stage changes were missing the subtype_id field, which defaults to an incorrect subtype (mt_note instead of mt_applicant_stage_changed). This caused the messages to be treated as internal notes rather than stage change notifications. Additionally, mail.tracking.value records used "Initial Qualification" as the old_value_char or new_value_char, which doesn't match the actual stage name defined in hr_recruitment module. The correct stage name is simply "Qualification" (ref: hr_recruitment.stage_job1). Solution: - Add subtype_id field with reference to hr_recruitment.mt_applicant_stage_changed to all mail.message records that track applicant stage transitions - This ensures stage change events are properly identified and displayed in chatter with the correct "Stage changed" label - Update old_value_char and new_value_char fields in mail.tracking.value records to use the correct stage name "Qualification" instead of "Initial Qualification" - Ensures consistency with actual stage names and proper display in applicant chatter history Affected records: 20 mail.message records in hr_recruitment_reports_demo.xml Task Id:5454691
This update resolves an issue where creating two companies with Sri Lankan settings resulted in a company inconsistency error. The problem stemmed from a duplicate tax ID format (using periods) in the system's tax configuration file. Removing the periods ensures correct company identification and prevents this error.
Original PR description
**STEP TO REPRODUCE** 1. create a company, and set country to Sri Lanka. 2. create a 2nd company, and do the same. 3. There is a company inconsistencies error. **CAUSE** There is 2 taxes defined in `account.tax-lk.csv` with `.` in their id. This messes up with the function `company_xmlid()`: we end up loading the `account.tax` record of the 1st company when saving the 2nd company. opw-5473952
This update addresses a potential issue where quality checks wouldn't display a helpful message if no IoT device was connected. Now, a notification appears, guiding users to configure a device and ensuring a smoother quality check process. This improves user experience and prevents confusion.
Original PR description
We now display a notification when no device is configured for a measure quality check. opw-5409775
This update automatically updates the IoT box's database when a new version is released. Previously, manual restarts were required, which was inconvenient. Now, the IoT box checks for changes and restarts itself to ensure it's always running the latest database version, improving stability and efficiency.
Original PR description
Before this commit, when the DB was upgraded to a new version, the IoT box had to be manually restarted so that it would checkout and align with the new version. After this commit, we check the DB branch whenever we receive a `bundle_changed` message on the websocket. If it has changed then the IoT will restart and checkout the new version. task-5463520 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242284 Forward-Port-Of: odoo/odoo#242195
This update resolves a technical issue that prevented the system from accurately calculating the number of documents associated with a partner during the upgrade process. The fix ensures that the system correctly identifies a single partner record, preventing a ValueError and ensuring accurate document counts.
Original PR description
When trying to compute the document count during the upgrade, we encountered a ValueError because multiple records were found for a partner. The system expected a singleton ``` File…
When trying to compute the document count
during the upgrade, we encountered a ValueError
because multiple records were found for a partner. The system expected a singleton
```
File "/home/odoo/src/enterprise/19.0/documents_hr/models/hr_employee.py", line 34, in _compute_document_count
('partner_id', '=', self.work_contact_id.id)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields_misc.py", line 112, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: res.partner(11393, 11612, 13026, 13085, 13066, 11674, 13007, 11240, 11420, 13086, 2687, 8998, 10309, 8195, 8468, 6439, 8151, 6580, 7928, 10301, 11058, 10515, 5274, 9243, 8141, 8435, 8889, 7761, 7733, 8443, 8545, 9252, 8457, 9980, 5495, 11424, 6458, 10558, 11070, 8924, 11731, 11528, 11615, 11766, 13021, 13080, 11758, 11742, 9306, 8826, 11004, 9393, 8879, 9317, 11652, 13075, 11744, 11160, 11644, 11763, 11416, 11618, 11732, 7931, 3846, 8442, 10299, 7916, 8429, 8057, 11061, 9342, 6435, 6553, 6512)
```This update corrects a technical issue where order documents weren't being properly updated in the Mexican tax reporting system (l10n_mx_edi). By forcing a write-date update, the system now reliably identifies and processes documents for accurate reporting. This resolves a previous limitation in the update process.
Original PR description
Before the commit 8b118a7, the search of the documents to update has been limited and ordered. With the actual domain the records to update will be most of the time the same because is not being updated. To fix this issue we force to update it. OPW-5368047 Forward-Port-Of: odoo/enterprise#103272
This update fixes an issue where the floating order name displayed during direct sales in the restaurant POS was incorrectly showing the POS reference instead of the tracking number. Now, the order name accurately reflects the tracking number, ensuring accurate order identification and tracking for customers. This improves the overall customer experience and operational efficiency.
Original PR description
Before this commit, when making a direct sale, the floating order name was the pos reference instead of the tracking number. This is now fixed. task-id: 5470874 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242359
This update resolves an issue where 'Website: Editor and Designer' users couldn't save Unsplash images after editing website content. The fix ensures the user creating the attachment has the necessary permissions, preventing security warnings and saving functionality failures. This improves the usability of the website editor for all user roles.
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#245085 Forward-Port-Of: odoo/odoo#219472
This update resolves an issue where the website tour test would fail after changing the header template to 'Sidebar'. The fix ensures the WebsiteBuilder component fully remounts before the tour continues, preventing it from resetting to the initial edit state. This improves the reliability of our website test suite.
Original PR description
When changing the header template to 'Sidebar', the loading screen disappears but the WebsiteBuilder component remounts asynchronously. If the tour proceeds to the theme tab before the remount completes, the builder resets to the Edit tab (its initial state), breaking the test flow. We wait for the builder to remount, and add `.editor_enable` class to the body of the iframe, so then nothing disrupts the flow. runbot-234504 Forward-Port-Of: odoo/odoo#243518
This update resolves an issue where users would encounter errors when uploading corrupted or encrypted PDF files for quotation document headers and footers. The fix ensures the system gracefully handles unreadable PDFs, preventing disruptions to the sales process. This improves the reliability of quote generation.
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 Forward-Port-Of: odoo/odoo#245167 Forward-Port-Of: odoo/odoo#230712
This update corrects a bug where the inventory count badge in the Barcode app incorrectly displayed requests from one company, even when no count existed for another. Now, the badge accurately reflects the inventory count for the company currently being viewed, ensuring data consistency and reliable reporting.
Original PR description
Steps to reproduce: - Create two companies (A and B) - Create a storable product "P1" - Log in with company A - Update the on-hand quantity of P1 in company A only - From Physical Inventory, request an inventory count for P1 - Switch to company B - Open the Barcode application Problem: The inventory count badge in the Barcode main menu displays a request count created for company A, even though no inventory count exists for company B. The badge incorrectly shows "1" instead of "0". opw-[5472031](https://www.odoo.com/web#id=5472031&view_type=form&model=project.task)
This update fixes an issue where VAT import taxes were incorrectly mapping to accounts in the Odoo system. The change in account 33312 has been addressed by updating the default account used for importing VAT taxes on purchase invoices. This ensures accurate financial reporting.
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 Forward-Port-Of: odoo/odoo#244919 Forward-Port-Of: odoo/odoo#244434
This update corrects a technical error where a function was incorrectly called in the payroll module. The fix involves creating a new function in the documents module that correctly calls the necessary function, ensuring proper document generation within the payroll system. This resolves a potential issue impacting payroll document accuracy.
Original PR description
Issue: `_check_create_documents` is called in 'hr_payroll' but only defined in 'documents_hr_payroll' Solution: Create a new method that will be redefined in 'documents_hr_payroll' to call `_check_create_documents` opw-5213979 Forward-Port-Of: odoo/enterprise#105099 Forward-Port-Of: odoo/enterprise#104282
This update fixes a display issue in the appointment calendar for Ukrainian and Polish users. Previously, month names were shown in the genitive case, which is grammatically incorrect. The change ensures month names are displayed in the nominative case, aligning with standard calendar conventions.
Original PR description
In the appointment calendar, the "Month Year" (e.g. January 2026) is displayed at the top of the calendar selector as is standard for calendars. Unfortunately in some languages, the word month word…
In the appointment calendar, the "Month Year" (e.g. January 2026) is displayed at the top of the calendar selector as is standard for calendars. Unfortunately in some languages, the word month word used depends on grammatical situation. Steps to reproduce: - activate Ukrainian (or Polish) language - Preview (i.e. the website view) of any appointment - Change the preview into Ukrainian (or Polish) Expected result: Calendar month at top of calendar is shown in the nominative case: e.g. January 2026 = січень 2026 (in Ukrainian) Actual result: Calendar month is shown in the genitive case (e.g. "of January", as in "the 12th of January): e.g. January 2026 = січня 2026 (in Ukrainian) Fix is to switch from the "MMMM Y" format (i.e. month based on grammar context) to "LLLL Y" (i.e. stand alone month) which will use the correct month case. Ref: https://www.unicode.org/reports/tr35/tr35-dates.html#dfst-month Note that for most languages this won't make a difference since there is usually only 1 way of writing a month. opw-5474705 picture diff (for January 2026): before fix: <img width="1168" height="468" alt="image" src="https://github.com/user-attachments/assets/36754439-e664-40f3-9c5b-7c9c76cd7cca" /> after fix: <img width="1215" height="492" alt="image" src="https://github.com/user-attachments/assets/82f0665e-fe70-4b9f-b1d4-f420b52db38f" /> Forward-Port-Of: odoo/enterprise#104942
This update aligns a key icon used in the Odoo Enterprise software with established design guidelines. The change ensures a more consistent and professional look and feel, reflecting updated branding standards. This improves the overall user experience.
Original PR description
This `network_light.svg` wasn't quite aligned with Milky picto's design guidelines. In this PR the pictogram has been tweaked in order for it to follow the guidelines. task-5126719 Forward-Port-Of: odoo/enterprise#104356 Forward-Port-Of: odoo/enterprise#95895
This update prevents the OCR from automatically updating a user's address information when processing QR-bills. Previously, the system would overwrite existing partner details, leading to confusion and incorrect data. This change ensures that address information is only populated if the QR-bill was the source of the data, improving data accuracy and user experience.
Original PR description
When the OCR detects that the document is a QR-bill, it will always overwrite the address information from the partner currently set on the record. We shouldn't do that if the partner wasn't created by the OCR. In the following scenario, it's pretty obvious why it is a bad idea: - User receives his QR-bills on his personnal email address. - He forwards it to the email alias set up for vendor bills. - A vendor bill is created with himself set as the supplier (already a bit annoying for him) - The OCR automatically analyses the document and updates the user's record with the address found in the QR-bill (really annoying). The same issue can arise if the user manually sets a supplier before sending the QR-bill for digitization. task-none
This update resolves an issue where rounding errors in currency calculations were causing the system to incorrectly remove small cash differences from reports. The fix ensures that even minor discrepancies, resulting from rounding, are accurately identified and reported, leading to more reliable cash reconciliation. This improves the accuracy of our sales reporting.
Original PR description
Before this commit, when calculating the cash difference in the report, the code did not account for currency rounding. This could lead to situations where a very small cash difference, due to rounding errors, was not recognized as zero, resulting in the unintended removal of cash moves. opw-5489958 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245251
This update addresses a technical issue preventing Odoo from correctly importing a necessary library. The problem stemmed from a recent change in the Requests library itself, which removed a specific exception. By installing a compatible version of Requests and importing the exception correctly, this fix ensures Odoo continues to function without errors.
Original PR description
Installing `requests==2.25.1` and using the following line of code:
from requests.exceptions import JSONDecodeError
It raises the following error:
ImportError: cannot import name 'JSONDecodeError' from 'requests.exceptions' (python3.10/site-packages/requests/exceptions.py)
It was removed from the following commit in the `requests` package:
https://github.com/psf/requests/commit/db575eeedcfdb03bf31285afd3033e301df8b685
This change fixes this error importing the original exception from `json` package
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#245075This update corrects a bug where toggling image captions caused layout disruptions, particularly when images were placed within tables or other non-paragraph containers. The fix ensures images remain within their original structure, maintaining a consistent and professional look for Odoo records.
Original PR description
Description of the issue this PR addresses: - When toggling an image caption, the logic only checks whether the image or figure’s closest block is editable. This causes images inside non-paragraph containers (such as table cells, list items, blockquotes, and columns) to be repositioned, breaking the original layout. Desired behavior after PR is merged: - Image caption toggling correctly handles paragraph-related containers, ensuring the image remains within its original structural context (tables, lists, blockquotes, columns) without altering the layout. Steps to Reproduce: - Open a to-do record. - Insert a table. - Add an image inside any table cell. - Toggle the image caption multiple times (3–4 times). task-5485697 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243454
This update corrects a technical issue where internal users without sales permissions would encounter an error when accessing their sales orders through the /my page. The change mirrors a previous fix and ensures a smoother experience for all users within the Odoo system. This improves overall system stability and usability.
Original PR description
Avoid error when internal user (no sale permissions) see Orders at /my Similar to https://github.com/odoo/odoo/commit/5ebab949a06ec338cc28e912317a74bbfb3fe6ac @Tecnativa TT60025 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245039
2 changes
Resolved issues and error corrections
This update fixes an issue where the system incorrectly prevented saving BOMs with byproducts having different cost shares based on product color attributes (e.g., white vs. black). The change ensures that the total cost share for a BOM's byproducts can exceed 100% when using different color variants, resolving a user-reported error and improving flexibility in product costing.
Original PR description
### Steps to reproduce: - In the settings enable By-Products - Create a product with an color attribute and 2 values: white, black - Create a bom for that products and add 2 by product lines: - 1 x…
### Steps to reproduce:
- In the settings enable By-Products
- Create a product with an color attribute and 2 values: white, black
- Create a bom for that products and add 2 by product lines:
- 1 x comp1 with a cost_share of 50% specific to the white att-value
- 1 x comp2 with a cost_share of 70% specific to the Black att-value
> Try to save and you will raise a UserError: The total cost share for a BoM's by-products cannot exceed 100.
### Expected behavior:
The error should not be raised as the total cost_share is 50% for the white variant and 70% for the black one but none of them exceeds the 100% cost share.
### Cause of the Issue:
Currently the constraint does not take attribute values into accounts and simply sums the value of the cost share of all by-product lines: https://github.com/odoo/odoo/blob/bcc1397c7d694dbe61ecbd44d0320b9518df84cb/addons/mrp/models/mrp_bom.py#L201-L202
### Fix:
Just as for the total cost_share on kit products, we rely on the exclusion util and check for each existing product variant if the cost share set up is valid:
https://github.com/odoo/odoo/blob/7e81c528ae350aab4432207f5655dcfadf6ec627/addons/purchase_mrp/models/mrp_bom.py#L20-L23 see 3832793e3ce61aff0c7cf4673de84645a3469b3a
opw-5499773
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue where customer names containing reserved words (like 'constructor') caused errors in reporting. The fix uses a different object creation method to avoid conflicts with inherited properties, ensuring customer names with these words can now be used without technical problems.
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#2452066 changes
Enhancements to existing features
This update streamlines CRM email templates by removing unnecessary fields. This change ensures more data is captured in chatter, particularly without requiring a system upgrade, and prevents duplicate information from being sent. It’s a small improvement to data accuracy and efficiency.
Original PR description
- Remove newly added fields that can be replaced by existing keys present in `iap_mail.enrich_company` template to ensure we get more data in chatter without upgrade and avoid duplicate entries IAP PR: https://github.com/odoo/iap-apps/pull/1390
Resolved issues and error corrections
This update fixes a potential issue in the Point of Sale reporting system where rounding errors could incorrectly identify small cash differences as non-zero. This meant the system might remove legitimate cash transactions, leading to inaccurate reporting. The change ensures accurate cash difference calculations by accounting for rounding, improving the reliability of financial reports.
Original PR description
Before this commit, when calculating the cash difference in the report, the code did not account for currency rounding. This could lead to situations where a very small cash difference, due to rounding errors, was not recognized as zero, resulting in the unintended removal of cash moves. opw-5489958 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where using certain reserved words (like 'constructor') as customer names caused errors in reporting. The change prevents the system from incorrectly interpreting these names, ensuring customer data can be accurately displayed and processed. This improves the reliability of customer reporting.
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-5474691This update resolves an issue where customer invoices sent via Peppol were generating duplicate attachments, leading to a cluttered user experience. The change ensures that attachments are updated instead of created anew, preventing this duplication and streamlining the invoice process. This improves the clarity and efficiency of invoice management.
Original PR description
When sending a customer invoice via Peppol, the system creates duplicate attachments (4 instead of 2 expected), cluttering the chatter and the attachment sidebar. This commit: - Implements a search-and-update logic for attachments to ensure idempotency (updates existing instead of creating duplicates). task-5438951 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#241130
This update resolves a customer complaint regarding test data using the name "Deco Addict". The system has been updated to consistently use "Acme Corporation" in all demo and test data, preventing user confusion. This ensures a cleaner and more accurate demonstration experience.
Original PR description
A company that happens to be named "Deco Addict" has complained some of our users thought they had business with them due to test and demo data containing that name. It will now be named Acme Corporation. task-5865502 Forward-Port-Of: odoo/odoo#245205
This pull request resolves a customer complaint regarding demo data. The name "Deco Addict" was replaced with "Acme Corporation" to prevent users from mistakenly associating test data with actual business transactions. This ensures a cleaner and more accurate demo experience.
Original PR description
A company that happens to be named "Deco Addict" has complained some of our users thought they had business with them due to test and demo data containing that name. It will now be named Acme Corporation. task-5865502 Forward-Port-Of: odoo/enterprise#105151