Friday, September 18, 2026
10 changes · saas-19.1
Resolved issues and error corrections
This fixes the Discuss quick reaction menu so users can hold Shift when choosing an emoji to keep the picker open. It makes adding several reactions in a row smoother by avoiding the need to reopen the picker each time.
Original PR description
When adding a reaction to a message in Discuss, selecting an emoji adds the reaction and closes the emoji picker. This can be inconvenient when adding multiple reactions in a row, as the picker has to be reopened every time. To address this problem, the emoji picker remains open when the user holds Shift while selecting an emoji. However, this behavior was overlooked when implementing the Quick Reaction Menu, which therefore closes the emoji picker upon emoji selection, regardless of whether Shift is pressed. This commit fixes the Quick Reaction Menu so that holding Shift while selecting an emoji once again prevents the emoji picker from closing. [Task-6575382](https://www.odoo.com/odoo/project/1519/tasks/6575382) Forward-Port-Of: odoo/odoo#288336
This fixes a problem where installing Chilean localization demo data alongside other localization modules could fail. The change ensures only appropriate Chilean demo accounting entries are posted, so demo companies are set up correctly for testing and evaluation.
Original PR description
When several localization modules are installed at once (with demo data), loading the chilean demo data fails and the chilean demo company ends up without any accounting demo data. Steps to reproduce: - Install `l10n_cl` together with the other localizations and the enterprise addons, with demo data enabled Issue: Error while loading accounting demo data ValidationError: Document types for foreign customers must be export type (codes 110, 111 or 112) or you should define the customer as an end consumer and use receipts (codes 39 or 41) Analysis: Demo methods will posts every move of the chilean company, not only the ones prepared by the module. In combination with other modules loading their own demo data it may raise the said error.
This fixes an automated stock workflow test that could fail when the Turkish Nilvera e-Dispatch localization was installed. The change helps ensure stock operations remain consistently tested across localized Odoo setups without changing user-facing inventory behavior.
Original PR description
### Steps to reproduce: - Install `l10n_tr_nilvera_edispatch` (e.g. the `tr` country build) - Run `test_basic_stock_flow_with_minimal_access_rights` > The tour times out on step 6/31, "check that at…
### Steps to reproduce: - Install `l10n_tr_nilvera_edispatch` (e.g. the `tr` country build) - Run `test_basic_stock_flow_with_minimal_access_rights` > The tour times out on step 6/31, "check that at least one picking is present in the view". ### Cause of the issue: The step triggers on `.o_stock_list_view_view`, a class the web client derives from the `js_class` of `stock.vpicktree`: https://github.com/odoo/odoo/blob/71c040ae236c9487afc49559486a588f21ccb37b/addons/stock/views/stock_picking_views.xml#L66-L70 https://github.com/odoo/odoo/blob/71c040ae236c9487afc49559486a588f21ccb37b/addons/web/static/src/views/utils.js#L45-L68 `l10n_tr_nilvera_edispatch` overwrites that attribute to plug in its e-Receipt upload button, so the root carries `o_l10n_tr_edispatch_tree_view` instead and the trigger never matches: https://github.com/odoo/odoo/blob/71c040ae236c9487afc49559486a588f21ccb37b/addons/l10n_tr_nilvera_edispatch/views/stock_picking_views.xml#L4-L13 Only the class name changes: `L10nTrNilveraEdispatchListView` spreads `StockListView`, so the rendered list is identical. runbot-947260 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#288255
Invoices that have already been sent through PEPPOL can no longer be selected for sending again. This avoids duplicate submissions and makes the send option clearly unavailable when it should not be used.
Original PR description
If the invoice is already sent through PEPPOL, the checkbox for sending the invoice should then be readonly and unchecked. Currently is correctly unchecked but not readonly. We fix it by copying what French localization (`l10n_fr_pdp`) does already, giving a reason for disabling. <img width="1359" height="948" alt="immagine" src="https://github.com/user-attachments/assets/6f91ab34-8989-487e-8cd9-96dafee7bcb5" /> . Pad: https://pad.odoo.com/p/accountingv20 pad-accountingv20 Forward-Port-Of: odoo/odoo#288898
Generic demo leave types no longer carry a specific country, so they will not interfere when setting a company's country in demo or development databases. Real country-specific leave rules remain protected, while demo installs become easier to configure.
Original PR description
_check_country_change_holidays constraint blocks writes to res.company.country_id whenever hr.leave/hr.leave.allocation records exist whose leave type country differs from the new company country. Unset country_id on the generic holiday_status_* demo leave types they are not meant to represent a specific country's holiday policy, so they should not carry a country at all. With country_id set to False, they no longer participate in the country-change constraint. The constraint keeps protecting real country changes on business data, while no longer blocking legitimate demo installs where we configure the main company with our country but rely on demo data for dev instances. Related to https://github.com/odoo/odoo/pull/277346 Forward-Port-Of: odoo/odoo#278749
This update removes an unnecessary internal step when creating maintenance requests. Maintenance teams are already assigned correctly automatically, so the change keeps the code cleaner without changing how users work.
Original PR description
The create method assigned request.maintenance_team_id to itself, a no-op that reads and writes the same value and has no effect. This line originally set the team from the equipment as a fallback when creating a request. PR #196181, while refactoring mail alias handling from equipment category to team, replaced that assignment with a self-assignment, turning it into dead code. maintenance_team_id is a required field and is already a stored compute depending on equipment_id, so it is computed correctly on create without this line. Removing it has no functional impact. Forward-Port-Of: odoo/odoo#286132
A navigation issue in the API documentation was fixed so opening a related field in a new tab now goes to the correct related model instead of the original model. This makes browsing model relationships more reliable and avoids confusion for users consulting technical documentation.
Original PR description
Steps to reproduce: * open api_doc * select a model (eg: project.task) * middle click on a many2one field (eg: stage_id) Observed behavior: The new tab is opened on the base model (project.task) instead of the comodel (project.task.type). This commit fixes the issue by using `t-att-href` to point to the correct model and `preventDefault` to avoid a full reload when clicking on a m2o. Forward-Port-Of: odoo/odoo#288558
This fixes an issue where some grid views could appear empty after the page rebuilt a scrollable area. The grid now recalculates immediately when that area changes, reducing confusion and avoiding the need for users to scroll or resize the window to restore content.
Original PR description
See commit messages for details. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#281721
When helpdesk tickets are merged, related timesheets now keep the same sales order item as the destination ticket. This prevents mismatched sales information after a merge and helps keep service reporting and billing data consistent.
Original PR description
Currently when you merge helpdesk tickets with differing sale order items, the sales order item listed on the timesheets of the source ticket is not updated to match the destination ticket's sales order item. This PR ensures uniformity bugfix-6473396 Forward-Port-Of: odoo/enterprise#131155 Forward-Port-Of: odoo/enterprise#129060
Appointments created from the calendar now use the exact time slot selected by the user instead of defaulting to the appointment type duration. This prevents bookings from being longer or shorter than intended and makes calendar scheduling more reliable.
Original PR description
When creating an event from the calendar view of an appointment type, the duration of the event was set to the duration of the appointment, therefore bypassing the slot we drew. This commit fixes this behavior by giving the priority to the end date of the drawed slot. Task-6412432 Forward-Port-Of: odoo/enterprise#130171