Wednesday, January 7, 2026
26 changes · master
Resolved issues and error corrections
This update fixes an issue where invoices in USD were failing due to excessively long exchange rates. The solution rounds exchange rates to two decimal places, aligning with documentation requirements and ensuring accurate invoice processing for Vietnamese currency transactions.
Original PR description
* STEP TO REPRODUCE: create USD invoice to issue sinvoice, have currency rate like 26337.9186666777 , when issue we will get error because too many decimal * SOLUTION: round exchange rate up to 2 decimal because documentation said that is maximum Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241061
This update resolves an issue where deleting a specific product (Booking Fees) within the appointment scheduling module would trigger an access error. The fix involves using a special function to ensure the product's record can be accessed regardless of the currently selected company, preventing the error.
Original PR description
**Steps to produce:** - Install `appointment_account_payment` and `l10n_be` with demo data. - Go to product `Booking Fees` and assign company `YourCompany`. - Switch the current company to `Belgium Company`. - Try to delete any product. **Issue:** - An access error is raised when deleting a product. **Root cause:** - During product deletion, method `_unlink_except_booking_fee_product_template` is executed [1]. - If the 'Booking Fees' product is assigned to another company, the current company cannot access its record, which triggers an access error. **Solution:** - Use `sudo()` when fetching the "Booking Fees" product template so that the record can be accessed regardless of the current company. [1]: https://github.com/odoo/enterprise/blob/0ba44def7fd961e1c17aa218e1a86a48f0918371/appointment_account_payment/models/product_template.py#L9-L15 opw-5255991 --- Forward-Port-Of: odoo/enterprise#101582
A recent update to the Odoo Enterprise system prevented a crash that occurred when opening the part-time simulation salary package. This fix addressed a JavaScript error related to incorrect dropdown creation, ensuring the simulation function reliably for part-time employees. This resolves an issue impacting offer generation workflows.
Original PR description
Version: - 19.0 Steps to reproduce: - Open the salary package simulation form. - Add &part=True to the URL. Issue: - Opening the salary package simulation with `&part=True` in the URL caused a JavaScript error. - The working schedule dropdown was created incorrectly, leading to a crash. Fix: - Use ownerDocument.createElement to correctly create the wrapper element in JS. - Ensure new_calendar is always defined before accessing its id when preparing payslip values. task-5265734 Forward-Port-Of: odoo/enterprise#99641
This update prevents the accounting application from automatically contacting our external Odoo Fin server when opened. Previously, the accounting dashboard's 'favorite institutions' feature triggered a call to production.odoofin.com. This change adds a mock to ensure the accounting app functions correctly without unnecessary external communication.
Original PR description
The aim of this commit is making sure that the click all won't try to contact our external server odoo fin when the accounting application is opened. Indeed, the accounting application is displaying the favorite institutions for a particular country in the accounting dashboard which is doing a call to production.odoofin.com. This commit adds a mock using _request_handler to patch the call to odoo fin. runbot-error-231151 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223602
This update resolves an issue where users would encounter access errors when creating private tasks without assigned users or a project. The fix ensures that a user is automatically added to the task upon creation, granting them necessary access rights. This prevents the error and allows for seamless creation of private tasks.
Original PR description
When users would follow the following step as they are makeing a private task, they would be hit by an incorrect access error. ### Steps to reproduce: 1.Open the form view to create a new task.…
When users would follow the following step as they are makeing a private task, they would be hit by an incorrect access error. ### Steps to reproduce: 1.Open the form view to create a new task. 2.Clear the Project field. When empty, it should display the Private placeholder. 3.Ensure no user is assigned to the task. 4.Create the private task. 5.An access rights error occurs, stating that the user does not have permission to create the record. #### ⚠️ Note: This access rights error only occurs when the task is created directly as private. If a task is created normally and then its project_id and user_ids are removed afterward, no access rights error occurs. ### Root cause: When a task is created without a project_id and without assigned users, Odoo checks access rights on creation. Since no project members or assigned users exist, no user has access to the record, including the creator. This results in an access rights error during creation. This issue does not occur when modifying an existing task because, after creation, the creator is automatically added as a follower. As a follower, the creator retains access to the task even if it has no project and no assigned users. ### Fix (implemented): Tasks that have no assigned users and are not linked to any project (private tasks) did not make sense, as they were effectively assigned to nothing. To address this, we now require at least one user to be assigned to a task when it is not attached to a project. This change was made inside of the "project_task_view.xml" file in the "view_task_form_2" record Task: [5403926](https://www.odoo.com/odoo/project/4105/tasks/5403926) Version: 19.2a1+e --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes outdated demo data for the Odoo Sandbox, resolving validation warnings related to standard partners. The changes include the latest tax information, partner details, and company data, ensuring all validations now pass correctly. This improves the reliability of the demo environment for testing and training.
Original PR description
Our demo data for the Sandbox was outdated, and the new validations for the Other Seller ID triggered warnings. This commit updates the data to include the latest taxes, partners, and company details to ensure all validations pass. task-5152670 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a rounding issue that was causing slight discrepancies in the remaining time displayed on Sales Orders. The change ensures that time overages are accurately calculated without the accumulation of floating-point errors. This improves the precision of time tracking for service-based sales.
Original PR description
Steps to reproduce: - Create service product with UoM 'pack of 20 hours' and prepaid policy - Sell the product and confirm the Sales Order - Create a helpdesk ticket/task linked to the Sales Order…
Steps to reproduce: - Create service product with UoM 'pack of 20 hours' and prepaid policy - Sell the product and confirm the Sales Order - Create a helpdesk ticket/task linked to the Sales Order Line - Log 22:00 on timesheets Current behavior: Sales Order Line shows '-2:01 remaining' Expected behavior: Should show '-02:00' to reflect two hours overconsumed without rounding. Root cause: Python's float type follows the IEEE 754 double-precision standard, where only base-2 fractions can be stored precisely. Base-10 fractions cannot be represented exactly, introducing tiny rounding errors. During chained operations such as multiple conversions or subtractions, these small errors accumulate into larger discrepancies. The float_round() function uses a small constant epsilon to correct rounding noise, but as arithmetic chains grow, errors exceed epsilon's tolerance and it can no longer correct them. Since a single global epsilon cannot handle every case (small vs. large values, chained vs. single operations, or regressions), rounding drift is inevitable when rounding happens repeatedly. Fix: To prevent these rounding errors from compounding, the solution is to stop intermediate rounding altogether. By using conversions with round=False, all arithmetic is done in the base unit (hours) with full float precision, and rounding is applied only once when displaying the final value. This eliminates error accumulation and ensures consistent, drift-free results. task-5090240 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241120 Forward-Port-Of: odoo/odoo#229282
A technical bug was causing a traceback when using the AI button within the applicant refusal process. This issue stemmed from a missing required field, preventing the AI functionality from working correctly. The fix involved extending the relevant widget to correctly identify the applicant IDs, ensuring the AI button now functions as intended.
Original PR description
Step to reproduce: - Install hr_recruitment. - Open any applicant in any job position. - Click the Refuse button to open the refusal wizard. - Enable the send email toggle key. - Click on AI button Issue: traceback occurs Reason: - required field for using this widget is not defined. - so it tries to slice the res_ids field which is still not defined Solution: - In stable versions, we cannot add the missing required fields because this would cause upgrade issues. - Instead, we extend the widget and override its behavior to use active_model and active_id. task-5058510 Forward-Port-Of: odoo/enterprise#103384 Forward-Port-Of: odoo/enterprise#99498
This update resolves a technical issue related to type definitions within the Odoo mail module. The change ensures that the system correctly identifies and handles different types of messages, improving data accuracy and stability. This is a routine maintenance fix.
This update corrects a visual issue where resizing images within the HTML editor would cause a brief flicker. The problem stemmed from inconsistent mouse coordinate tracking between the iframe and the main window. This fix ensures smooth image resizing without the distracting flicker.
Original PR description
Problem: After 3b28df9eb22a3eb9af129a7f756986f54b983fc3, resizing an image during transform causes a visible flicker. Cause: The same mousemove handler is attached to listeners on both the iframe and the window. When the mouse moves from the iframe to the window, `ev.pageX` and `ev.pageY` differ between the two contexts, leading to incorrect position calculations and visual flickering. Solution: When `mousemove` is triggered, correctly recompute `pageX` and `pageY` when transitioning between iframe and window contexts, ensuring consistent coordinates during resize. Steps to reproduce: - Open website/jobs. - Try to transform and resize the image on the right. - Observe a flicker while resizing. opw-5368040 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240935
This update resolves a visual bug in the website blog where the author's avatar would incorrectly display as a small, rounded image after changing the author's contact information. The fix ensures that avatar updates are correctly applied within the website builder, maintaining consistent display across blog posts.
Original PR description
With the [website builder refactor], the avatar of the author of a blog post is updated when the author is changed. But with the [replication of fields] in the builder, if the avatar is present…
With the [website builder refactor], the avatar of the author of a blog post is updated when the author is changed. But with the [replication of fields] in the builder, if the avatar is present several times on the page with different options, the replication would overwrite some instances with the options of another. This commit avoids the avatar field from getting replicated (and avoids the weird removal of `o_dirty`) by updating the avatar of mutated fields in a `normalize_handlers`. Steps to reproduce: - Open website builder on a blog post - Enable the "Sidebar" - Enable the "Author" in the sidebar - Click on the name of the author in the page (any of the 2 instances) - Change the "Contact" associated with the author of the post - Bug: the avatar in the sidebar is now small and round like the other [website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 [replication of fields]: 7d7d6df5aaff52f740a54fe5234f0f778e3d4905 Forward-Port-Of: odoo/odoo#242221 Forward-Port-Of: odoo/odoo#234985
This update corrects a visual issue with the carousel's indicators, specifically when using 'Numbers' as the indicator style. Previously, the indicator colors were incorrect and the buttons weren't aligned properly. This change ensures indicators are clearly visible and buttons are correctly positioned for all indicator types.
Original PR description
The css rules for indicators outside the carousel were not adapted for number indicators, and used the button color intended for dots and bar as background of the numbers, making them unreadable and…
The css rules for indicators outside the carousel were not adapted for number indicators, and used the button color intended for dots and bar as background of the numbers, making them unreadable and ugly. The height of the indicators when outside influences the margin needed to align the bottom of the prev/next buttons. That caused the bottom of the next/prev buttons to not reach the bottom of the slide with "Numbers" or "Hidden" as indicators. This commit adds the necessary css rules to correctly size and colors the number indicators (and the hidden one) when positioned outside. Steps to reproduce - Add a carousel - Set "Indicators" to "Numbers" - Set "Style" to "Indicators outside" - Bug: The colors are all wrong, we cannot see the numbers - Bug: The bottom of the previous/next buttons do not reach the bottom of the carousel - Set "Indicators" to "Hidden" - Bug: The bottom of the previous/next buttons is even further from the bottom of the carousel task- 5358507 Forward-Port-Of: odoo/odoo#237397
This update fixes an issue where the UBL XML invoices were including the 'Invoice address' suffix in the partner name. The change ensures that the correct commercial partner name is used, aligning with standard Odoo XML generation and improving invoice accuracy. This ensures consistent and accurate data exchange with trading partners.
Original PR description
The dict-to-xml helpers were still using `partner.display_name` which includes the 'Invoice address' suffix. Changed to use `partner.commercial_partner_id.display_name` when partner name is not available, to match the fix in https://github.com/odoo/odoo/pull/232819 for the standard XML generation. task-4614564 Forward-Port-Of: odoo/odoo#242200 Forward-Port-Of: odoo/odoo#241250
This update corrects a visual issue where the OCR label for expense documents was incorrectly displayed alongside the data field, causing a misalignment in the expense report grid. The fix ensures that all labels are correctly positioned, improving the user experience when processing expenses with OCR data. Testing requires OCR credits or a trial account.
Original PR description
Prerequisites ------------- To test this scenario you need either OCR credits, a free trial or to use the IAP account we have in the spreadsheet. Steps To Reproduce ------------------ 1- Go to Expenses > My Expenses. 2- Upload a receipt to trigger OCR. 3- Open the expense in Normal Mode (It works fine in Debug Mode). Issue ----- "Payment Method" field is misaligned - label appears in the value column and field appears in the label column. Cause ----- The label for "ID of the request to IAP-OCR" (`extract_document_uuid`) is visible when OCR data exists, but its field is only visible in Debug Mode. This orphan label breaks the grid layout. opw-5369619 Forward-Port-Of: odoo/enterprise#103189
This update fixes an issue where the analytic distribution field in Odoo contained unexpected data types, specifically the '__update__' string, which caused errors during account ID retrieval. The change now safely processes only strings that can be interpreted as numbers, providing a more robust and reliable system for managing analytic accounts.
Original PR description
Issue: Before this commit, the analytic distribution field contained a mix of integers (account IDs) and strings (such as '__update__'). When attempting to retrieve the account ID, converting the '__update__' string to an integer caused an error. Fix: As a generic solution, instead of skipping only the '__update__' key—which may not be the only non-numeric string in the future—we now process only the strings that can be safely interpreted as numbers. opw-5450293 Forward-Port-Of: odoo/odoo#242021
This update fixes an issue where job offer emails didn't include the employee's name in the subject line. Now, the email subject will automatically include the employee's name, improving email clarity and making it easier to identify offers. This change was implemented as a simple fix to enhance the user experience.
Original PR description
**Steps to reproduce:** - Go to Employees app and select any employee - Press "Offers" smart button - Create a new job offer and send it by email **Issue:** The employee name is not populated in the email subject. Task: 5407028 Forward-Port-Of: odoo/enterprise#102628
This update ensures the live chat info panel remembers your preference (open or closed) across different chat sessions. Previously, the panel always opened by default, leading to a frustrating experience. Now, the panel will automatically adjust to your last setting, improving ease of use.
Original PR description
**Purpose of this PR:** Previously, the livechat info panel would always open by default when switching between chats, regardless of the user's preference. This required users to manually close the panel repeatedly. This commit persists the panel's toggle state, so the panel remains open or closed based on the user's last choice across all livechat sessions. Task-5291258 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241917 Forward-Port-Of: odoo/odoo#238472
This update resolves an issue where tax grouping keys in the account_edi_ubl module could sometimes be unexpectedly empty. This fix ensures accurate tax calculations and reporting, particularly when using customizations. A minor correction was also made regarding excise taxes to improve data accuracy.
Original PR description
Some overrides assign a value to the tax's grouping_key after the super call. However, the returned value could be None. Also fix a little mistake regarding excise taxes. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239959 Forward-Port-Of: odoo/odoo#239954
This update resolves an issue where users were encountering an error when previewing XML files containing embedded PDFs. The fix ensures that thumbnails are only generated for valid PDF files, preventing the 'Invalid Operation' error and improving the user experience when working with documents.
Original PR description
Steps to reproduce: 1. Install `documents` 2. Upload an XML file that contains an embedded PDF in base64. 3. Click on the `Info & Tags` icon on the top right in the Documents kanban view 4. Open the imported XML file Issue: - An `Invalid Operation: Only PDF files can have thumbnail` error occurs. Cause: - The `Attachment` model attempts to generate a thumbnail for the XML file because it contains PDF data. However, as of now, thumbnails are only generated for valid PDFs, so the `generatePdfThumbnail` function returns `isPdfValid: false` but `setPdfThumbnail` method fails to handle this `false` value in resulting invalid rpc call. Solution: - Update the condition in `setPdfThumbnail` to consider only valid PDFs. File: [Link](https://drive.google.com/file/d/19OxVJeqj9i-VgH9D6Aqk0P9Tuf6zlPwB/view?usp=sharing) opw-5374529 Forward-Port-Of: odoo/odoo#240546
This update adjusts a timeout setting in the SMTPD tests, preventing unnecessary test failures. Previously, a short delay caused tests to fail frequently, triggering alerts. Now, the tests have more flexibility to complete without being disrupted by overly strict time limits, improving overall system reliability.
Original PR description
There are multiple cases where the SMTPD tests fail due to a timeout error. It is much worse to get a red runbot due to a silly timeout than to sometime wait a bit longer than .1 second. 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#242214
A bug preventing users from searching within sign templates has been fixed. Previously, the search function within PDF templates was unresponsive. This update removes a technical issue that blocked users from utilizing the search feature, ensuring they can efficiently locate information within sign templates.
Original PR description
Currently when the user is viewing sign templates, they are unable to search within a PDF. **Steps to replicate:** * Install `sign` with demo data * Sign > Templates > Open a template * Try searching using the magnifying glass button **Observed Behavior:** * User is unable to type anything in the PDF search box. **Root cause:** * This error happens because `preventDefault()` is called during a `keydown` event. At [1], calling `event.preventDefault()` stops the key’s normal behavior, so the typed character is not added to the input field. **Solution:** * Remove the `preventDefault` call which allows the search to work again. [1]: https://github.com/odoo/enterprise/blob/3df585779e6ede664279331c4531043688dadf17/sign/static/src/backend_components/editable_pdf_iframe_mixin.js#L623 opw-5366074 Forward-Port-Of: odoo/enterprise#102749
This update fixes a technical issue that caused a traceback to appear when canceling orders with the 'Takeout or Delivery' preset. The fix redirects users to the correct screen and prevents new orders from being created during the cancellation process, improving the user experience.
Original PR description
### step to reproduce: - Set default preset to "Takeout or Delivery" in restaurant config. - Open restaurant . - Open any table and add a product. - Cancel the order using the action button. ### issue: - A popup appears asking to select a partner/floating order name, followed by a traceback. ### cause: - Traceback occures as next screen is loaded after order deletion. ### fix: - Redirect to the default screen before deleting the order. - Ensure that no new order is created when the next screen is the floor screen. task: 5092951 Forward-Port-Of: odoo/odoo#242199 Forward-Port-Of: odoo/odoo#227925
This update fixes an issue where iOS devices were not displaying the website's favicon when creating shortcuts. The change adds a specific HTML tag to ensure the correct icon is shown, improving the user experience on iOS PWA devices. This ensures a more professional and consistent brand appearance.
Original PR description
iOS devices currently display the first letter of the website name instead of a favicon when creating a shortcut. This commit adds the `apple-touch-icon` link tag referencing the favicon to ensure the icon displays correctly. task-5427275
This update resolves a random error that occasionally occurred during the project task tour. The fix utilizes a more specific trigger to ensure the tour initiates reliably, improving the user experience. This ensures consistent and accurate tour functionality.
Original PR description
Fix this random error in the tour by using a more precise trigger. runbot-error-id~234373 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where delivery slips were printing move lines in the wrong order, primarily when multiple products were included in a single delivery. The fix ensures that move lines are printed in the same order as their associated stock moves, resulting in accurate and consistent delivery slip reports. This improves the reliability of our inventory tracking process.
Original PR description
**Steps to reproduce:** - Add 2 products in a delivery - Add the second's product move lines before the first one. - Validate and print delivery slip **Issue:** We iterate the `move_line_ids` directly which means if we have a new move line for a move with a lower id, it will push the product to the end of the delivery slip. **Example:** If we have `stock.move(1,)` with `stock.move_line(52,)` and `stock.move(2,)` with `stock.move_line(51,)`. `stock.move_line(51,)` will be printed first, which introduces a change in the order of the delivery slip. **Fix:** Iterate on `move_ids` and access `move_line_ids` through it, to print `move_lines_ids` in the same order of the `move_id`. Task: 4570203 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242166 Forward-Port-Of: odoo/odoo#213400
This update resolves an issue where a website tour feature timed out during testing, specifically when searching for products. The fix ensures the tour waits for the dropdown to populate before initiating a search, preventing unnecessary clicks and ensuring a smoother user experience. The `searchNeeded` parameter has been removed as it was no longer required.
Original PR description
__Behavior before commit:__ When `searchNeeded` is `true`, `changeOptionInPopover` adds a step to search the option in the dropdown. This step is not working if the dropdown is not ready. This causes `add_to_cart_snippet_tour` to timeout when the tests are run with demo data because the products created in the python side of the test are not showing directly. If the demo data are not included and `searchNeeded` is `true`, it is useless to search. Furthermore in this case, it might click on the item before the search request is finished. The popover will then be kept open when the request end (without result because the search will exclude the already selected item). __Fix:__ - Wait for the dropdown to be ready by waiting for the items to appear in the dropwdown. Then only make the search if the item isn't already in the list. - Remove the now useless `searchNeeded` parameter runbot-234680 Forward-Port-Of: odoo/odoo#242312 Forward-Port-Of: odoo/odoo#240193