Monday, March 9, 2026
27 changes · 19.0
Enhancements to existing features
Not sure if this is the proper way to add translations, just let me know. <img width="419" height="189" alt="product_catalog_translation" src="https://github.com/user-attachments/assets/652845bb-9243-4323-943d-b85ceb9da3c7" />
Original PR description
Not sure if this is the proper way to add translations, just let me know. <img width="419" height="189" alt="product_catalog_translation" src="https://github.com/user-attachments/assets/652845bb-9243-4323-943d-b85ceb9da3c7" />
The geolocation module now separates how external service API keys are retrieved from the rest of the location lookup process. This makes the feature easier to maintain and adapt without changing user-facing behavior.
Original PR description
Move the api key retrieval to another method. Forward-Port-Of: odoo/odoo#252342 Forward-Port-Of: odoo/odoo#243496
This update adjusts the trial balance reports in the Mexican accounting module (l10n_mx_reports) to align with the latest accounting standards in Mexico (CoA). This ensures accurate reporting and compliance for Mexican businesses using Odoo Enterprise.
Original PR description
Adapted trial balance tests to consider update on MX CoA task-4920083 target: 19.0 -> master
Resolved issues and error corrections
Some demo live chat conversations that already had feedback were still shown as active because they were missing an end time. This fix marks those demo sessions as ended, so the information panel shows the correct outcome details instead of ongoing chat status.
Original PR description
**Description of the issue this PR addresses:** ---------------------------------------------- Some livechat demo sessions included feedback/ratings but were still displayed as active conversations…
**Description of the issue this PR addresses:** ---------------------------------------------- Some livechat demo sessions included feedback/ratings but were still displayed as active conversations in the info side panel. This created inconsistent demo data where closed conversations appeared with options meant for ongoing chats (e.g., status shown instead of outcome). **Current behavior before PR:** ---------------------------------------------- - Certain demo livechat sessions had ratings applied but no explicit livechat_end_dt set. - As a result, the info side panel treated them as ongoing conversations. - This caused mismatched UI information for demo data. **Desired behavior after PR is merged:** ---------------------------------------------- - Demo livechat sessions that received feedback are explicitly marked as ended using livechat_end_dt. - The info side panel correctly reflects closed conversations with coherent outcome information. Task-5412081 ---------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250001
This update fixes an automated website test that checks the auto-hide menu behavior. The test now waits for the page frame to be ready after navigation, reducing false failures and improving release confidence without changing customer-facing functionality.
Original PR description
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#239614
The change removes an internal system method from generated API documentation because it cannot actually be called through the supported API. This prevents customers and integrators from relying on misleading documentation and reduces confusion when using Odoo's API references.
Original PR description
It was documented within Doc API, but it cannot be called through the Json2 API. This change removes method from API documentation: `/doc-bearer/<model>.json` and `/doc/<model>.json`, etc... --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Customers no longer see a leave conversation warning after a chatbot conversation has already ended. This avoids confusion when closing or continuing from a completed chat while keeping the warning for active conversations.
Original PR description
Before this commit: When a user finishes a chatbot script and the conversation is already ended, clicking on close / continue still triggers the leave conversation warning. After this commit: The leave conversation warning is no longer shown when the chatbot conversation is already closed or ended. The warning is only shown for active conversations. [Task-5882084](https://www.odoo.com/odoo/project/1519/tasks/5882084) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251904 Forward-Port-Of: odoo/odoo#247918
The chart granularity dropdown in Spreadsheet Dashboard now displays correctly in Chrome, with the label and icon aligned side by side. The picker icon also remains visible in dark mode and rotates more smoothly, making the control clearer and easier to use.
Original PR description
## Description of the issue/feature this PR addresses: Current behavior before PR: - In Chrome, the select dropdown showed label and picker icon stacked vertically. - In dark mode, the picker icon was not clearly visible due to a change in picker color. Desired behavior after PR is merged: - Use flex + align-items: center to align label and icon horizontally. - Use a fixed spreadsheet color for the icon to ensure visibility. - Add a transition for smooth picker icon rotation. Task: [5418157](https://www.odoo.com/odoo/project/2328/tasks/5418157) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change keeps a temporary safeguard in the API documentation area for databases upgraded from older versions that may still contain incorrectly renamed fields. It helps prevent issues for affected customers until a proper upgrade script is available.
Original PR description
This reverts commit d29c2ea2c32204302e5043f1b67e0905e7025bfc. There are databases that were upgraded from <19 and that still have badly renamed fields. So keep the bandaid, at least until we can have an upgrade script. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes automated checks for sales and purchase flows so they wait for product details to finish loading before continuing. It helps prevent false failures where an order could remain in draft during testing, improving confidence in release validation without changing everyday user workflows.
Original PR description
There is an inaccuracy in the steps of the tour: - test_basic_sale_flow_with_minimal_access_rights Indeed, in this test a new line is added on the order and a product is selected but the next step…
There is an inaccuracy in the steps of the tour: - test_basic_sale_flow_with_minimal_access_rights Indeed, in this test a new line is added on the order and a product is selected but the next step confirms the order without waiting for all the associated onchanges to be taken into accounts: https://github.com/odoo/odoo/blob/b5511e5ebb919c2c506131bf9e2a4196dac25f79/addons/sale_management/static/tests/tours/sale_flow_tour.js#L14-L20 https://github.com/odoo/odoo/blob/b5511e5ebb919c2c506131bf9e2a4196dac25f79/addons/sale/static/src/js/tours/tour_utils.js#L27-L47 In the case where the confirmation happends before the product edition is taken into account, the order fails to confirm and stays in draft which makes the rest of the tour fails. Note: The same issue could happen at some point on the equivalent purchase test, so that we also modify the test: - test_basic_purchase_flow_with_minimal_access_rights runbot-241198 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Quotation previews now avoid showing duplicate section totals with zero value when combo products are hidden under a section. This makes sales documents clearer for customers and prevents unnecessary clutter in the preview.
Original PR description
**Behavior:** When a combo product is added under a section and the 'Hide Composition' option is selected the system will try to get a list of the prices grouped by different taxes, however since combo items usually don't cost anything and are not under any tax group, the quotation preview will try show the section's total prices under no tax which will likely amount to 0$ This results in a bloated preview. Solution: Only accept a grouping under a specific tax (be it no tax or a real tax) if the total price != 0$ **Steps to reproduce:** - Create a combo product containing a product that is taxed - Create a quote with a section - Add the product under the section - Check 'Hide Composition' in the section's options - Preview the sale - You'll notice the section duplicated with no tax and no price opw-5481931
Public holiday timesheets are now generated only for employees whose company matches the holiday's company. This prevents employees in another company from receiving incorrect timesheet entries when companies share the same working schedule.
Original PR description
**Steps to reproduce** - Have 2 companies A and B - Use a single working schedule (needs to have no company on it) for both companies and their employees - Create a public holiday with company A, while having company B in the selected companies - There's a timesheet for the public holiday created for employees of company B, even though the public holiday will not apply for them. **Change** Only generate the timesheets for employees belonging to the companies of the public holidays. opw-5498462 Forward-Port-Of: odoo/odoo#245743
Task assignment notification emails are now removed automatically after they are sent. This prevents unnecessary email records from building up over time, helping keep the system database cleaner without changing the user experience.
Original PR description
Task assignment notification emails (sent via message_notify when a user is assigned to a project task) were configured with mail_auto_delete=False, causing them to accumulate in the mail.mail table indefinitely. These are transient notifications that don't need to be retained after sending.
Working schedules that use a fixed number of hours per day now calculate average daily hours and weekly totals correctly. This helps HR teams see accurate schedule totals when employees work duration-based days instead of start and end times.
Original PR description
## Short functional explanation of the error When editing attendances of a schedule for which we checked the box `Define Amount of Hours per Day`, the resulting average hours per day and hours per…
## Short functional explanation of the error When editing attendances of a schedule for which we checked the box `Define Amount of Hours per Day`, the resulting average hours per day and hours per week fields aren't computed correctly. ## Reproduction Steps 1. Go to Employee > configuration > Working Schedules. 2. Create a working schedule. Check the box Define Amount of Hours per day and in the Working Hours tab, remove all intendances. 3. Add a line for Monday, set the day period to Full Day and the duration in hours to 4. 4. Repeat the operation for tuesday and wednesday. ### Expected behavior As we have 3 days during which we work 4 hours, the average hours per day should be 4, and the total hours per week should be 12. ### Unexpected behavior The average hours per day and hours per week don't show the correct numbers. ## Origin of the issue We compute the hours per week with this method: https://github.com/odoo/odoo/blob/ae9fd7cc7d434d4b222c81aa58515c57d7426b65/addons/resource/models/resource_calendar.py#L690-L696 However, when we check the box `Define Amount of Hours per Day`, we don't set the attendances starting and ending hours. Instead, we work with duration hours. Therefore, when the box is checked, we have to compute the weekly hours with the field `duration_hours`, and not `hour_from` / `hour_to`. __ opw-5885571
Dynamic product carousels now stay on a single slide when all fetched items already fit in the visible area. This prevents confusing one-by-one sliding and gives website visitors a cleaner browsing experience.
Original PR description
Steps to reproduce: 1. Add a Dynamic Snippet Carousel(Products). 2. Set the number of records to 4. 3. Enable Single Scroll mode. Issue: When a dynamic snippet carousel is in single scroll mode…
Steps to reproduce: 1. Add a Dynamic Snippet Carousel(Products). 2. Set the number of records to 4. 3. Enable Single Scroll mode. Issue: When a dynamic snippet carousel is in single scroll mode (`o_carousel_multi_items`) and the number of fetched items is less than or equal to the visible slots per slide (`chunkSize`, typically 4 on desktop), the carousel still slides one item at a time. Cause: When `scrollMode` is single, the QWeb template generates each data item in its own `carousel-item` div. So with 3 products and 4 visible slots, we got 3 separate slides(this is the usual behavior of single scroll mode). But due to this bootstrap would slide between them one by one. Fix: If the number of fetched records is less than or equal to the number of elements per slide (chunkSize), use "all" scroll mode so that all items are grouped in a single slide instead of being split into individual carousel-items (which would cause unwanted sliding). Forward-Port-Of: odoo/odoo#251700
This fix restores the expected inheritance behavior after a method name change was not applied consistently. It helps prevent errors in stock-related accounting flows used by purchasing, sales, and point-of-sale operations.
Original PR description
**Description of the issue/feature this PR addresses:** A new method name was introduced but not fixed in the inherited modules which leads to a missing method in their related super call. **Current behavior before PR:** Missing super method in related super calls in these modules **Desired behavior after PR is merged:** Proper inheritance based on a method removed by accident Info: @wt-io-it --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adjusts an internal test for the purchase replenishment process so it focuses on preventing a known error rather than depending on a specific buying route. It helps keep automated quality checks stable and reduces the risk of regressions reaching users.
Original PR description
Runbot error 241249
This fix stops Odoo from making external location lookups or sending emails while demo data is being installed on an existing database. It helps avoid unexpected costs, side effects, and unnecessary notifications during setup or testing.
Original PR description
Followup on https://github.com/odoo/odoo/pull/25086 to avoid makin api calls, sending emails when installing demo data on an existing database
Installing demo data on an existing database no longer triggers certain external calls or outgoing emails. This reduces unintended notifications and third-party API usage during setup or testing, helping keep demo installation safer and cleaner.
Original PR description
Followup on https://github.com/odoo/odoo/pull/25086 to avoid makin api calls, sending emails when installing demo data on an existing database
This update ensures that users only see the option to 'Insert in spreadsheet' within list view menus if they have the necessary permissions for Documents and Dashboards. Previously, users without these permissions could still access the action, which has now been corrected for improved security and user experience.
Original PR description
Current behavior before PR: - The 'Insert in spreadsheet' action was always visible in the list view action menu, even when the user lacked access rights for Documents or Dashboards. Desired behavior after PR is merged: - The action is shown in the list view action menu only if the user has the required permissions. Task: 5930184 Forward-Port-Of: odoo/enterprise#109739 Forward-Port-Of: odoo/enterprise#108099
This update fixes an issue where users without proper permissions could access the 'Insert in spreadsheet' action in the Kanban view. Now, the action is only visible to users with the necessary permissions, and the restriction on inserting records based on grouped m2m fields has been removed, streamlining the process.
Original PR description
Current behavior before PR: - The 'Insert in spreadsheet' action was always visible in the kanban view action menu, even when the user lacked access rights for Documents or Dashboards. - Inserting records from a kanban view into a spreadsheet was blocked when the view was grouped by an m2m field. Desired behavior after PR is merged: - The action is shown in the kanban view action menu only if the user has the required permissions. - The m2m field check is removed when inserting from kanban views. Task: 5930184 Forward-Port-Of: odoo/enterprise#108098
This fix prevents a data error that occurred when generating work entries after overtime lines were created. The issue stemmed from an incorrect domain used to unlink overtime lines, leading to a 'ValueError'. This ensures work entries are consistently accessible after overtime generation.
Original PR description
__ ## Short functional explanation of the error When trying to access work entries after having generated similar overtime lines, an error occurs. This commit prevents the error to occur on databases…
__ ## Short functional explanation of the error When trying to access work entries after having generated similar overtime lines, an error occurs. This commit prevents the error to occur on databases where similar overtime lines have already been generated, but the prevention of duplicating overtime lines is implemented in commit 7bc84a920ba39457cb89cf2b93b2e769060c2854 on community. ## Reproduction Steps 1. Create an employee. The time zone of the employee should be different from the one on his work schedule. To be sure to replicate the bug, set the time zone of the work schedule to Pacific/Fiji (GMT +12). Set his Work Entry Source to Attendances, and in settings, set an overtime ruleset. 2. On this ruleset, select a rule and select 'From a specific duration', and in the field Duration to Exceed, write 8 hours. 3. Go to Attendances. Create an attendance from 3 am to 3 pm, save and close. 4. Click on the Configuration tab > Rulesets, click on the ruleset and click on Regenerate overtimes. 5. Try to open Work Entries. ### Expected behavior The Work Entries show. ### Unexpected behavior An error occurs: `ValueError: Expected singleton: hr.attendance.overtime.line` ## Origin of the issue When regenerating overtimes, we unlink the previously created overtime lines. However, as the domain to retrieve such lines wasn't set correctly, the overtime line of day 2 wasn't included in the lines to unlink. __ opw-5908447
This update removes unnecessary customizations related to Swiss payroll calculations within the payrun process. The core logic has been corrected, eliminating redundant and potentially conflicting rules. This ensures accurate and compliant payroll processing for Swiss users.
Original PR description
Not necessary anymore, standard logic has been fixed Forward-Port-Of: odoo/enterprise#108121
This update resolves a technical issue that prevented basic receipts with long POS names from printing correctly. The problem stemmed from a calculation error when padding text, causing a runtime error. This fix ensures all POS names, regardless of length, can be accurately printed on basic receipts.
Original PR description
When printing a basic receipt, if the pos name is too long a traceback will occurs when printing the basic receipt. Steps to reproduce: * Create a pos with a name of 46 character or more * Setup the italian fiscal printer * Enable Basic Receipt printing * Open point of sale * Create an order and validate it * Try "Print Basic receipt" Traceback: RangeError: Invalid count value: -15 at String.repeat () If the data being printed is longer than the maximum number of character in a line (MAX_CHARS = 46), paddingLeft becomes negative which cause an error in repeat(). [Similar solution](https://github.com/odoo/enterprise/blob/18.0/l10n_it_pos/static/src/app/fiscal_printer/commands/print_rec_message/print_rec_message.js#L35) [opw-5270697](https://www.odoo.com/odoo/project/49/tasks/5270697) Forward-Port-Of: odoo/enterprise#109527
This update resolves an issue where the AI module installation would fail due to insufficient PostgreSQL user permissions. By checking if the `pg_vector` extension is already installed before attempting to create it, we avoid errors and streamline the installation process without granting excessive database privileges.
Original PR description
[FIX] ai: test if pg_vector is installed before launching the create extension command
The command `CREATE EXTENSION IF EXISTS ...` require the postgresql user to have rights to use the command `CREATE EXTENSION`.
If the extension is already installed it will fail with a stacktrace because of inssuficient rights. `psycopg2.errors.InsufficientPrivilege`
With this PR we want to be able to install the module without giving too many rights to the postgresql user.This update ensures that German customer addresses are correctly formatted when used with Amazon. Previously, the system incorrectly sent company names as the primary address line, causing delivery validation errors. This change swaps the fields to ensure accurate address formatting and successful delivery.
Original PR description
When filling in a German address on Amazon, customers are presented with two fields: - Street, and - Building or company name. The street is sent as AddressLine2, while the building/company name is sent as AddressLine1. However, delivery providers validate address existence, which fails when address line 1 is not a street name. To resolve this, we swap these two fields for German addresses. opw-4668178 Forward-Port-Of: odoo/enterprise#109215
This update fixes an issue where users weren't seeing ratings for helpdesk tickets when they weren't part of the team assigned to those tickets. The change ensures all ratings for assigned tickets are displayed in the average rating views, regardless of team membership. This improves the accuracy of customer feedback reporting.
Original PR description
Steps to reproduce: - Configure a helpdesk team to be viewable by the test user - Remove test user from member_ids of helpdesk team - With that team selected, create a helpdesk ticket assigned to test user - Submit a rating for the ticket as the customer - As the test user in the helpdesk app overview, click on today average rating or last 7 days average rating Current behavior: - In both views, the test user won't see ratings for tickets attached to helpdesk teams where they are not listed in member_ids Expected behavior: - In both views, the test user should see all ratings of assigned tickets regardless if they are included in a helpdesk team's member_ids Note: member_ids in helpdesk.team appear to be only used for auto assigning new helpdesk tickets, so checking member_ids doesn't account for all potential users working in a team opw-5949917 Forward-Port-Of: odoo/enterprise#109136