Daily updates from Odoo
Friday, January 23, 2026
24 changes · saas-18.2
Resolved issues and error corrections
This update fixes an issue where the dashboard wasn't accurately counting high-priority maintenance requests. The fix ensures that critical requests are correctly identified and displayed, improving visibility and allowing users to prioritize maintenance effectively. This enhances the reliability of the maintenance dashboard.
Original PR description
Issue before this commit: ========================= The high-priority maintenance request count (todo_request_count_high_priority) was not calculated correctly. Steps to Reproduce:…
Issue before this commit: ========================= The high-priority maintenance request count (todo_request_count_high_priority) was not calculated correctly. Steps to Reproduce: ========================= - Install the maintenance module. - Create a maintenance request and set the Priority to High (3-starred) in the form view. - Open the dashboard. - Observe that the high-priority request count is not displayed. - The count always remains 0, even when high-priority requests exist. Cause of the issue: ========================= In this [PR](https://github.com/odoo/odoo/pull/94866), the logic was mistakenly changed. The priority field is defined as a Selection field, but while computing the count, the comparison was done against an integer(3, not '3') instead of the actual string value. Since the stored value is '3' (string), the condition is always evaluated to False, resulting in a count of 0. With This Commit: ========================= Ensure that high-priority maintenance requests are correctly counted and displayed on the dashboard when they exist. This provides better visibility of critical requests and helps users prioritise maintenance work effectively. Forward-Port-Of: odoo/odoo#244987
This update optimizes how Odoo sends notifications, specifically when the system is under heavy load. By using a faster JSON encoding library (orjson), the system processes notifications more efficiently, reducing delays and improving overall responsiveness. This results in a smoother user experience.
Original PR description
When the gevent server is under high load, the time required to acquire a cursor and fetch notifications increases. This causes notifications to accumulate, leading to larger payloads. Serializing these large payloads using the standard json library becomes a bottleneck. In a gevent environment, this monopolizes the event loop, delaying the processing of other greenlets. This commit introduces optional support for `orjson`. If installed, it is used to significantly speed up JSON encoding, freeing up the event loop. Using `orjson` increases the throughput by ~20% under high load. Forward-Port-Of: odoo/odoo#245072 Forward-Port-Of: odoo/odoo#241601
This update corrects a timezone discrepancy impacting invoices sent to ZATCA in Saudi Arabia. Previously, the system added a +03:00 offset, which ZATCA requires to be transmitted in the Asia/Riyadh timezone. This fix ensures invoices are formatted correctly for ZATCA compliance, preventing potential processing delays or errors.
Original PR description
The time information added to the date of the invoice post for ZATCA in iso format which adds +03:00. However ZATCA expects the time to be sent as is in Asia/Riyadh timezone. - Set up a ZATCA company and onboard a journal - To simulate the timezone issue, replace the hour value with 23h in the following line: vals['l10n_sa_confirmation_datetime'] = datetime.combine(move.invoice_date, fields.Datetime.now().time()). (use .replace(hour=23))) - Create, confirm, and send an invoice to ZATCA opw-5373067 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#244761 Forward-Port-Of: odoo/odoo#243961
This update removes the outdated 'Por Definir' payment method as the default for invoices, sale orders, and POS orders in the MX localization module. This change corrects a fiscal inconsistency, particularly when using the PUE payment policy, ensuring accurate reporting and compliance.
Original PR description
### Issue: The payment method `99 – Por Definir` was used as the default value for invoices, sale orders, and POS orders This leads to fiscal inconsistencies, especially when invoices use the `PUE`…
### Issue: The payment method `99 – Por Definir` was used as the default value for invoices, sale orders, and POS orders This leads to fiscal inconsistencies, especially when invoices use the `PUE` payment policy, where this payment method is invalid ### Cause: In the `_compute_l10n_mx_edi_payment_method_id` methods, the default value was always set to `Por Definir` ### Fix: After discussion with the PO (MIAL), the chosen solution is to archive the payment method `99 – Por Definir`and remove it as a default value All valid cases should already be handled explicitly, making it clear to the user that something is missing when the data is blank ### Steps to reproduce: - Install `l10n_mx_edi` and switch to the MX company - Create an invoice with today’s invoice date - The payment policy is set to PUE - Before the fix, the payment method is set to `Por Definir` For Sale Order and POS Order tests, it's the default value as soon as you create an order opw-5406038 Forward-Port-Of: odoo/enterprise#105058 Forward-Port-Of: odoo/enterprise#104164
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 an issue preventing bookings from being scheduled for the last hour of the day. The system was incorrectly flagging 23:59:59 as unavailable, blocking appointments. The fix ensures that appointment slots can now accurately include time ranges ending at 00:00, improving scheduling flexibility.
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 point of sale functionality within the l10n_ar_edi module for Arabic VAT. The fix ensures that sales transactions using the Arabic VAT accounting method are correctly processed, improving the module's core functionality for businesses operating in Argentina.
Original PR description
Tarea: 62909 Forward-Port-Of: odoo/enterprise#105104
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
This update fixes a calculation error in the Vietnam (l10n_vn) sales tax reports. The previous formula excluded 8% VAT transactions from the total sales base, leading to inaccurate reporting. This change ensures that all sales transactions, including those with 8% VAT, are correctly included in the report totals.
Original PR description
`VAT_SALES` report line aggregates total untaxed amount from its children lines. Previously, the formula for this line was missing `VAT_SALES_8.amount_untaxed`. As a result, the base amount for 8% VAT transactions was excluded from the total sales base calculation. This commit adds the missing tag to the `VAT_SALES` formula to ensure the total taxable base is calculated correctly. task-5836154 Forward-Port-Of: odoo/odoo#244915
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 provides more specific error messages when the message list fails to load. Previously, users only saw a generic 'Ann error occurred' message. Now, the commit displays the underlying error details, giving support teams a clearer understanding of the issue and its potential cause.
Original PR description
Backport of https://github.com/odoo/odoo/pull/244094 Before this commit, when message list failed to load, it just displays a "Ann error occurred" generic message with a retry button. This assumes that error happens rarely and when so this is temporarily. However some errors are persistent and it's frustrating to have no clue on why there's error or what may have caused it. This commit shows the `Error.toString()` from fetch message RPC failure on UI, so that there's a clue on the reason the fetch of messages failed. Before / After <img width="305" height="67" alt="Screenshot 2026-01-20 at 15 10 38" src="https://github.com/user-attachments/assets/34c546df-71e6-4055-9f85-8d85a9c89b35" /> <img width="334" height="100" alt="Screenshot 2026-01-20 at 15 09 07" src="https://github.com/user-attachments/assets/5fadd0b7-7ea0-43ca-8c28-0ac1d33650ff" /> Forward-Port-Of: odoo/odoo#245073 Forward-Port-Of: odoo/odoo#244754
This update resolves an issue where tax reverse charges weren't being accurately reported on BIS3 invoices. The system now correctly handles these charges by classifying them as 'Prepaid Amounts,' ensuring accurate tax calculations and compliance. This change improves the reliability of invoice data for international transactions.
Original PR description
There is no WithholdingTaxTotal node in BIS3. You cannot report any negative tax amount as taxes. You can only report VAT taxes but tax reverse charge are not considered as VAT. This commit reports the tax reverse charge amount as a PrepaidAmount instead. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240525
This update fixes an issue where zero-percent taxes (NT/EXEMPT) were incorrectly filtered out during downpayment creation in the Arabic localization. Previously, these taxes weren't properly accounted for, leading to incorrect calculations. This change ensures accurate tax reporting for downpayments and other scenarios.
Original PR description
Taxes 0% NT and 0% EXEMPT should not be fixed taxes. This is causing issue in some cases such as downpayments, where those taxes needs to be present, but fixed taxes are filtered at the creation of the downpayment. opw-5815953 Forward-Port-Of: odoo/odoo#245361 Forward-Port-Of: odoo/odoo#245252
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 issues related to error handling and compatibility with the UBL (Universal Business Language) tax extension for HR payroll. Specifically, it prevents conflicts with other UBL modules and now displays warnings for invoices that fail to fiscalize correctly, improving the reliability of payroll processing.
Original PR description
- Improving error handling for various requests - Adjusting XML generation to not conflict with `account_edi_ubl_cii_tax_extension` if it is installed - Adding a separate test for HR:E category taxes - Replacing skipping import of not successfully fiscalized document with warnings displayed on the moves after import task-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245028
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