Daily updates from Odoo
Friday, January 23, 2026
198 changes
26 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 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 in Odoo Enterprise. It’s now the default currency for Curaçao and Sint Maarten, aligning our financial data with the latest community standards. This change ensures accurate reporting and transactions 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 fixes an issue where employee appraisals weren't automatically selecting the correct company template when the employee lacked a department. The fix ensures that appraisals consistently use the appropriate template based on the employee's company, improving appraisal accuracy and consistency. This resolves a previous bug impacting appraisal setup.
Original PR description
### Issue: When having a template with a company but no department, it's not selected by new appraisal. ### Steps to reproduce: - Have an employee whose appraisal date is today. - Have only one…
### Issue: When having a template with a company but no department, it's not selected by new appraisal. ### Steps to reproduce: - Have an employee whose appraisal date is today. - Have only one template, with the company of the employee but no department - Run the cron "Appraisal: Run employee appraisal" - Open the Appraisals app - Click on the newly created appraisal - It doesn't have the template ### Cause: - In `_compute_appraisal_template()`, only the department of the appraisal is used to compute the template. But `_create_new_appraisal()` doesn't include the department in `appraisal_values` to create the appraisal. So `appraisal.department_id` is `False` and the template from the department is ignored. - Another issue is if the employee has no department, then the appraisal also has no department. Then no template is selected by the search domain. ### Solution: - Include `department_id` in `appraisal_values` - Modify the search domain to include the case where the appraisal has no department opw-5477450 Forward-Port-Of: odoo/enterprise#104470
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 grammatical rules.
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 ensures that the demo data used in the product expiry tests is specific to the test environment, rather than relying on the main Odoo demo data. This resolves a test failure and provides more reliable results for developers working on this module. It's a minor fix that improves the stability of the testing process.
Original PR description
Use test specific data instead of relying on demo data. Runbot Error : [232852](https://runbot.odoo.com/odoo/runbot.build.error/232852?debug=1) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229730
This update optimizes the Odoo database by removing unnecessary default settings in the Spanish accounting module (l10n_es_edi_facturae). This reduces data storage and improves performance, particularly for businesses with multiple companies using different localization settings. The change ensures correct handling of user-defined values, maintaining data integrity.
Original PR description
On multi-company databases, having the defaults value on `account.move` selection fields unnecessary bloat the database for other companies with different fiscal package (localization). Moreover those two selection fields (`l10n_es_payment_means` and `l10n_es_edi_facturae_reason_code`) are not required, meaning the user can still set the value to `False` and we must be sure to handle that case anyway. opw-4397651 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242539
This update resolves an issue where rapid receipt printing via USB printers occasionally caused errors. The fix prevents multiple threads from accessing the printer simultaneously, ensuring reliable ESC/POS printing. This improves the overall stability of receipt generation.
Original PR description
When printing many receipts quickly using a USB printer, this error was occasinally occuring: ``` WARNING ? odoo.addons.iot_drivers.iot_handlers.drivers.printer_driver_base: Failed to query ESC/POS…
When printing many receipts quickly using a USB printer, this error was occasinally occuring: ``` WARNING ? odoo.addons.iot_drivers.iot_handlers.drivers.printer_driver_base: Failed to query ESC/POS status ERROR ? root: Could not set configuration: [Errno 16] Resource busy ``` This would cause `python-escpos` to be disabled and fallback to just CUPS printing. The issue was caused by two threads trying to access the printer at the same time, which could happen in two ways: - IoT thread with `python-escpos` and CUPS try to access the printer at the same time. - Two IoT threads with `python-escpos` try to access the printer at the same time (this can happen if two receipt actions are received at the same time). Both of these scenarios should now prevented: - Now, if we are using `python-escpos`, we also use it to print the receipt as well as checking the status. CUPS is never used so there should be no interference from it. - We now have an `escpos_lock` (per printer, not global) that is acquired when accessing the printer via `python-escpos`. This ensures that different threads cannot both try to access the printer at the same time. task-5490942 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244370 Forward-Port-Of: odoo/odoo#244031
This update fixes a bug that prevented portal users from another company from being mentioned in chat conversations. The issue stemmed from how access permissions were handled based on the currently active company. The fix ensures that portal users can be mentioned regardless of the company they belong to, improving collaboration across integrated accounts.
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 Forward-Port-Of: odoo/odoo#245224
This update aligns a small icon used in the Odoo Enterprise SaaS subscription visuals with established design guidelines. Ensuring consistency in our branding materials strengthens our overall professional image and user experience. This is a minor visual improvement.
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 resolves an issue preventing proper employee filtering within the l10n_ch_hr_payroll module. By using 'sudo' for filtering, the system now reliably processes payroll data regardless of the user's specific role (Payroll or Assistant). This ensures consistent and accurate payroll processing.
Original PR description
We perform the filtering with sudo so that it can be done even in cases where the user is not a Payroll/Assistant. This is primarily to fix the following runbot error, but in general to avoid blocking errors where they shouldn't happen. Runbot Error: 237851
This update fixes a bug that prevented users from successfully uploading attachments to expense records. The issue stemmed from a restriction in how Odoo handles attachment records, specifically when an attachment wasn't linked to an expense. The fix ensures attachments are correctly associated with expenses, improving the user experience.
Original PR description
Currently, an exception occurs when a user tries to open expenses or upload an attachment on expenses after following the steps described below. - Create an attachment with an `image/PDF` file and set the resource model as `hr.expense` - Go to expense > Create a new expense and upload the same `image/PDF` file This issue occurs because when a user creates an attachment without specifying a `res_id`, it defaults to `0`. In the previous version, `0` was allowed in the record set. However, after the changes introduced in [1], `falsy` values like `0` are strictly disallowed in the record set. This commit fixes the issue by reading only the `read_group` attachments that have a valid `res_id`, effectively ignoring attachments without a `res_id`. [1]: https://github.com/odoo/odoo/commit/4290724a4c8c57fba4f4d3d688d38f65dadcc38f sentry-7201563878
This update resolves an issue where incorrect data IDs within Odoo could trigger errors. The fix adds a filter to ensure all IDs used for browsing `ir.model.data` are valid, preventing potential disruptions to the system. This improves stability and reliability.
Original PR description
Since https://github.com/odoo/odoo/pull/227477, using falsy ids ids illegal This commit adds an additional filter to the domain used to browse `ir.model.data` to compute the following fields:…
Since https://github.com/odoo/odoo/pull/227477, using falsy ids ids illegal
This commit adds an additional filter to the domain used to browse `ir.model.data` to compute the following fields: `(menus|views|reports)_by_module` in order to avoid selecting any that would contain a falsy `res_id` and thus cause the above-mentioned assertion to fail.
One way to reproduce this in a new trial:
- Create a new trial with several modules: `account`, `crm`, `project`, `sales`
- Install `web_studio`
- Uninstall `base_automation`
- Traceback
```
File “/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py”, line 5200, in browse
assert all(ids) or all(isinstance(x, NewId) or x for x in ids), “Invalid falsy real id”
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: Invalid falsy real id
```
This is due to an `ir.model.data` containing a falsy res_id in the internal code of `saas_trial` (`installed-17`)
This fix will avoid any additional traceback like this one.
opw-5865316This update resolves a minor UI issue related to the ActivityWatch timesheet download screen within the Enterprise version of Odoo. The fix ensures a smoother and more reliable user experience when downloading timesheet data. This improves the usability of a key reporting feature.
Original PR description
This PR fixes some minor stuff that didn't make it into the previous PR.
A technical error preventing mail template creation was fixed. The issue stemmed from a validation process unaware of rental order functionality, causing a template creation failure. The fix involved moving a necessary method to the `sale_renting` module to ensure compatibility.
Original PR description
The mail template `mail_template_sale_cart_recovery` creation fails in some cases if there is a rental order in the database. Indeed, during a template creation, the first record of the corresponding model is used to validate the template validity. In this case, the template is only meant for e-commerce orders and there won't be any e-commerce rental order without `website_sale_renting` but the validation is not aware of functional specificities, leading to a traceback because the method `_get_rental_pricing_description` doesn't exist when only `sale_renting` and `website_sale` are installed. To avoid this error, we move the method to `sale_renting`, even though there is no real life flows where this was breaking (except templates validation ofc). Was fixed first with c3f5dafa23a8b1fd36eaedd83a575b717e5e9377 but moved back into `website_sale_renting` by mistake with fd1d7f91e7e60a20a5401201ff89a7e875faad82
This update fixes a warning message appearing in Point of Sale when expiration dates are disabled. The issue stemmed from a missing field in the product data, preventing accurate lot number retrieval. The fix ensures the system correctly handles this scenario, improving the user experience.
Original PR description
Steps to reproduce: = - Install only `point_of_sale` with demo data. - Ensure `Settings->Inventory->Traceability->Expiration Dates` is unchecked. - Open POS. - Click a product that uses lots. Issue: = - PoS always shows the warning “The existing serial/lot numbers could not be retrieved. Continue without checking the validity of serial/lot numbers?” even though lots are available. - Terminal error:`AttributeError: 'stock.lot' object has no attribute 'expiration_date'` Reason: = - When *Expiration Dates* is unchecked and the `product_expiry` module is not installed, the `expiration_date` field is not available (it is defined in `product_expiry` module by inheriting `stock.quant` model). Fix: = - Check field existence using the model’s _fields registry before accessing `expiration_date`, to prevent traceback. runbot-234958, 234959, 234960, 234961, 234964
This update resolves an issue where enlarging icons in the bills list view also disrupted the layout of the invoicing dashboard. The fix utilizes a new setting to display larger icons only when needed, ensuring a consistent and professional appearance for users.
Original PR description
As a part of task-5258726 the icons of no-content help in bills list view were enlarged. The icons used there were also used in the module dashboard, so enlarging them messed the dashboard styling. This commit fixes this issue by using a prop `largeIcons` on the `BillGuide` componenet to make it with large icons when needed only (in the bills list view no content help). task-5801970 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245209
This update resolves an issue where the website's cookie consent settings weren't being saved correctly after changing the 'I agree' button style to 'Default'. The fix ensures that the user's consent is properly recorded when this style change is applied, maintaining consistent cookie consent management.
Original PR description
Steps to reproduce: =================== 1. Enable the Cookies Bar in website settings. 2. Go to the website and enter Edit mode. 3. Select the Cookie Bar and change the button "I agree" style shape…
Steps to reproduce: =================== 1. Enable the Cookies Bar in website settings. 2. Go to the website and enter Edit mode. 3. Select the Cookie Bar and change the button "I agree" style shape to "Default" (this applies the `.btn-primary` class). & Save 4. Accept the cookies & refresh -> The cookie bar appears again because the consent was not saved. Cause: ====== The `CookiesBar` widget inherits from the generic `Popup` widget. The `Popup` class defines a default behavior for elements with the `.btn-primary` class: clicking them triggers `onBtnPrimaryClick`, which closes the popup. By default, the cookie bar button uses `.btn-outline-primary`, avoiding this behavior. However, when the user changes the style to "Default", the button receives the `.btn-primary` class. Consequently, the parent `Popup` handler is triggered. It closes the modal prematurely, interrupting the `CookiesBar`'s specific logic (specifically `onAcceptClick`),So onHideModal won't be called inside the function, and as a result, the user's consent cookie is never written. Solution: ========= Override the event to avoid side effects on hide. opw-5484578 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244875 Forward-Port-Of: odoo/odoo#243562
This update fixes a potential discrepancy in tax reporting within the Point of Sale module. Previously, the total tax base amounts in reports could slightly differ from the sum of individual line items due to rounding. This change ensures more accurate tax calculations and reporting, improving the reliability of financial data.
Original PR description
Before this commit, the total base amounts of taxes might be different from summing the base amounts of each line, due to rounding issues. opw-5408201 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244280
This update fixes a potential issue in the Point of Sale reporting where rounding errors could incorrectly identify small cash differences as non-zero. Previously, the system didn't account for currency rounding, leading to inaccurate cash difference calculations and unintended removal of transactions. This ensures more precise reporting of cash flow.
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 standard exception within the Requests library. The fix involves installing a specific version of Requests and adding a necessary import statement. This resolves an error that was caused by a recent change in the Requests library itself, ensuring Odoo continues to function smoothly.
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 prevents excessive email notifications to managers when employees submit expenses. Previously, managers received emails for every state change, which was causing spam. Now, a weekly email is only sent if a manager has outstanding expenses awaiting approval, streamlining the approval process and reducing unnecessary communication.
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 fixes a situation where quality checks wouldn't display a helpful message if no IoT device was connected. Now, users will receive a notification when a quality check requires an IoT device and one isn't configured, preventing confusion and ensuring accurate data collection.
Original PR description
We now display a notification when no device is configured for a measure quality check. opw-5409775 Forward-Port-Of: odoo/enterprise#105207
This update improves the product information displayed in the Point of Sale system. It now includes the product's internal code (default_code) in the product name shown in the product info popup, making it easier for staff to identify and track products. This change enhances clarity and efficiency within the sales process.
Original PR description
This commit adds the default_code (internal reference) to the display name of the product in the product info popup. opw-5493827 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244068
This update resolves a bug that prevented website tour tests from running correctly when the header template was changed to 'Sidebar'. The fix ensures the Website Builder remounts properly before the tour continues, preventing the builder from resetting to its initial state and disrupting the test flow.
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#245271 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 prevents the system from crashing when encountering these files, ensuring a smoother user experience when creating quotes.
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#245264 Forward-Port-Of: odoo/odoo#230712
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 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
7 changes
Resolved issues and error corrections
This update removes a restriction that previously limited the ability to use certain journal accounts for reconciliation. This change provides greater flexibility for users to configure their accounting processes, addressing a previous limitation that could restrict account usage. It’s a minor improvement to the system’s flexibility.
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 a potential infinite loop issue that could occur when generating combinations of product attributes, specifically with multi-checkbox attributes. The fix ensures that lines without attribute values are excluded from the combination process, preventing redundant calculations and maintaining system stability. This change improves the reliability of product configuration.
Original PR description
Before this commit, having a `product.template.attribute.line` with zero `product.template.attribute.value` records might cause an infinite loop if this **multi-checkbox** attribute wasn't in the end…
Before this commit, having a `product.template.attribute.line` with zero `product.template.attribute.value` records might cause an infinite loop if this **multi-checkbox** attribute wasn't in the end of the list.
Suppose the order was arbitrary and we are generating combinations for two lines (the order here is important):
- Line (A) -> [] (multi checkbox type)
- Line (B) -> [attr_1, attr_2]
- The possible combinations are {(attr_1), (attr_2)}.
After generating the second combination the following 2 procedures happen.
- The value_index_per_line[1] will be resetted to -1,
- The line_index will decrement from 1 to 0.
Now, since the first line doesn't have any values, it will be skipped and the line_index will be incremented to 1.
This results in the redundant generation of the same combination, triggering an infinite loop.
Since this method yields a recordset of `product.template.attribute.value` model and the **multi-checkbox** attribute doesn't have a value being passed to the method anyways, we can exclude the lines that doesn't have values for the algorthim not to be stuck in an infinite loop.
opw-5267179
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#241557This update corrects a technical inconsistency where certain fields in payroll modules (l10n_au, l10n_eg, l10n_lu) were incorrectly marked as editable. Removing this setting ensures that fields designated as 'readonly' remain protected, maintaining data integrity and compliance within these 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
This update corrects a problem with the tax report tour that prevented it from running correctly in certain scenarios. The fix addresses an incompatibility between the tour's assumptions about date calculations and the Odoo system's configuration, particularly when using the US tax report localization. This ensures the tour functions reliably across different Odoo setups.
Original PR description
- The tour shouldn't run if a localization with 'Tax Report' for the country is not installed (i.e. l10n_us_account) - Dynamic Javascript dates calculation don't mix well with Python's freeze_time running in the "No future" 2026 preparation build, so I froze the time in the Python test but resorted to hardcode the Javascript dates. - No need to check the position of the column "Column 1". In debug mode for the tour, there will be the "Debug" column where the info about the computations are shown, so it won't be the last. We just need to see that it shows, after all. Runbot error [link](https://runbot.odoo.com/odoo/error/234624) runbot-234624
This update resolves an issue preventing grouping within the planning module's slot templates. The fix ensures that parameters are passed to the underlying method in the correct order, enabling proper data aggregation. This improves the functionality of the planning system.
Original PR description
Before this commit, it was impossible to group by on any field in `planning.slot.template` model, because the parameters given to the parent method of `formatted_read_group` method were not given into the right order. This commit makes sure the order is respected. Forward-Port-Of: odoo/enterprise#105211
This update fixes 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 several configuration files. This ensures accurate translations and proper functionality for Greek-speaking users.
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#245352 Forward-Port-Of: odoo/odoo#244684
This update corrects a technical issue where newly added modules to the Odoo Enterprise platform were not correctly identified for translation. This fix ensures that the Greek language (el) is properly supported and translatable within the system, preventing errors and improving localization for users in Greece. It resolves a previous oversight related to .weblate.json configuration.
Original PR description
Modules added into stable without being properly added to .weblate.json file = never translatable. Forward-Port-Of: odoo/enterprise#105243 Forward-Port-Of: odoo/enterprise#104890
11 changes
Resolved issues and error corrections
This update corrects a discrepancy in payroll account testing, reflecting that payments are now processed through different business partners. The change reverts a previous adjustment to ensure accurate test results and maintain the integrity of payroll accounting. This ensures the system correctly accounts for all payment transactions.
Original PR description
This reverts commit 0d34a92a3afb7d488e4637f738a6e43688b58f4b. The tests were actually right, the payments are for different partners
This update allows users to modify stock quantity views through Studio, even without a unique identifier. Previously, a check prevented Studio fields from being used in the 'stock.quant' view. Now, Studio and customized views are correctly recognized, ensuring greater flexibility in managing stock data.
Original PR description
In versions prior to 18.3, the “stock.quant” view did not have an “xml_id”, which prevented it from being modified through Studio. However, starting from version 18.3 and specifically since this commit: https://github.com/odoo/enterprise/commit/f4a4d54d45392c2ba46a123d4951f8b4468c5cba it is now possible to modify views through Studio even if they don't have an xml_id. But in the 'stock.quant' view, we perform a check at creation time to ensure that the field is among the allowed fields. Fields coming from Studio or from a customized view should, however, be ignored by this check and allowed. opw-5107591
This update resolves a bug where the color slider in the editor's custom color picker would reset to red when selecting a color from the top of the palette. The fix prevents unnecessary UI updates, ensuring the color picker functions correctly and reliably.
Original PR description
**Current behavior before PR:** In editor's custom gradient picker, if `#FFFFFF` is picked from the very top of picker area, the color slider is reset to color `red`. This happens because when moving picker pointer to the top of area, `selectedColor` prop is updated to `#FFFFFF`, which calls `onWillUpdateProps` callback. As result, `convertRgbToHsl` sets hue value 0 for `#FFFFFF`, setting color slider to red. **Desired behavior after PR is merged:** This commit ensures that in `onWillUpdateProps` callback, `setSelectedColor` should not get called if `newSelectedColor` is the same as `this.colorComponents.cssColor` to prevent updating UI twice while picking the color. task-5170041 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245056 Forward-Port-Of: odoo/odoo#236644
This update prevents visitors from seeing or accessing live chat commands like `/help` or `/leave`. Previously, these commands were visible, which wasn't ideal for user experience. This change ensures a cleaner and more intuitive experience for all users.
Original PR description
**Current behavior before PR:** channel commands like `/help ` or `/leave` are visible to visitors even it is not functional for them. **Desired behavior after PR is merged:** commands are now hidden from visitors. task-4552209 related: [PR](https://github.com/odoo/enterprise/pull/82963) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196737
This update hides potentially confusing live chat commands (like `/help`) from website visitors and guests. Previously, these commands were visible, even though they weren't functional for them. This change enhances the user experience and security of the Helpdesk module.
Original PR description
*= test_discuss_full_enterprise **Before PR:** channel commands like `/help ` or `/leave` and more are visible to visitors or guest even it is not functional for them. **After PR:** all commands are now hidden from visitors/guests. task-4548666 Forward-Port-Of: odoo/enterprise#82963
This update resolves a potential infinite loop issue that could occur when generating product attribute combinations, specifically with multi-checkbox attributes. The fix ensures that lines without values are excluded from the combination process, preventing redundant calculations and maintaining system stability. This improves the reliability of product configuration.
Original PR description
Before this commit, having a `product.template.attribute.line` with zero `product.template.attribute.value` records might cause an infinite loop if this **multi-checkbox** attribute wasn't in the end…
Before this commit, having a `product.template.attribute.line` with zero `product.template.attribute.value` records might cause an infinite loop if this **multi-checkbox** attribute wasn't in the end of the list.
Suppose the order was arbitrary and we are generating combinations for two lines (the order here is important):
- Line (A) -> [] (multi checkbox type)
- Line (B) -> [attr_1, attr_2]
- The possible combinations are {(attr_1), (attr_2)}.
After generating the second combination the following 2 procedures happen.
- The value_index_per_line[1] will be resetted to -1,
- The line_index will decrement from 1 to 0.
Now, since the first line doesn't have any values, it will be skipped and the line_index will be incremented to 1.
This results in the redundant generation of the same combination, triggering an infinite loop.
Since this method yields a recordset of `product.template.attribute.value` model and the **multi-checkbox** attribute doesn't have a value being passed to the method anyways, we can exclude the lines that doesn't have values for the algorthim not to be stuck in an infinite loop.
opw-5267179
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#241557This update fixes a visual glitch in the time-off UI for Belgian employees. Previously, sickness relapse fields appeared unexpectedly after certain time-off approvals. The fix adjusts the layout to prevent this overlap and ensure a consistent user 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
This update fixes a technical issue in the Delivery IoT module that caused tracebacks when processing multiple print job confirmations. The change ensures that print jobs are handled correctly, even when there are discrepancies between the front-end and back-end systems, and improves compatibility with certain IoT devices. This prevents errors and ensures reliable print job processing.
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#105230 Forward-Port-Of: odoo/enterprise#105194
This update resolves an issue preventing bookings from being scheduled for the last hour of the day. The fix corrects a technical error that was incorrectly flagging the end of the day as unavailable, now allowing appointments to be booked from 23:00 to 00:00. This ensures users can utilize the full range of available appointment times.
Original PR description
**Steps to reproduce:** - Go to Appointment app - Edit an appointment type - Ensure its availability is on resources - Set duration to 1 hour - Add a schedule slot ending in 00:00 - Save and go to…
**Steps to reproduce:** - Go to Appointment app - Edit an appointment type - Ensure its availability is on resources - Set duration to 1 hour - Add a schedule slot ending in 00:00 - Save and go to the website page of the appointment - Last slot is not showing (23:00-00:00) **Issue:** When computing the appointment slots of a resource using time range, the end of day is considered as an unavaibility resource slot with this interval in `_get_unavailable_intervals`: `i_start = 23:59:59.999999` `i_stop = 00:00` this conflicts with the given range (23:00-00:00) in `self._slot_availability_is_resource_available` It comes from `_attendance_intervals_batch`, as `float_to_time(24.0)` is converted to `time.max` (23:59:59.999999) by: `day_to = datetime.combine(day, float_to_time(attendance.hour_to))` This introduces the microsecond unavaibility at the end of the day, which blocks the booking. (it's working properly for availability on users appointments) **Fix:** Changed the condition so that 23:59:59.999999 is considered as equal to 00:00. opw-5163892 Forward-Port-Of: odoo/enterprise#100853
This update resolves an issue preventing grouping within the planning module's slot templates. The fix ensures that parameters are passed to the correct method, enabling proper data aggregation and reporting. This improves the functionality of the planning feature.
Original PR description
Before this commit, it was impossible to group by on any field in `planning.slot.template` model, because the parameters given to the parent method of `formatted_read_group` method were not given into the right order. This commit makes sure the order is respected. Forward-Port-Of: odoo/enterprise#105211
This update resolves minor visual issues in the website's image gallery template. Specifically, it corrects errors like missing styling and undefined class names, ensuring a consistent and properly formatted display of images for users. This improves the overall user experience and presentation of product images on the website.
Original PR description
This commit fixes a few minor issues in the new carousel items template introduced in [1]: items having an `"undefined"` class, and a missing margin style in the main snippet template. [1]: https://github.com/odoo/odoo/commit/9042b1cae7b630b20e0670788b7a4ed9e4c97609 linked-task-3414281 Forward-Port-Of: odoo/odoo#241785
5 changes
Resolved issues and error corrections
This update resolves a potential infinite loop issue that could occur when generating product attribute combinations. Specifically, it prevents errors caused by a specific configuration involving multi-checkbox attributes with no associated values. This change ensures stable product configuration and avoids disruptions to the sales process.
Original PR description
Before this commit, having a `product.template.attribute.line` with zero `product.template.attribute.value` records might cause an infinite loop if this **multi-checkbox** attribute wasn't in the end…
Before this commit, having a `product.template.attribute.line` with zero `product.template.attribute.value` records might cause an infinite loop if this **multi-checkbox** attribute wasn't in the end of the list.
Suppose the order was arbitrary and we are generating combinations for two lines (the order here is important):
- Line (A) -> [] (multi checkbox type)
- Line (B) -> [attr_1, attr_2]
- The possible combinations are {(attr_1), (attr_2)}.
After generating the second combination the following 2 procedures happen.
- The value_index_per_line[1] will be resetted to -1,
- The line_index will decrement from 1 to 0.
Now, since the first line doesn't have any values, it will be skipped and the line_index will be incremented to 1.
This results in the redundant generation of the same combination, triggering an infinite loop.
Since this method yields a recordset of `product.template.attribute.value` model and the **multi-checkbox** attribute doesn't have a value being passed to the method anyways, we can exclude the lines that doesn't have values for the algorthim not to be stuck in an infinite loop.
opw-5267179
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#241557This update resolves a bug where self-order kiosk tickets were printing blankly when a preparation printer was configured without product categories. The fix ensures that the printer only prints when a product category is defined, aligning with the expected behavior of the self-order system. This prevents blank tickets and ensures accurate order information is printed.
Original PR description
Before this commit: To reproduce (version 17 and >): 1. Install Restaurant 2. In PoS restaurant config allow "Self ordering" in Kiosk mode and enable "Preparation printers" 3. Create a preparation printer with NO categories and set it as a restaurant preparation printer 4. Open the Kiosk 5. Make an order with any product and checkout -> Printer will print a ticket with no product <img width="512" height="415" alt="image" src="https://github.com/user-attachments/assets/31bd08f9-2470-4f72-9e3d-822564b43f70" /> After this commit: No kitchen printer is printed (expected as no category set on the kitchen printer) Forward-Port-Of: odoo/odoo#245193
This update resolves minor visual inconsistencies in the website's image gallery template. Specifically, it corrects issues with missing styling and undefined class names, ensuring a more polished and consistent user experience. This improves the overall presentation of images on the website.
Original PR description
This commit fixes a few minor issues in the new carousel items template introduced in [1]: items having an `"undefined"` class, and a missing margin style in the main snippet template. [1]: https://github.com/odoo/odoo/commit/9042b1cae7b630b20e0670788b7a4ed9e4c97609 linked-task-3414281 Forward-Port-Of: odoo/odoo#241785
This update enhances the security and reliability of our Peppol integration by implementing a safer process for server-initiated deregistration. Previously, an issue caused disruptions when a server unexpectedly removed a participant. Now, the system handles this more gracefully, allowing users to re-register after a soft reset of the configuration. This change was driven by a postmortem analysis of a recent incident.
Original PR description
Reintroduce server-initiated deregistration on `client_gone`, but only for implementations that explicitly handle it. The base proxy client now just raises the error. Peppol opts in by soft-resetting its configuration so users can re-register. See the IAP postmortem for the rationale and incident history. https://github.com/odoo/iap-apps/pull/1317 no-task Forward-Port-Of: odoo/odoo#245038 Forward-Port-Of: odoo/odoo#239254
This update resolves a technical issue identified during testing of Odoo's project scheduling features. Specifically, a problem with how spaces were handled in test data was corrected. This ensures the accuracy and reliability of the project scheduling system, preventing potential errors in planning and reporting.
Original PR description
Fixes https://runbot.odoo.com/odoo/runbot.build.error/162366 Forward-Port-Of: odoo/enterprise#105370
13 changes
New functionality added to Odoo
This update adds keyboard shortcuts to the Purchase Agreements form, streamlining the process for users. These shortcuts will allow for faster navigation and quicker completion of purchase requests, boosting overall efficiency. This is a minor improvement designed to enhance user experience.
Original PR description
This commit adds some shortcuts to the Purchase Agreements form, allowing users to navigate and work more efficiently. Task: 5420786 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
Enhancements to existing features
This update standardizes the UOM field names across various Odoo logistics modules, consolidating them to 'uom_id'. Previously, multiple names caused confusion and made it difficult to consistently use UOM fields. This change improves clarity and simplifies development.
Original PR description
Currently, the uom field can have 3 different names in logistic modules: - uom_id - product_uom_id - product_uom This is annoying when we need to use a uom field and we have to check what is its name. So we decided to only keep uom_id as the only name for basic uom fields. Task [5364113](https://www.odoo.com/odoo/project.task/5364113)
This update streamlines the handling of UOM fields across various Odoo modules. Previously, multiple names (uom_id, product_uom_id, product_uom) were used, creating confusion. Now, only 'uom_id' will be used for basic UOM fields, simplifying development and reducing potential errors.
Original PR description
Currently, the uom field can have 3 different names in logistic modules: - uom_id - product_uom_id - product_uom This is annoying when we need to use a uom field and we have to check what is its name. So we decided to only keep uom_id as the only name for basic uom fields. task 5364113
This update optimizes the suggestion list in email communication by placing the current user last. This change prioritizes more relevant suggestions for other partners, improving the user experience and efficiency.
Original PR description
With this commit the current user will be the last suggested partner in the suggestion list, as it's very unlikely to mention yourself so the space is better used to display other more relevant suggestions. part of task-5867464
This update simplifies the mass mailing editor by removing a specific setting related to link font sizes. Users can now adjust link font sizes using the standard editor toolbar, providing a more intuitive and flexible design experience. This change focuses on improving usability within the mass mailing module.
Original PR description
Remove the `mass_mailing` Design Tab `--link-font-size` special variable, as it is more natural that a link font-size is aligned with its container. It is still possible to use the editor toolbar `font-size` feature to change the `font-size` of links individually. task-5868086
Resolved issues and error corrections
This update resolves an issue where the message reaction menu remained open even when no reactions were selected. The fix ensures the menu automatically closes when empty, improving the user experience and preventing unnecessary screen clutter. This change contributes to a cleaner and more efficient workflow for users.
Original PR description
Since [1], message reaction menu doesn't close when it's empty. This commit fixes the issue. [1]: https://github.com/odoo/odoo/pull/234161 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 problem preventing changes to the Invoice Type field within the l10n_tr_nilvera_einvoice module. Previously, the system couldn't properly store data due to a limitation with the field type. This change allows for correct data storage and functionality.
Original PR description
After a recent PR, #235832 the `fields.Binary` can not store data other than bytes, due to this a traceback occurs while trying to change the Invoice Type, since a compute method is triggered that computes domain for a field that is of type Binary. Error: `TypeError: 'str' object cannot be interpreted as an integer` This commit fixes that issue by changing field type from Binary to Json. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update allows users to create working files with custom date ranges, addressing a previous limitation. The fix ensures accurate generation of reports by correctly passing necessary context during file creation. Additionally, minor improvements have been made to display audit titles more clearly in the user interface.
Original PR description
It should be possible to create a working file with any dates. odoo/enterprise#100757 should have solved this but the context for force_periodicity_violation wasn't passed to _try_create_returns_for_fiscal_year which doesn't allow creating those custom working files in the wizard. Also, includes a small changes to make longer audit titles display better in their record view (checks kanban view) and kanban view.
This update resolves an issue with how payroll dependencies were configured, specifically removing a redundant and incorrect exclusion setting. Simultaneously, the team modernized the testing code by replacing older print statements with more efficient f-strings, improving code readability and maintainability.
Original PR description
Community fixes `upstream_dependencies` to support an empty list of states to exclude, and these tests don't seem to actually need anything (since they would previously exclude no less than 9 states which don't exist, as `('uninstallable')` is a string not a 1-uple).
While at it, convert a bunch of printfs to f-strings.A recent update added options to the account reports footer generation process. However, the code wasn't updated to handle cases where no options were provided, leading to an error. This fix ensures the report generates the default footer layout when no options are specified, resolving the issue.
Original PR description
The following commit added a new 'options' argument to _get_layout_footer but forgot to add pass those in one of the calls to the method. Therefore, we get an error when 'options' is None (default…
The following commit added a new 'options' argument to _get_layout_footer but forgot to add pass those in one of the calls to the method. Therefore, we get an error when 'options' is None (default value) and 'options.get()' is called.
Commit:
https://github.com/odoo/enterprise/commit/b02b65ad2baa999b62e3b44fcfc05f9afff5f8cc
Error:
```
RPC_ERROR
Odoo Server Error
Occured on 98738418-master-design-theme.runbot278.odoo.com on 2026-01-22 08:48:56 GMT
Traceback (most recent call last):
File "/data/build/enterprise/account_reports/controllers/main.py", line 32, in get_report
generated_file_data = report.dispatch_report_action(options, file_generator)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/account_reports/models/account_report.py", line 2630, in dispatch_report_action
return report_method(model, *args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/account_reports/models/account_journal_report.py", line 265, in export_to_pdf
footer = self.env['account.report']._get_layout_footer(rcontext)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/account_reports/models/account_report.py", line 6139, in _get_layout_footer
custom_config = options.get('custom_display_config', {})
^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'get'
The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
RPC_ERROR
at makeErrorFromResponse (https://98738418-master-design-theme.runbot278.odoo.com/web/assets/3059a1f/web.assets_web.min.js:3221:165)
at decoder.onload (https://98738418-master-design-theme.runbot278.odoo.com/web/assets/3059a1f/web.assets_web.min.js:3203:7)
```
task-noneCode cleanup and technical improvements
This update reorganizes the structure of our point-of-sale data models. Separating the `pos_order_line` from the `pos_order` model improves code organization and makes it easier for developers to maintain and update the system. This change enhances overall system stability and efficiency.
Original PR description
*: pos_mrp, pos_sale, pos_self_order In this commit: ------------------ - We have separated the `pos_order_line` model from the `pos_order` model to better organize the files and improve the overall code structure, making the codebase easier to understand, maintain, and navigate. task: 5473161 Related PR: https://github.com/odoo/enterprise/pull/103624
This update reorganizes the structure of our point-of-sale (POS) data models. Separating the `pos_order_line` from the `pos_order` model improves code organization, making it easier for developers to understand and maintain the system. This ultimately leads to more efficient updates and enhancements to our POS functionality.
Original PR description
In this commit: ------------------ - We have separated the `pos_order_line` model from the `pos_order` model to better organize the files and improve the overall code structure, making the codebase easier to understand, maintain, and navigate. task: 5473161 Related PR: https://github.com/odoo/odoo/pull/242738
This update consolidates the code responsible for generating call status information within the Odoo Enterprise system. This change improves code organization and maintainability, ensuring consistent and reliable call status updates across various modules.
Original PR description
We centralize the code that produces call statuses.
17 changes
Enhancements to existing features
This update adjusts the font size of the 'amount due' and 'amount by guest' displays on the payment screen within the Point of Sale module. This enhancement improves readability and ease of use for staff processing payments, particularly when dealing with larger transactions.
Original PR description
Little improvement of the font size of amount due and amount by guest on the payment screen. task: 5473324 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
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 payroll calculations. This change enhances the overall accuracy of financial reporting.
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
This update fixes an issue where customer display QR codes in the Point of Sale (POS) system were generating incorrect URLs. The change ensures the QR code uses the correct base URL configuration for the POS session, improving the reliability and accuracy of customer information displayed through QR codes.
Original PR description
Steps:
- Install point_of_sale.
- Open a POS session on a mobile device.
- Click on the customer display menu.
Issue:
- The QR code for the customer display contains an invalid URL: undefined/pos_customer_display/${config_id}.
Issue:
- The base URL was being accessed from the POS session, where it is not available.
Fix:
- Retrieve the base URL from the POS configuration instead of the session.
task-5792308This update removes the Sign menu item from Odoo's discuss channels. Previously, this menu was incorrectly displayed, which was confusing for users. This change aligns with the functionality of discuss channels, which are designed for mail threads and don't require the Sign feature.
Original PR description
Currently, the Sign menu item is displayed in discuss channels, which is not making sense. This was due to an incomplete check in the isDisplayed method of the SignRequestCogMenu component. To fix this, we enhance the condition to ensure that the menu item is not displayed when the current model is 'discuss.channel'. Discuss channels inherently support mail threads, but should not have the Sign menu item. task-5494751
This update addresses an issue where light-colored dropdown menus in the Discuss app caused eye strain when using the dark theme. A simple adjustment was made to darken these menus, ensuring a more comfortable viewing experience and improved usability in dark mode. This enhances the overall user experience for users of the Discuss app.
Original PR description
Dropdown menu are quite light in dark theme. Outside of discuss not many UI elements require dropdown. However discuss use them a lot, so this becomes a problem to have light background so often. This commit adds `.bg-view` to all discuss dropdown, which is visually unchanged in white theme but in dark theme this makes it darker so easier to read with less eye strain. Task-5492040 Before / After <img width="961" height="671" alt="Screenshot 2026-01-13 at 17 24 12" src="https://github.com/user-attachments/assets/09ab5f8f-5927-4beb-a814-d77cd61f8a01" /> <img width="957" height="667" alt="Screenshot 2026-01-13 at 17 23 56" src="https://github.com/user-attachments/assets/4ec0ef3b-7af5-4b69-b48e-40c3788eb95e" />
This update resolves an issue where the 'Pending' button in manufacturing orders incorrectly stopped productivity records for all employees involved, instead of just the current one. The fix ensures that only the employee actively working on the operation is impacted when the 'Pending' button is clicked, improving workflow efficiency and accuracy.
Original PR description
Steps to reproduce the bug:
- Create a storable product P1 with the following BoM:
- Create a new operation OP1
- Create a manufacturing order to produce one unit of P1
- Confirm the manufacturing order
- Log in as Mitchel (admin) and start OP1
- Log in as Marc (demo) and also start OP1
- Click on Pending
Problem:
Both “mrp.workcenter.productivity” records are stopped, instead of stopping only the one linked to
The `button_pending` method was stopping productivity records for all employees linked to the work order.
opw-5453752
Forward-Port-Of: odoo/enterprise#105109
Forward-Port-Of: odoo/enterprise#103553This update corrects a potential issue where users could inadvertently add special characters to the company registry field when submitting VAT returns via the Intervat API. The change adds a filter to ensure only numeric values are used, preventing errors and ensuring accurate data transmission to the API. This improves the reliability of VAT return submissions.
Original PR description
When submitting vat return to Intervat API, we are using company_registry, which is a computed field based on VAT. It's VAT - Country code But this field remains editable, so user could change it to add special characters, like dots or country code, but the Intervat API's are expecting only numbers. This commit add a regex to remove all special characters and only keep numbers from company_registry to use it for API calls. task-5500052
This update resolves an issue where users lacking specific access rights within Odoo could not submit VAT declarations through the Intervat module. By adding sudo permissions, the update ensures all users can submit, regardless of their access level, improving the usability and reliability of this important business process.
Original PR description
Add few sudo() for vat declaration, to be sure users without access rights to res.company or certificate.certificate can still make a submission. task-5470492
This update corrects a visual issue where 'Danger' and 'Success' action buttons weren't consistently displayed in the portal message action list. The fix ensures that these buttons appear correctly, regardless of whether they're shown in the dropdown or quick action menu, improving the user experience.
Original PR description
PR #224976 fixes the demonstration of an action with a `DANGER` tag in the dropdown menu in the action list. Such an action may not be located in the dropdown, but rather in the quick action menu. This change ensures that the action buttons with `DANGER` or `SUCCESS` tags are demonstrated properly in either case. Steps to reproduce: - Open a document in the portal as a portal user. - Send a message and hover over the message. - The `delete` button is not visible in the action list.
A bug was causing the 'this device' option in the Point of Sale customer display to unexpectedly close and open the POS session in a new tab. This has been fixed by correcting how the URL is generated, resolving an issue with incorrect URL formation and a missing base URL.
Original PR description
Step to reproduce: - start pos - from top-right menu, click on display icon - a dialog will appear, click on "this device" button Observation: - current session will be closed and open in new tab Cause: - Incorrect url formed for redirection which, as a fallback loads currrent pos - base url is `undefined`, as we try to get it from `pos.session`, which now is attribute of `pos.config`. https://github.com/odoo/odoo/blob/06ddce00115c906a4d8396387dd3332482145d7f/addons/point_of_sale/models/pos_config.py#L288 opw-5502812 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a potential infinite loop issue that could occur when generating combinations of product attributes, specifically with multi-checkbox attributes. The fix ensures that lines without attribute values are excluded, preventing redundant calculations and maintaining system stability. This change improves the reliability of product configuration processes.
Original PR description
Before this commit, having a `product.template.attribute.line` with zero `product.template.attribute.value` records might cause an infinite loop if this **multi-checkbox** attribute wasn't in the end…
Before this commit, having a `product.template.attribute.line` with zero `product.template.attribute.value` records might cause an infinite loop if this **multi-checkbox** attribute wasn't in the end of the list.
Suppose the order was arbitrary and we are generating combinations for two lines (the order here is important):
- Line (A) -> [] (multi checkbox type)
- Line (B) -> [attr_1, attr_2]
- The possible combinations are {(attr_1), (attr_2)}.
After generating the second combination the following 2 procedures happen.
- The value_index_per_line[1] will be resetted to -1,
- The line_index will decrement from 1 to 0.
Now, since the first line doesn't have any values, it will be skipped and the line_index will be incremented to 1.
This results in the redundant generation of the same combination, triggering an infinite loop.
Since this method yields a recordset of `product.template.attribute.value` model and the **multi-checkbox** attribute doesn't have a value being passed to the method anyways, we can exclude the lines that doesn't have values for the algorthim not to be stuck in an infinite loop.
opw-5267179
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#241557This update resolves an issue where the l10n_cl_edi module was incorrectly creating duplicate vendor bills when receiving identical XML invoices via the incoming mail server. The fix prevents duplicate bill creation, ensuring accurate record keeping and avoiding potential accounting discrepancies. This addresses previous bugs opw-5362664 and 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 Forward-Port-Of: odoo/enterprise#103211
This update resolves an issue preventing grouping within the planning module's slot templates. The fix ensures that parameters are passed to the underlying method in the correct order, enabling proper data aggregation. This improves the functionality of the planning system.
Original PR description
Before this commit, it was impossible to group by on any field in `planning.slot.template` model, because the parameters given to the parent method of `formatted_read_group` method were not given into the right order. This commit makes sure the order is respected. Forward-Port-Of: odoo/enterprise#105211
This update removes a previous restriction that limited the use of journal accounts for reconciliation. Previously, certain accounts couldn't be used if they were designated as default debit or credit accounts within a journal. This change provides greater flexibility for accounting processes and simplifies account management.
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 fixes a potential issue with how payroll reports are generated in Switzerland. Specifically, it ensures that a snapshot is only created if one doesn't already exist, streamlining the process and preventing unnecessary data duplication. This improves the efficiency of report generation and reduces potential processing delays.
Original PR description
Forward-Port-Of: odoo/enterprise#105258 Forward-Port-Of: odoo/enterprise#105135
Features or functions removed from Odoo
This update removes outdated Albanian translations from several Odoo modules. This prepares the system for accurate translations when Albanian is reintroduced through our Weblate translation platform, ensuring a consistent and reliable user experience.
Original PR description
Both the po files and the translations were old and out of date. Delete them now so we can start from scratch when the language is added into Weblate.
This update removes outdated Albanian translations from various Odoo modules. This cleanup prepares the system for future language updates by utilizing Weblate, ensuring accurate and current translations moving forward. It's a routine maintenance task to maintain translation quality.
Original PR description
Both the po files and the translations were old and out of date. Delete them now so we can start from scratch when the language is added into Weblate. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
16 changes
Enhancements to existing features
This update improves how product prices are displayed in Odoo. A new method, `_get_price_label_base_str()`, has been added to the product pricelist item model. This change allows for more flexible and customizable formatting of price labels, ensuring consistent and accurate presentation of pricing information.
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
Resolved issues and error corrections
This update fixes an inconsistency in how product pricelists are assigned to partners. Previously, EU partners were incorrectly assigned a specific pricelist, while others weren't. This change ensures that EU partners automatically use the default pricelist, streamlining pricing and avoiding manual adjustments.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a way to check the `specific_property_product_pricelist` field; 2. create a pricelist for EU countries; 3. delete all other regional pricelists; 4.…
Versions -------- - 18.0+ Steps ----- 1. Have a way to check the `specific_property_product_pricelist` field; 2. create a pricelist for EU countries; 3. delete all other regional pricelists; 4. create a new partner in a EU country; 5. create a new partner outside a EU country; 6. create a new partner without a country. Issue ----- Inconsistent behavior: - EU partner has no `specific_property_product_pricelist` value set, as it's identical to the default `property_product_pricelist`. - The other partners do have a `specific_property_product_pricelist` value set to the default value, as if a user manually assigned them. Cause ----- In the `_inverse_product_pricelist` method, the `default_for_country` pricelist is an empty recordset if the partner has no `country_id` or none of the pricelists have a country groups with the partner's `country_id` in it. Solution -------- Introduce a `_get_country_pricelist_multi` method that can be used by `_get_partner_pricelist_multi` and `_inverse_product_pricelist` to ensure that they both return the same result for any given country (including none), and use this as the `default_for_country`. > [!Note] > An alternative approach could be to replace the `_inverse_product_pricelist` method with an `onchange` method, as the docstring of the `_get_partner_pricelist_multi` method states: >> First, the pricelist of the specific property (res_id set), this one is created when saving a pricelist on the partner form view. > > This suggests a behavior that more closely resembles the purpose of an `onchange` method, instead of an `inverse`. opw-5385213 Enterprise PR: https://github.com/odoo/enterprise/pull/103116 (only modifies a test)
This update corrects a discrepancy in a sales subscription test. The test previously incorrectly prioritized pricelists based on default settings for partners without country information. The fix ensures consistent ordering by aligning pricelist sequences, resolving a minor technical issue without impacting core functionality.
Original PR description
Versions -------- - 18.0+ Issue ----- Commit a840e4250666 changed a `sale_subscription` test as pricelist ordering was changed. Before, it was `sequence asc, id desc`, now it is `sequence asc, id asc`. However, in the updated tests, it expects the first pricelist created with sequence 4 to be before the second pricelist with sequence 2. This was only happening due to default pricelists getting set as the `specific_property_product_pricelist` if the partner has no country assigned to them. Solution -------- As the behavior is now identical for partners with or without a country assigned to them, we can resolved the test setup by giving both pricelists an identical sequence, making the ordering fall back on `id` like a840e4250666 intended. opw-5385213 Related: https://github.com/odoo/odoo/pull/241736
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, preventing unintended removal of cash transactions. This improves the accuracy of our 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 corrects a user experience issue where demo data included the name "Deco Addict," causing confusion. The name has been updated to "Acme Corporation" to align with standard demo data practices and prevent user misinterpretations. This ensures a cleaner and more reliable demo environment.
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
This update resolves a customer complaint regarding demo data. The name "Deco Addict" has been replaced with "Acme Corporation" to avoid confusion and ensure accurate test scenarios. This change improves the user experience and data integrity within our demo environment.
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
This update addresses a limitation in how users manage their consent for online account synchronization. Previously, a short-lived access token caused the synchronization link to break after 30 minutes. Now, a more stable consent token is used, linked to the user, ensuring a consistent and reliable synchronization process.
Original PR description
In this commit:bf5b7d0 we introduce a message on the account_online_link to be able to manage the consent. (one needed fix in this commit:https://github.com/odoo/enterprise/commit/1c84804fd3f0c0d1d23916b9f6a388616f66ac7e) This commit will change the way we manage the consent since the access token is in fact available only for 30 min, so the link in the chatter would not work. We decided to have a consent token which is a uuid4 encoded in base64 (url safe) and link it to the odoofin user. task-5187621 Forward-Port-Of: odoo/enterprise#105202
This update enhances the security and reliability of our Peppol integration by implementing a safer method for server-initiated deregistration. The system now handles deregistration more gracefully, allowing users to re-register after a server-initiated step. This change was prompted by a previous incident and is designed to improve overall system stability.
Original PR description
Reintroduce server-initiated deregistration on `client_gone`, but only for implementations that explicitly handle it. The base proxy client now just raises the error. Peppol opts in by soft-resetting its configuration so users can re-register. See the IAP postmortem for the rationale and incident history. https://github.com/odoo/iap-apps/pull/1317 no-task Forward-Port-Of: odoo/odoo#244575 Forward-Port-Of: odoo/odoo#239254
This update resolves a potential infinite loop issue that could occur when generating product attribute combinations, specifically with multi-checkbox attributes having no values. The fix ensures that lines without values are excluded from the combination process, preventing the loop and improving system stability. This change impacts product configuration and ensures accurate attribute selection.
Original PR description
Before this commit, having a `product.template.attribute.line` with zero `product.template.attribute.value` records might cause an infinite loop if this **multi-checkbox** attribute wasn't in the end…
Before this commit, having a `product.template.attribute.line` with zero `product.template.attribute.value` records might cause an infinite loop if this **multi-checkbox** attribute wasn't in the end of the list.
Suppose the order was arbitrary and we are generating combinations for two lines (the order here is important):
- Line (A) -> [] (multi checkbox type)
- Line (B) -> [attr_1, attr_2]
- The possible combinations are {(attr_1), (attr_2)}.
After generating the second combination the following 2 procedures happen.
- The value_index_per_line[1] will be resetted to -1,
- The line_index will decrement from 1 to 0.
Now, since the first line doesn't have any values, it will be skipped and the line_index will be incremented to 1.
This results in the redundant generation of the same combination, triggering an infinite loop.
Since this method yields a recordset of `product.template.attribute.value` model and the **multi-checkbox** attribute doesn't have a value being passed to the method anyways, we can exclude the lines that doesn't have values for the algorthim not to be stuck in an infinite loop.
opw-5267179
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#241557This update resolves a test failure in Odoo's web_studio module caused by a missing dependency. The fix ensures that tests accurately check for the presence of required modules and their associated models, preventing false test failures. This improves the stability and reliability of the web_studio functionality.
Original PR description
`RELATED_MODELS_TO_EXCLUDE` contains `account.edi.document`, which is installed by `account_edi`, which is neither in the `needed_modules` set nor a dependency of any of them. Therefore the test can fail because `account_edi` is not installed even though every module in the set is. Improve the test by checking that the models or fields we're checking for actually belong to the modules we've listed. Also add the missing module in the list.
This update removes outdated test code related to exchange rate precision in the l10n_mx_edi module. The previous fix inadvertently left this older code in place, and this PR ensures the testing environment is clean and consistent. This improves the reliability of the Mexican tax reporting functionality.
Original PR description
The PR #102557 fixed an issue with exchange rate precision for Solution Factible. However, its forward ports for 18 (PR #104195) and saas-18.2 (PR #104673) did not properly delete some of the old test code. This PR deletes that code. [opw-5165200](https://www.odoo.com/odoo/project.task/5165200)
This update resolves a bug where self-order kiosk tickets were printing blankly when a preparation printer was configured without product categories. The fix ensures that kitchen printers only print when a product category is defined, aligning with the expected behavior of the self-order system. This prevents blank tickets and improves the kiosk experience.
Original PR description
Before this commit: To reproduce (version 17 and >): 1. Install Restaurant 2. In PoS restaurant config allow "Self ordering" in Kiosk mode and enable "Preparation printers" 3. Create a preparation printer with NO categories and set it as a restaurant preparation printer 4. Open the Kiosk 5. Make an order with any product and checkout -> Printer will print a ticket with no product <img width="512" height="415" alt="image" src="https://github.com/user-attachments/assets/31bd08f9-2470-4f72-9e3d-822564b43f70" /> After this commit: No kitchen printer is printed (expected as no category set on the kitchen printer) Forward-Port-Of: odoo/odoo#245193
This update resolves a technical issue that was preventing our project scheduling tests from running correctly. The fix ensures proper handling of spaces in test data, improving the reliability of our testing process and ultimately contributing to more stable project planning features. This change focuses on internal test improvements.
Original PR description
Fixes https://runbot.odoo.com/odoo/runbot.build.error/162366
This update corrects a bug where a delivery order's picking state would incorrectly update the serial number of a product. The fix prevents changes to the serial number when adding new moves to 'ready' pickings, ensuring accurate tracking of inventory and serial numbers. This improves data integrity and reduces potential errors in stock management.
Original PR description
Steps to reproduce: - Create a storable product tracked by serial number (e.g. "P1") - Set the quantity on hand to 2 with serial numbers SN1 and SN2 - Create a delivery order - Add any product with available quantity - Mark the delivery as "To Do" -> The picking is in the `ready` state - Add a new move line with product "P1" and assign serial number SN2 -> Before saving, the quantity is correctlyupdated to 1 - Save the delivery Problem The assigned lot/serial number is unexpectedly replaced with 'SN1'. Fix: Do not update or recompute the serial/lot number when creating a move on pickings that are already in the `ready` state. opw-5385993
This update replaces "Deco Addict" with "Acme Corporation" in various Odoo demo data sets to address a user complaint. This ensures demo data accurately reflects business scenarios and avoids confusion for users. The change improves the user experience and data consistency.
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#245434 Forward-Port-Of: odoo/odoo#245205
This update resolves a user complaint regarding test data that incorrectly included 'Deco Addict'. The company name has been updated to 'Acme Corporation' to align with demo and test environments, ensuring a more accurate and professional experience for potential users. This change improves data consistency and user perception.
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#105279 Forward-Port-Of: odoo/enterprise#105151
3 changes
Resolved issues and error corrections
This update fixes an issue where the 19%I tax code (9) was missing from Datev exports for expense journal entries. The problem occurred due to how payment amounts were aggregated, leading to inaccurate data transfer. This ensures consistent and compliant tax reporting for 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
This update fixes an error in the FAIA report that incorrectly classified partners as suppliers. The change allows partners to be recognized as both customers and suppliers, resolving an issue caused by credit notes. This ensures accurate reporting of financial transactions within the SAFT report.
Original PR description
1. Create a contact (with minimal details). 2. Create a customer invoice for that contact **last month** with `quantity = 300`. 3. Create a credit note for that invoice **this month**. 4. Create another customer invoice for the same contact **this month** with `quantity = 100`. In the FAIA report (XML), within the General Ledger section, the partner is incorrectly classified as a supplier instead of a customer. In the method _saft_fill_report_partner_ledger_values from account_saft, he partner type is determined based on whether the balance is negative. However, a negative balance can result from a credit note, where the partner is still a customer and not a supplier. Furthermore, a partner can be both a supplier and a customer. This commit allows a partner to be both a customer and a supplier. If both receivable and payable are 0 we set the partner type to customer to keep the behavior from e9640caf29e967fe7d8c6fe303b5a8d7a866437e opw-5360924
This update resolves a technical issue that was causing crashes during the import of accounting data. The fix prevents a specific error related to incorrect data handling, ensuring that import processes run smoothly and reliably. This improves the stability of our accounting reports and reduces the risk of data loss.
Original PR description
Fixes crash caused by #97263