Monday, September 21, 2026
87 changes · master
Resolved issues and error corrections
The HR contract template field is now handled correctly even when Payroll is not installed. This prevents confusion for HR users by ensuring the field remains available in standard HR setups where it is expected.
Original PR description
The field can be seen if payroll is not installed. runbot-947214 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#288219
Discuss avatars now display status indicators with masks that match each icon's actual shape, rather than forcing every status into a circle. This improves visual clarity for special statuses such as on leave, homeworking, in office, and OdooBot indicators.
Original PR description
Before this commit, the mask of im status of discuss avatar was always a circle. This is ok for the most used im status "online", "away", "busy" and "offline" where icons are rounded. We have a few exceptions like: - odoobot's heart - user on leave with plane icon - user in office / homeworking with bulding / house icon This commit fixes the mask to take the shape of icon into account, so this looks like whatever the icon of im status. <img width="1808" height="1136" alt="discuss-chats-before-after" src="https://github.com/user-attachments/assets/c2a8372f-bc4d-4d08-91d4-c5ceb97e49b6" /> Forward-Port-Of: odoo/odoo#288972
Fixes an issue where hovering over a channel in the messaging menu could make it impossible to click. Users can now reliably open channels and use the messaging menu without hidden interface elements blocking their actions.
Original PR description
Before this commit, opening the messaging menu from the systray and moving the pointer over a channel could make the channel impossible to click. The invisible anchor used to position the right-click actions was rendered inside the outer dropdown, so Dropdown treated it as a submenu and added the dropdown-item class. Its full width combined with fixed positioning made it cover the UI and intercept pointer events. After this commit, the manual context menu anchor opts out of optional Dropdown styling. It can still position the right-click actions without covering channel items, and the systray test ensures that the anchor is not styled as a dropdown item. |Before|After| |-|-| |<img width="818" height="691" alt="image" src="https://github.com/user-attachments/assets/edcad7ed-fe02-499d-bf9c-112cba470100" />| <img width="773" height="663" alt="image" src="https://github.com/user-attachments/assets/ca89c8a0-034d-4807-bbc2-d4d36a171797" />| Forward-Port-Of: odoo/odoo#289476
Discuss conversations now show the correspondent's own avatar consistently across the sidebar, header, messages, and member list. This avoids confusing cases where the same person appeared with different generated avatars when they had not uploaded a photo.
Original PR description
A conversation with a correspondent showed that person with two different avatars: one in the Discuss sidebar and header, another on their messages and in the member list. The sidebar and the header read the avatar of the channel, while messages and the member list read the avatar of the correspondent. When that person had no uploaded photo, both records generated their own, and the two do not match. This commit fixes the issue by generating an avatar only for a channel and a group, and returning False for every other conversation kind, so the correspondent's own avatar is used everywhere. Related Enterprise PR: https://github.com/odoo/enterprise/pull/131716 Task-[6559693](https://www.odoo.com/odoo/project/1519/tasks/6559693) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#288520
Avatar cards in the mail interface now use the same border styling as the popover that contains them. This fixes a small visual inconsistency, making the user interface look more polished and consistent.
Original PR description
This commit make the card follow the same border property than the popover that contains it. Forward-Port-Of: odoo/odoo#289526
The calendar popover is now easier to use on mobile devices, with a bottom-sheet style design and proper scrolling when content is long. This prevents information from overlapping and helps users view calendar details more comfortably on small screens.
Original PR description
This commit improves the usability of the calendar popover on mobile by adjusting its design to match the bottom sheet. Prior to this commit, when the popover content exceeded its maximum height, it…
This commit improves the usability of the calendar popover on mobile by adjusting its design to match the bottom sheet. Prior to this commit, when the popover content exceeded its maximum height, it was not scrollable, causing the content to overlap. This commit also updates the popover to fix this issue. task-6578705 Requires: - https://github.com/odoo/enterprise/pull/132185 | Before | After | |--------|--------| | <img width="1920" height="925" alt="Screenshot 2026-09-18 at 15 22 27" src="https://github.com/user-attachments/assets/26f83b38-09f1-49b8-b1f5-49ba3a1502f1" /> | <img width="1914" height="925" alt="Screenshot 2026-09-18 at 16 07 26" src="https://github.com/user-attachments/assets/1dc784ab-3224-43da-ba4f-438d482d3c6b" /> | | <img width="430" height="699" alt="Screenshot 2026-09-18 at 17 52 42" src="https://github.com/user-attachments/assets/4ba909f1-dc0c-477a-bc25-3cb699f9b6cd" /> | <img width="441" height="712" alt="Screenshot 2026-09-18 at 17 51 43" src="https://github.com/user-attachments/assets/6c560e21-242d-45a5-8731-a6a9654c775a" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#289220
The Gantt popover now behaves better on mobile screens by matching the bottom-sheet layout and allowing oversized content to scroll. This prevents information from overlapping or being hidden, making Gantt details easier to view on phones and small devices.
Original PR description
This commit improves the usability of the gantt popover on mobile by adjusting its design to match the bottom sheet. Prior to this commit, when the popover content exceeded its maximum height, it was…
This commit improves the usability of the gantt popover on mobile by adjusting its design to match the bottom sheet. Prior to this commit, when the popover content exceeded its maximum height, it was not scrollable, causing the content to overlap. This commit also updates the popover to fix this issue. task-6578705 Requires: - https://github.com/odoo/odoo/pull/289220 The inner design will be addressed in task-6584243 | Before | After | |--------|--------| | <img width="1915" height="928" alt="Screenshot 2026-09-18 at 15 23 12" src="https://github.com/user-attachments/assets/ca304338-92b9-4898-a43e-a2cf7b26b0f2" /> | <img width="1916" height="928" alt="Screenshot 2026-09-18 at 16 08 23" src="https://github.com/user-attachments/assets/f806c753-c059-485f-a2ef-0f53fb7b75bc" /> | | <img width="434" height="700" alt="Screenshot 2026-09-18 at 17 52 51" src="https://github.com/user-attachments/assets/709a9f4d-cf55-4889-aca2-2747d771391e" /> | <img width="440" height="703" alt="Screenshot 2026-09-18 at 17 52 02" src="https://github.com/user-attachments/assets/c7024d29-2615-4e52-b4ac-7cf542e40223" /> | Forward-Port-Of: odoo/enterprise#132185
New U.S. companies using AvaTax could create tax records without the required accounting account when Accounting was installed without demo data. This fix ensures AvaTax invoice and refund accounts are assigned during company setup, preventing incomplete tax entries on invoices.
Original PR description
Steps to reproduce: - Create a DB and Install `Accounting` without demo data - In Companies > Create New Company with `US` Localization - Switch to US Company > Add `Avatax` Credentials - Create a…
Steps to reproduce: - Create a DB and Install `Accounting` without demo data - In Companies > Create New Company with `US` Localization - Switch to US Company > Add `Avatax` Credentials - Create a Product with `Avatax Category` - Create a Invoice > In Other Info `Fiscal Position` - `Automatic Tax Mapping (AvaTax)` > `Compute Taxes` - In Taxes check newly created tax does not have a account ID Issue: AvaTax fiscal position created from chart templates have empty `avatax_invoice_account_id` and `avatax_refund_account_id` fields on a fresh database without demo data. Problem: Both fields use [defaults] based on `company.account_sale_tax_id`. During initial CoA loading, `_load_data()` creates the AvaTax fiscal position before `_post_load_data()` sets `company.account_sale_tax_id`. The defaults therefore resolve to an empty recordset and no tax account is assigned. This issue does not occur in databases with demo data because the demo company is already loaded, so `company.account_sale_tax_id` is already set when the AvaTax fiscal position is created. Solution: Set the invoice and refund accounts explicitly in the AvaTax fiscal position template to ensure they are correctly assigned during CoA loading. [defaults]: https://github.com/odoo/enterprise/blob/de17c107651394025e9a3d5cbed8d81bcfc2e76d/account_avatax/models/account_fiscal_position.py#L9-L13 opw-6347128 Forward-Port-Of: odoo/enterprise#132315 Forward-Port-Of: odoo/enterprise#126604
WhatsApp conversations in Discuss now show the same contact avatar across the sidebar, header, messages, and member list. This avoids confusion when a contact has no uploaded photo and ensures users see a consistent identity throughout the conversation.
Original PR description
A conversation with a correspondent showed that person with two different avatars: one in the Discuss sidebar and header, another on their messages and in the member list. The sidebar and the header read the avatar of the channel, while messages and the member list read the avatar of the correspondent. When that person had no uploaded photo, both records generated their own, and the two do not match. This commit fixes the issue by generating an avatar only for a channel and a group, and returning False for every other conversation kind, so the correspondent's own avatar is used everywhere. Related Community PR: https://github.com/odoo/odoo/pull/288520 Task-[6559693](https://www.odoo.com/odoo/project/1519/tasks/6559693) Forward-Port-Of: odoo/enterprise#131716
This fix ensures shifts without a set date are not automatically scheduled before the selected planning day or before the current time. It prevents planning errors caused by timezone handling, helping teams rely on auto-planning to place work on the intended date.
Original PR description
Prior to this commit, it was possible to schedule dateless shifts (i.e, "Shifts to Schedule") in the past. This was occuring because of the dates passed as input to the auto-plan algorithm, which are in local timezone. However, the auto-planned treated them as server-local timezone (i.e., UTC). We therefore fix (and reduce by the same occasion) the timezone conversions between user-local and server-local. Further, an open shift / dateless shift should not be scheduled before 'now'. ## Steps to reproduce: - Create a shift without date - View one day in the Gantt (e.g., September 18th) - Auto-plan ## Current behaviour: - The shift is scheduled on September 17th ## Expected behaviour: - It should be scheduled on September 18th task-6573957 Forward-Port-Of: odoo/enterprise#132141
Sales quotation templates now preserve section descriptions correctly when sections have no product, preventing blank lines from appearing in new quotations. The update also avoids saving unsupported combo lines into quotation templates, making templates more reliable for sales teams.
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#289534
Fixed a display issue where the row actions menu icon could appear with extra ellipsis text on combo product lines. This keeps sales order lines visually clean and makes the actions menu easier to recognize.
Original PR description
Steps to reproduce: - Open a sale order and add a combo product line. - Look at the row-actions column (rightmost, the "⋮" dropdown) for that line. Before the fix: - The `.o_list_section_options` cell only got its width/text-overflow override when the row also carried `.o_is_line_section` or `.o_is_line_subsection`. Any other row reusing the same cell fell back to the generic web list rule `text-overflow: ellipsis`, so the oversized "more_vert" icon glyph got clipped and rendered as "⋮ ..." instead of a clean "⋮". After the fix: - Moved the width/text-overflow override up to apply to every row inside `.o_section_and_note_list_view`, since this cell only ever holds an icon and should never truncate regardless of row type. Combo rows now render correctly with no extra sale-side changes needed. opw-6580665 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#289462
Tooltips now have corner rounding that matches the rest of Odoo's interface styling. This fixes a small visual inconsistency so pop-up help elements look more polished and aligned across editions.
Original PR description
We need an override of Bootstrap's default tooltip border radius because the default value assumes that the users of Bootstrap haven't also overridden the default popover border radius. Since we…
We need an override of Bootstrap's default tooltip border radius because the default value assumes that the users of Bootstrap haven't also overridden the default popover border radius. Since we have, we must also override our tooltip border radius and compute it according to our popover's styling. It follows the usual formula for computing border radii: Inner radius = Outer radius - Padding COM Before <img width="438" height="372" alt="Screenshot 2026-09-18 at 2 40 26 PM" src="https://github.com/user-attachments/assets/5faa8bd3-8048-4f4f-bb69-1082c4f7a40e" /> COM After <img width="540" height="438" alt="Screenshot 2026-09-18 at 2 39 20 PM" src="https://github.com/user-attachments/assets/58fed7bd-2fac-4a0b-8a8f-10824cce6ff6" /> ENT Before <img width="444" height="348" alt="Screenshot 2026-09-18 at 2 45 29 PM" src="https://github.com/user-attachments/assets/4d04a647-6667-474a-8a35-6c2845c362b8" /> ENT After <img width="762" height="492" alt="Screenshot 2026-09-18 at 2 46 38 PM" src="https://github.com/user-attachments/assets/bb4dade6-c497-406a-9f08-110de90d7eeb" /> Forward-Port-Of: odoo/odoo#289320
The attendance kiosk now shows the weekday in the selected company or interface language instead of always using English. This creates a more consistent localized experience for employees using kiosk mode in non-English environments.
Original PR description
Problem:
The weekday displayed in the attendance kiosk header is always shown in English, even when the comapany contact's language is changed.
This happens because `DateTime.toFormat("cccc")` uses Luxon's locale, but the `DateTime` instance is created without setting the current UI locale.
Steps to reproduce:
1. Install `hr_attendance`.
2. Change the company contact language to a language other than English (e.g. French).
3. Open the Kiosk Mode.
4. Observe that the date and UI are translated, but the weekday remains in English (e.g. "Monday" instead of "Lundi").
Fix:
Set the Luxon locale from the document language before formatting the weekday. This ensures `toFormat("cccc")` returns the weekday in the active Company contact language.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#289464
Forward-Port-Of: odoo/odoo#274655This fix prevents Chilean demo accounting setup from trying to post demo entries linked to non-Chilean partners. It helps companies and implementers load Chilean localization demo data alongside other localizations without setup failures or missing accounting examples.
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. Forward-Port-Of: odoo/odoo#288590
Payslip work entries now subtract unpaid break time from recorded attendance. This prevents employees from being paid for break hours that should not count as worked time, improving payroll accuracy.
Original PR description
Steps to Reproduce: 1. Create an attendance from 8am to 4pm (8 hours) 2. Add 2h of Break Duration -> This reduces the worked time from 8h down to 6h. 3. Generate a payslip for this employee -> 8h of attendance is included, but it should be 6H instead Fix: Exclude `attendance.break_duration` -if there is one set- from attendance work entries' total value. task-6573873 Forward-Port-Of: odoo/odoo#289266
Public spreadsheets no longer show chart links that send viewers to internal Odoo screens they cannot access. This avoids confusing public users with actions that fail and keeps shared spreadsheets focused on usable content.
Original PR description
Task: 6449019 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#281414
The emoji picker search field now shows its focus outline around the full search pill, including the magnifying glass icon. This makes the focused control look consistent and easier to understand when composing messages.
Original PR description
### Impacted versions 20.0, community. Enterprise sets `$input-focus-box-shadow: 0` (`web_enterprise/static/src/scss/bootstrap_overridden.scss`), so it draws no input ring at all and the misplacement…
### Impacted versions
20.0, community. Enterprise sets `$input-focus-box-shadow: 0` (`web_enterprise/static/src/scss/bootstrap_overridden.scss`), so it draws no input ring at all and the misplacement is invisible there.
### Steps to reproduce
1. Open a record with a chatter, e.g. a sales order.
2. Click **Send message**, then the emoji button.
3. The search is autofocused.
### Current behavior
The focus ring is drawn around the input rather than around the search control, so it starts after the magnifier and leaves it outside the ring.
The search is a bordered pill holding a magnifier and a deliberately borderless input:
```html
<span class="o-EmojiPicker-searchContour ... rounded-pill border bg-view">
<i class="oi ..." data-icon="search"/>
<input class="form-control border-0 flex-grow-1 rounded-pill ..."/>
</span>
```
`form-control` is on the input, so bootstrap rings the input. Measured at 1600x1000:
| | box-shadow | inset inside the pill |
|---|---|---|
| input | `0 0 0 2px, 0 0 0 4px` | left **22px**, right 1px, top 1px, bottom 1px |
| pill | `none` | |
The 22px on the left is the magnifier. The ring therefore cuts across the middle of the pill, and on the other three sides a 4px ring over a 1px inset spills past the border.
555aa438ca64 ("[IMP] mail, web: improve emoji picker UX") moved the magnifier to the left and made the pill `rounded-pill`, which is what makes this plain to see. It was already misplaced before, with the magnifier then on the right.
### Expected behavior
The ring is drawn around the whole search control, magnifier included.
### Before
<img width="1824" height="282" alt="emoji_before" src="https://github.com/user-attachments/assets/1db54ff9-e39f-46c0-8f65-ce7f5a89856f" />
### After
<img width="1824" height="282" alt="emoji_after" src="https://github.com/user-attachments/assets/92af463c-1e24-4ee5-91e5-d140e52fd593" />
<!-- drag emoji_before.png and emoji_after.png here -->
### About the fix
The ring moves onto the pill, on `:has(input:focus)`, which is what the neighbouring rule for the magnifier colour already uses in that file.
The two declarations are the pair bootstrap applies in `.form-control:focus` (`forms/_form-control.scss`), so nothing is invented and each flavour keeps deciding through its own variables. Enterprise, with `$input-focus-box-shadow: 0`, shows no ring here just as it shows none for any other input.
For reference this is how the control panel search is assembled, in `addons/web/static/src/search/search_bar/search_bar.xml`: the wrapper carries `form-control` and the input inside it is left plain, so the ring lands on the whole control. Moving `form-control` onto the pill would match that more literally, at the cost of a markup change and of bootstrap's padding and sizing landing on the pill, so the ring is relocated in css instead.
Forward-Port-Of: odoo/odoo#289438This fixes an issue where product pages could show an error if the quantity selector was disabled in the website editor. Customers can now view and use affected product pages normally, even when quantity selection is hidden.
Original PR description
When the quantity option is disabled from the website editor, the quantity input is removed from the product page. However, `_updateMinimumQuantity` was still trying to update the input, causing a JavaScript error in product page. Handle the missing quantity input before updating its dataset. Enterprise PR:https://github.com/odoo/enterprise/pull/132137 Forward-Port-Of: odoo/odoo#288452
Notebook tabs now display with the intended rounded corners from the Frost design. This fixes a visual issue where tabs appeared too square, improving consistency and polish in the user interface.
Original PR description
Previous implementation of roundness on notebook was not working well, resulting in a squarish notebook, which is not in line with new Frost design. The tabs were squared by setting `--nav-tabs-border-radius` to 0 on the tab itself, but that is the same variable the first and last tabs read to get their radius back. So they were reading 0 too. We now square the tabs with the border-radius properties directly. task-6585237 | Before | After | |--------|--------| | <img width="475" height="135" alt="Screenshot 2026-09-21 at 10 19 10" src="https://github.com/user-attachments/assets/718da69e-4c30-404a-bdf1-bdab91621542" /> | <img width="524" height="130" alt="Screenshot 2026-09-21 at 10 18 32" src="https://github.com/user-attachments/assets/ac49cdfc-5fa6-4e4c-a8fb-a0f61415b480" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#289258
Point of Sale users can now remove the preselected customer filter when viewing quotations or orders. This lets them see all available records instead of being unintentionally limited to the customer selected earlier.
Original PR description
When a customer was selected before opening the quotations/orders view, a default partner filter was applied. However, the partner was also added directly to the domain. Therefore, removing the partner filter from the search bar had no effect, as the domain continued to restrict the records to that partner. We now only use the default search filter so that users can remove it and display all available quotations/orders. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6537521 Forward-Port-Of: odoo/odoo#287689
Publicly shared spreadsheets no longer expose internal Odoo-only menu actions or side panels that could confuse users or cause crashes. This keeps the public spreadsheet experience stable while preserving supported public features such as geo charts.
Original PR description
Task: 6449019 Forward-Port-Of: odoo/enterprise#127354
This fix prevents rental product pages from showing an error when the quantity selector has been disabled in the website editor. Customers can continue viewing and interacting with rental products normally, even when quantity selection is not displayed.
Original PR description
When the quantity option is disabled from the website editor, the quantity input is removed from the product page. However, `_updateMinimumQuantity` and `_toggleDisable` were still trying to access the input, causing a JavaScript error in the product page. Handle the missing quantity input before accessing its value or dataset. Community PR:https://github.com/odoo/odoo/pull/288452 Forward-Port-Of: odoo/enterprise#132137
This fixes how leave durations are entered when creating multiple leave records from the Gantt view. Users can now set a single duration that applies to each selected day, reducing confusion while keeping range-based entry available in the full leave form.
Original PR description
We only want to let the user encore durations in this context of multi select in the gantt. If a range is needed it's still possible in the real form view of a leave. But in a gantt it will just apply this duration for each days. task-6581959 Forward-Port-Of: odoo/enterprise#132174
Helpdesk teams can now link multiple community forums without causing errors when customers use the “Ask the Community” option. This keeps the self-service support experience available and avoids broken forum pages for teams that use forums or course-related discussions.
Original PR description
### Steps to Reproduce: 1) Install `website_helpdesk_slides_forum` module 2) On a Helpdesk team, link 2 (or more) forums under `Commnity Forums`. 3) Click on website smart button and then click `Ask…
### Steps to Reproduce: 1) Install `website_helpdesk_slides_forum` module 2) On a Helpdesk team, link 2 (or more) forums under `Commnity Forums`. 3) Click on website smart button and then click `Ask the community` button. ### Error: ``` odoo.addons.base.models.ir_qweb.QWebException: Error while render the template KeyError: '_forums' Template: website_helpdesk_slides_forum.helpdesk_forums ``` ### Root Cause: https://github.com/odoo/enterprise/blob/1bdd673c5fd19e335dc0948d2beed7a282e5e172/website_helpdesk_forum/controllers/website_forum.py#L18-L22 On clicking the "Ask the Community" button calls the `helpdesk_forums` controller. A single forum redirects straight to it. Several forums get rendered through `get_template_xml_id()`, with only `forums` in context. `get_template_xml_id()` is overridden in `WebsiteSlidesForumHelpdesk`, which points to : https://github.com/odoo/enterprise/blob/1bdd673c5fd19e335dc0948d2beed7a282e5e172/website_helpdesk_slides_forum/views/helpdesk_templates.xml#L3-L5 a primary copy of the inner partial `forum_all_all_entries`. That partial needs `_forums` (and, once extended by website_slides_forum, courses_discussions too), both only ever set by the page template's own t-call: [Reference](https://github.com/odoo/odoo/blob/23af2b443735c6d3a2f64e44f9ea5da45638b052/addons/website_forum/views/forum_forum_templates_forum_all.xml#L18-L19) Since `helpdesk_forums` is rendered directly instead of going through `website_forum.forum_all`, `_forums` is never set, hence `KeyError` occurs. The base `website_helpdesk_forum` module has the same root cause one level up, surfacing as a different error: https://github.com/odoo/enterprise/blob/1bdd673c5fd19e335dc0948d2beed7a282e5e172/website_helpdesk_forum/controllers/website_forum.py#L24-L25 `website_helpdesk_forum.forum_all` does not exist anywhere in the codebase. A team with multiple forums, without `website_helpdesk_slides_forum` installed, hits ``` ValueError: View 'website_helpdesk_forum.forum_all' in website 1 not found ``` Instead of a listing page. ### Fix: - Both `get_template_xml_id()` implementations now return the real, working `website_forum.forum_all` page template, which already sets `_forums/courses_discussions` through its own `t-call` and wraps the result in website.layout. - `helpdesk_forums()`'s render values are now built through an overridable `_get_helpdesk_forums_render_values()` hook instead of a hardcoded dict, so subclasses can extend the context. - `website_helpdesk_slides_forum` uses that hook to set `hide_forum_slides_link=True`, and adds one small non-primary view inheriting `website_slides_forum.forum_all_all_entries` that conditions the `/slides` promo link (not the "Course" badge, which doesn't navigate anywhere) on `not` `hide_forum_slides_link`. This targets the link element itself rather than a `t-call` site in `forum_all`, so it correctly applies whether `website_slides_forum` groups a given forum as "regular" or "course-linked". **opw-6332175** Forward-Port-Of: odoo/enterprise#131734 Forward-Port-Of: odoo/enterprise#124104
A test in the AI module was corrected so it checks a generic preview link using a neutral contact record. This prevents false failures caused by behavior from another AI agent component and helps keep automated validation stable.
Original PR description
The accepted-update preview test used an AI agent and expected the self-update message provided by the ai_agentic override. This made the base AI test depend on behavior from another module. Use a contact as the updated record and assert the generic preview link. This keeps the test scoped to the behavior provided by the AI module. Fixes Runbot error 947270 Forward-Port-Of: odoo/enterprise#132321
A website shop test was made reliable by ensuring a specific sample product always appears on the first shop page. This prevents failures when demo data changes product ordering, helping keep automated checks stable.
Original PR description
The website tour expects to find 'Floating Snippets Product B' on the first shop page. However, when demo data is installed, the product is moved to the second page, causing the tour step to fail. Set the product's website_sequence to 1 so that it always appears on the first shop page, regardless of whether demo data is installed. runbot-945783 Forward-Port-Of: odoo/odoo#289471
Barcode receipt screens no longer automatically focus the search bar, preventing product scans from being mistaken for transfer searches. This ensures scanned items are processed by the barcode workflow as intended, while users can still click into search when they need it.
Original PR description
Since odoo/odoo#284146, the search bar could regain focus after the barcode kanban controller blurred it during mounting. As scanners act as keyboards, scanning a product entered its barcode in the search bar and filtered transfers instead of triggering the barcode handler. Disable search bar autofocus through the barcode controller's environment instead of blurring the active element after mounting. Users can still focus the search bar manually when needed. Steps to reproduce: 1. Open the Barcode receipts kanban. 2. Scan a product barcode while the search bar is focused. 3. Observe that the barcode filters transfers as search input. Before this commit: Product barcodes could be captured by the automatically focused search bar and interpreted as a transfer search. After this commit: The search bar is not focused automatically, allowing product scans to be handled by the barcode service. Forward-Port-Of: odoo/enterprise#132217
Accounting predictions now use the most recent past entries instead of older records. This helps improve the relevance of automated suggestions when processing accounting documents, reducing the risk of outdated data influencing predictions.
Original PR description
This commit: https://github.com/odoo/enterprise/pull/38830/changes#diff-6f6931855e0903ff0d3f2b39bd5703ceaef9bdf9a516862b83f38d2d5b21a232 change the order of the predictive queries, removing the sorting order by date. Based on the current docstring: https://github.com/odoo/enterprise/blob/66682012145e5116ebec0183102bc5e930c2c343/account_accountant/models/account_move.py#L676 this is not correct, as we expect to retrieve the previous 100 entries, rather than the oldest ones. Correcting the query order ensures that the most recent entries are considered for predictive purposes. opw-6558929 Forward-Port-Of: odoo/enterprise#132254 Forward-Port-Of: odoo/enterprise#131731
A search option was added to the account selection wizard so users can find accounts by code, name, or description. This makes selecting the right account faster and reduces the chance of choosing the wrong record.
Original PR description
In this commit, we will add a new search view to the account.select.account.line wizard, to be able to look up record with code, name or description no task id Forward-Port-Of: odoo/enterprise#132335
Fixes an issue where users could not see the update or remove options for the currently installed website theme. This restores expected theme management actions and prevents users from being sent only to the preview flow.
Original PR description
Steps to reproduce: - Install a theme on the current website - Open the themes kanban ('Switch theme' in the builder, or Website > Configuration > Themes) - Hover the card of the theme that is…
Steps to reproduce:
- Install a theme on the current website
- Open the themes kanban ('Switch theme' in the builder, or Website > Configuration > Themes)
- Hover the card of the theme that is installed
- 'Update theme' and 'Remove theme' never show up, the card only opens the live preview
The kanban gates that overlay on `is_installed_on_current_website`, which computes `module == self.env.website.theme_id`. Since [1], `env.website` browses `context['website_id']` and has no fallback.
For every route that is not `website=True`, hence for the `/web/dataset/call_kw` through which the kanban reads its records, `ir.http._match` moves `website_id` into `host_id` and deletes it from the context. `env.website` is therefore always empty there, the field is always `False`, and the template falls back to the preview button.
`button_remove_theme` and `button_refresh_theme` resolve that same empty website. The former hands it to `_theme_remove`, which resets the default config on the generic `website_id=False` scope before returning on its `if not website.theme_id` guard; the latter upgrades an empty recordset and silently does nothing.
Fix by falling back to `host_id`, which `_match` sets to the website the user selected, as `_button_immediate_function` and `button_choose_theme` already do.
[1]: https://github.com/odoo/odoo/commit/9d97e0e919a953e4f86e42e32ca24d9790840f68This fixes a small-screen display issue where long status bar button labels could push the dropdown caret onto a separate line. The button label now wraps while the caret remains attached and aligned, making mobile and narrow layouts clearer and easier to use.
Original PR description
On small screens the status bar gathers its buttons into a split button, the first one in front and a caret opening the rest. The row they sit in wraps, so a first button long enough to fill the width sends the caret onto a line of its own, splitting the group it was meant to close. Leave the wrapping to the wide row, which has every button to place at once, and take it from the small one, where a group of two is all there is: the label wraps inside its button instead, which the group already lets it do. A caret keeping its own height then falls short of a button grown to two lines, so stretch it to the group. The group measures itself by what it holds rather than by the status bar, which a taller field beside it would otherwise lend it. task-6564150 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#289433
The manufacturing order Kanban progress bar now shows draft orders with a clearer color. This makes it easier for users to spot draft manufacturing orders at a glance and avoids confusion caused by segments blending into the background.
Original PR description
Issue before this commit: ========================= The draft progress segment in the manufacturing order Kanban view is barely visible against the background. <img width="442" height="145"…
Issue before this commit: ========================= The draft progress segment in the manufacturing order Kanban view is barely visible against the background. <img width="442" height="145" alt="image" src="https://github.com/user-attachments/assets/9ba3e4ef-7b91-4c82-86ee-1fe0e47f472f" /> Steps to reproduce: =================== - Install MRP. - Create a draft manufacturing order. - Open the manufacturing orders in the Kanban view. - Observe the progress bar and notice that the segment representing the draft state is barely visible Cause of the issue: =================== In this [commit](https://github.com/odoo/odoo/pull/251475/changes#diff-3bad372563263ef117de6ed9e222008e2a27b2ea212df89f72f269066a8eacacR603) the manufacturing order Kanban progress bar was changed to represent order states. Draft orders were assigned the `light` color, which blends into the Kanban background and makes their segment barely visible. After this commit: ================== The progress segment for the draft state is clearly visible, allowing users to easily distinguish draft orders in the Kanban view. <img width="343" height="123" alt="image" src="https://github.com/user-attachments/assets/6646143f-a299-4544-b8b5-115e13ebf8c5" /> Forward-Port-Of: odoo/odoo#288925 Forward-Port-Of: odoo/odoo#288462
Online payment status updates and draft resets now follow the same broader payment method rules used when starting payments. This helps avoid valid payments being blocked or handled inconsistently after initiation.
Original PR description
Post 56e73e8d8d674e272b809ef7628b0705cbd76900, we no longer restrict payment initiation to sepa_ct payments only. This commit ensures consistency with this behavior for the payment_status_updated webhook and when resetting payments to draft. No task ID Forward-Port-Of: odoo/enterprise#132114
This fixes how seized salary amounts are categorized in Belgian payroll by restoring their link to the remuneration base. It helps ensure deductions are calculated and validated correctly on payslips.
Original PR description
The SEIZED_AMOUNT category should have the REMUNERATION_BASE as parent. This was unintentionally removed here https://github.com/odoo/enterprise/pull/119727 Forward-Port-Of: odoo/enterprise#132162
Manufacturing users can now start a work order even when its workstation is marked as blocked. This removes an unnecessary dependency on another user to unblock the workstation when the operator knows it is available, helping production proceed with fewer delays.
Original PR description
Before if a user wanted to start a work order and the workstation was blocked the user had to ask someone with permission to unblock the work center to do so. The constraint is removed and we now assume that if the user wants to start a work order they know that the work center is available. task number: 6516333 Forward-Port-Of: odoo/odoo#285680
This update removes an invalid setup reference in the Danish localization module that could cause errors during Nemhandel registration. It helps keep the registration flow reliable without changing business functionality.
Original PR description
Method `_inverse_phone_number` is missing. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#288637
Website administrators can now enable Product Reference Price and have the setting remain active after saving and reloading, even when Point of Sale is not installed. This prevents confusion and ensures the eCommerce pricing display option behaves as expected.
Original PR description
Toggling "Product Reference Price" in Website Settings never sticks when point_of_sale isn't installed the checkbox appears checked after Save, but reloading the page always shows it unchecked again,…
Toggling "Product Reference Price" in Website Settings never sticks when point_of_sale isn't installed the checkbox appears checked after Save, but reloading the page always shows it unchecked again, with no error. Reproduce (no point_of_sale installed): 1. Install/keep website_sale without point_of_sale. 2. Go to Website > Configuration > Settings > eCommerce. 3. Check "Product Reference Price" and click Save. 4. Reload the settings page: the box is unchecked again. Root cause: `website_show_reference_price` (the checkbox) is linked to the global `group_show_uom_price` setting via two onchange methods, and `set_values()` force-disables the website-specific value for every website whenever `group_show_uom_price` is falsy Fix: keep `group_show_uom_price` in website_sale's own Settings view so its value always round-trips with the rest of the form, independent of whether point_of_sale is installed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#288560
Quotation and sales order PDFs now use the same column headers as the online portal preview. This removes confusing differences between what customers see online and what is printed or sent as a PDF, especially when line numbers are enabled.
Original PR description
Steps: - Settings > Sales > Enable the 'Line Numbers' setting - Sales > Quotations > Create a quotation with a few product lines - Open the Preview and compare it with Print > Quotation / Order…
Steps: - Settings > Sales > Enable the 'Line Numbers' setting - Sales > Quotations > Create a quotation with a few product lines - Open the Preview and compare it with Print > Quotation / Order Issue: - The same quotation shows different column headers depending on where it is viewed. On the portal preview the product and quantity columns have no header at all, while the PDF labels them 'Description' and 'Quantity'. The reverse happens on the line number column, which is labelled '#' on the preview but has a blank header on the PDF. Cause: - The sale order portal revamp replaced the visible 'Description' and 'Quantity' header text with aria-label attributes, but only in the portal template. The report template kept its labels. Likewise, the '#' header added for line numbering was only added to the portal template and never to the report. Fix: - Remove the visible 'Description' and 'Quantity' headers from the report template, keeping them as aria-label like on the portal, and add the missing '#' header, so the PDF renders the same column headers as the preview Forward-Port-Of: odoo/odoo#288486
Checkout now preserves the delivery date selected by the customer instead of replacing it with the earliest available date before payment. This ensures the promised delivery date on the order matches the customer's choice, improving reliability and reducing fulfillment confusion.
Original PR description
Steps to reproduce: =================== 1. Enable Estimated Delivery on a delivery method, lead 1 day, range 90. 2. On the website, add a product to the cart and go to checkout. 3. Pick a date far in…
Steps to reproduce: =================== 1. Enable Estimated Delivery on a delivery method, lead 1 day, range 90. 2. On the website, add a product to the cart and go to checkout. 3. Pick a date far in the range, then confirm the order. => Promised Delivery is the order date + 1 day, not the date picked. Root cause: =========== `_set_delivery_method` always writes the earliest offered date on `commitment_date`, and `_recompute_cart` calls it again on the way to payment, so the choice is overwritten just before the order is placed. - [1] added the date selector with that unconditional write. Fix: ==== Only fall back to the earliest date when there is none yet, or when the one set is no longer offered, as the checkout already requires. [1]: https://github.com/odoo/odoo/commit/7e51e356728d24ca0aeb14c5ff94a0eac66e188f opw-6538537 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#288271 Forward-Port-Of: odoo/odoo#287236
This fixes an automated stock workflow test that could fail when the Turkish Nilvera e-dispatch add-on was installed. The change makes the test recognize the customized stock list view, improving reliability without changing user-facing stock 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#288404 Forward-Port-Of: odoo/odoo#288255
Product option pills in the sales configurator now keep consistent spacing when they wrap onto multiple lines. This makes longer option lists easier to read and avoids a cramped layout for users configuring products.
Original PR description
Pill-style attribute values used Bootstrap's list-inline/list-inline-item, which only sets margin-right between items. When pills wrapped onto a new line, the rows touched with no vertical gap. Fix: Switch the pill list to a flex container with gap-2, matching the spacing website_sale already uses for its own attribute-value lists, so wrapping rows get the same gap as pills on the same row. opw-6584507 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#289176
Users can now start or validate manufacturing work orders even when the related workstation is marked as blocked. This reduces delays by removing the need to ask another user with unblock permissions when the operator knows the workstation is available.
Original PR description
Before if a user wanted to start a work order and the workstation was blocked the user had to ask someone with permission to unblock the work center to do so. The constraint is removed and we now assume that if the user wants to start a work order they know that the work center is available. task number: `6516333` Forward-Port-Of: odoo/enterprise#129869
The Ecuadorian ATS tax export now consolidates transactions from a company and its branches that share the same RUC. This ensures exported tax filings match the consolidated tax return totals and no branch invoices are omitted.
Original PR description
In Ecuador, a company and its branches file under a single RUC, so the ATS is expected to consolidate all of them. However, currently the system exports only the active company report. Steps to…
In Ecuador, a company and its branches file under a single RUC, so the ATS is expected to consolidate all of them. However, currently the system exports only the active company report. Steps to reproduce: - Install the Ecuadorian localization - Create a parent company and a branch, assign the RUC of the parent to the branch, and set the legal name of the branch in Settings - Post a customer invoice with taxes in the parent (e.g. 750) and another one in the branch (e.g. 250) - Activate both companies in the company selector - Go to Accounting > Reporting > Tax return - Select "Report: 104 (EC)", the dashboard shows the consolidated values - Click on the gear icon next to "Tax Return" and select ATS Issue: The exported XML only contains the documents and the totals of the parent company (750). The branch (250) is omitted. Analysis: Currently the ATS export use self.env.company for all searches, which only retrieve the data of the first company set opw-6469807 Forward-Port-Of: odoo/enterprise#132076 Forward-Port-Of: odoo/enterprise#128430
Fixes an issue where users in debug mode could be taken to an individual picking form instead of returning to the previous Barcode overview after refreshing the page. This keeps navigation consistent and reduces confusion for warehouse users and testers.
Original PR description
Issue ===== When refreshing the page in a opened picking in Barcode and going back, we end up in the picking's form view. It's happen only in debug mode. How to reproduce ================ 1. Enable…
Issue ===== When refreshing the page in a opened picking in Barcode and going back, we end up in the picking's form view. It's happen only in debug mode. How to reproduce ================ 1. Enable debug mode; 2. Open Barcode app and open any picking; 3. Refresh the browser's page (F5 on desktop, swap down on mobile); 4. Click on the "<" button to go back on the previous view => Instead of ending back on the picking's kanban view, it opens the current picking's form view. Cause of the issue ================== In the `Main` component, the `_exit` method should handle this case by checking if the last breadcrumb action is a number. In such case, we don't use the breadcrumb and use the navigator's usual `history.back` because otherwise, it will open the picking's form view. That said, this code doesn't work in debug mode because it adds `?debug=assets` at the end of the URL, which means when we check if the last part of the breadcrumb's URL is a number — eg. 3 —, instead of get `3`, we get `3?debug=assets`. Fix === To fix the issue, this commit breaks the last part in two in case a `?` is in it and uses the first part only to check if it's a number or not. Forward-Port-Of: odoo/enterprise#131991
Duplicating a section now keeps the related product even when that field cannot be edited, such as after stock movements exist. This prevents copied lines from losing product information while preserving quantities and descriptions.
Original PR description
**Version: saas-19.4+** **Description of the issue/feature this PR addresses:** Duplicating a section doesn't copy the product when it's readonly. **Current behavior before PR:** Duplicated lines keep qty/description but product is empty. **Desired behavior after PR is merged:** Product is always copied when duplicating a section. Forward-Port-Of: odoo/odoo#288476
Austrian company identifiers are now validated using the business ID format instead of VAT rules. This prevents valid Austrian company registry numbers from being incorrectly rejected and improves data accuracy for company records.
Original PR description
We used to validate the company ID of Austrian company with the vat validation. This commit use the business ID verification. No-task
When the French PDP integration receives an unsupported lifecycle status, Odoo now records the actual status code instead of showing a blank value. This makes troubleshooting easier and helps support teams identify unexpected responses more quickly.
Original PR description
Currently we just log `None` in case we receive a lifecycle with an unsupported (on community side) status. After this commit we log the status code at least. task-None before fix <img width="711" height="120" alt="image" src="https://github.com/user-attachments/assets/1f939cf4-17b7-49cb-8b31-5cc594fdeadd" /> after fix <img width="700" height="116" alt="image" src="https://github.com/user-attachments/assets/1b8b3853-f2da-4426-9c49-1d135d1c7824" /> Forward-Port-Of: odoo/odoo#286429
Fixes an issue where attachments added to time off requests could disappear when supporting documents were not required for that time off type. Employees and managers can now reliably see uploaded leave attachments regardless of whether documentation is mandatory.
Original PR description
Issue: ---------------------------------------- If the option "Require Supporting Document" on the Time Off Type is unticked, then when adding an attachment on a leave it disappears. Steps to reproduce: ---------------------------------------- - Have a Time Off Type with "Require Supporting Document" unticked - Create a leave with this time off type - On the form view add an attachment through the paperclip icon - It disappears Cause: ---------------------------------------- In `_compute_attachment_is_visible()` if `work_entry_type_support_document` is `False` then `attachment_is_visible` too. `attachment_is_visible` then control whether the attachments of a leave are visible. Solution: ---------------------------------------- Remove the condition on `work_entry_type_support_document`, `attachment_is_visible` purpose is to limit the access to attachments for users unliked to the leave. opw-6542429 Forward-Port-Of: odoo/odoo#289148
This update fixes an issue where clicking at the end of text inside a button moved the cursor outside the button. Users editing website or email content can now place the cursor where expected, making button text editing smoother and less frustrating.
Original PR description
Problem: When trying to place the caret at the end of a button's content with the mouse, the caret always moves outside of the button instead of staying inside it. Cause: This happens because of the previous commit https://github.com/odoo-dev/odoo/commit/c8e93dbc806b5ea511cce695afbc9e81e30a1ca9 (which aimed to fix placing the caret after a link when at the end of a paragraph in the editable), which was not fixing the issue properly. Solution: Check if the click happens at the end of a link and the caret will move inside the link then manually place the selection after the link. Steps to reproduce: - Add a button with one character. - Try to put selection after that character. - Selection always jumps after the button. opw-6499237 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#289047 Forward-Port-Of: odoo/odoo#284197
The PayPal Pay Later and P24 logos used in payment screens have been updated to match the required brand guidelines. This helps keep the checkout experience professional and compliant with payment provider requirements.
Original PR description
Commit [1] introduced the PayPal Pay Later logo and modified the P24 logo. These logos did not comply with the guidelines. This commit updates the PayPal and P24 logos to ensure compliance with the correct guidelines. [1]: https://github.com/odoo/odoo/commit/de06504773a4bc7583ee37d1ccd97aadbcfe492c task-6581412 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#289136
Renames confusing Time Off approval options so they match the actual approver roles shown on employee records. This helps users understand who will be notified to approve time off and allocation requests, reducing mistakes and support questions.
Original PR description
## Issue Currently, the different options for the approval of a time off (allocation) request are the following: 1. None needed 2. By Time Off Officer 3. By Employee's Approver 4. By Employee's…
## Issue
Currently, the different options for the approval of a time off (allocation) request are the following:
1. None needed
2. By Time Off Officer
3. By Employee's Approver
4. By Employee's Approver and Time Off Officer
On the Employee's view form, in the Settings tab, the approvers are named:
1. HR Responsible
2. Time Off
The *By Time Off Officer* option does not notify the *Time Off* approver, but the *HR Responsible*, which is not clear for the users. It would be clearer to use a similar naming convention for both the Approvers on the Employee's form and the options for the approval of the time off (allocation) requests.
<img width="1878" height="592" alt="6535827" src="https://github.com/user-attachments/assets/bc7ad9bb-6b53-4553-8fc8-fb305e7c0b28" />
## Steps to reproduce
1. Install *Time Off* (`hr_holidays`)
2. For an Employee E, set an HR Responsible and a (different) Time Off approvers
3. Create a Time Off request for the Employee E
- Ensure that the selected Time Off Type has its approval method set to "By Time Off Officer"
4. **The user notified off the time off request is the HR Responsible, which is unexpected, considering that we expect an approval from the "Time Off Officer".**
## Justification
In the `_get_responsible_for_approval` method, when using the "By Time Off Officer" option (`'hr'`), it is clearly the `hr_responsible_id` (HR Responsible) who is selected as "responsible" for the approval.
https://github.com/odoo/odoo/blob/dbed91769c48768f58b6a66bff0ed6d90394de38/addons/hr_holidays/models/hr_leave.py#L1557-L1559
The exact same logic is applied for the allocation requests [here](https://github.com/odoo/odoo/blob/dbed91769c48768f58b6a66bff0ed6d90394de38/addons/hr_holidays/models/hr_leave_allocation.py#L1070-L1072).
## Targeted version
We are targeting version 19.2, as it is the version from which the `responsible_ids` field (which was clearly specifying who had to be notified for the approval of a time off request) was removed (see https://github.com/odoo/odoo/commit/d37cf89a6ff134988b4a7c001a97973cd95a2ea8).
If deemed interesting, the same modification can be backported to previous versions too.
opw-6535827
Forward-Port-Of: odoo/odoo#288890
Forward-Port-Of: odoo/odoo#287686This fix improves the mobile checkout experience by preventing the cart summary from covering address fields when the Android keyboard is open. Shoppers can now fill in checkout details more easily, reducing friction during purchase completion.
Original PR description
The mobile summary element hides the address form on Android Steps to reproduce: 1. Install eCommerce 2. On android (or using browserstack) and without being logged in, go to the eCommerce 3. Add any…
The mobile summary element hides the address form on Android Steps to reproduce: 1. Install eCommerce 2. On android (or using browserstack) and without being logged in, go to the eCommerce 3. Add any product to the cart and go to checkout 4. Click on "Checkout" to enter the address details 5. Open the keyboard by clicking inside the first input 6. The virtual keyboard opens, enter a name and click on "Next" in the virtual keyboard 7. Do this a couple of times: the cart summary element doesn't scroll and the input field is hidden behind it Similar problem happens when you scroll a bit after clicking in the first input: the cart summary element displayed at the bottom is still visible (on top of the virtual keyboard) which hides part of the page and makes it difficult to navigate the page and fill in the details Issue: `sticky-bottom` keeps the element at the bottom of the screen Solution: Remove class `sticky-bottom` from `o_mobile_summary` when we click in one of the input opw-6500503 Forward-Port-Of: odoo/odoo#287464
This update fixes a manufacturing test that could fail depending on the timezone of the environment running it. It improves confidence in automated checks without changing business workflows or user-facing manufacturing features.
Original PR description
**PROBLEM**
In `test_generate_serial_button_sequence()` we generate a serial number based on the day of the year. In ir_sequence, we use the time based on the environment timezone, but in the test, we don't use any timezone. This can lead the assertion to fail, since the day of the year can differ with the timezone used.
**REPRO STEPS**
1. edit the freeze_time in the test to `freeze_time('2024-01-15T23:00:00')`
If your timezone is UTC+2, then the time according to your timezone will be `2024-01-16T01:00:00`
So, without in UTC+0, it's the 15th day of the year, but in UTC+2 it's already the 16th.
Remove the timezone in the last assertIn() (ie, remove the fix).
(if your timezone is different, adjust the freeze_time accordingly)
2. run the test and see it fails.
runbot-237780
Forward-Port-Of: odoo/odoo#285647A cart update issue was fixed so rental product date selectors continue working after customers use quick reorder from the cart. This helps prevent stalled checkout flows for rental purchases and keeps the cart experience consistent.
Original PR description
`updateCartSummary` refreshes `o_wsale_shorter_cart_summary` via `replaceWith`, detaching the node and inserting a new one. `reorderProduct` in quick_reorder.js ends up restarting an interaction on the previous node instead of the new one. For rental products, this leaves the daterange picker rendered but inert after a quick reorder from the cart. This commit updates the existing node instead of replacing it, so its identity is preserved. Issue present since PR: https://github.com/odoo/odoo/pull/234965 Forward-Port-Of: odoo/odoo#288559
This change prevents an error when settling restaurant POS orders that were paid through a customer account. It ensures the payment flow can continue normally when returning later to settle the due amount.
Original PR description
Issue: createOrderIfNeeded could be called without data parameter and it would fail when trying to access the parameter. In this case when being called from deleteOrderAndGoToDefaultScreen in pos_settle_due. Steps to reproduce: - Pay an order with the customer account on a pos restaurant config. - Try to settle it later - The settling fails at the payment 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#288589
Regular users could sometimes hit an access error when an AI chat without a custom name was shown in other workflows, such as adding an attachment to Documents. The fix lets the system safely display the AI agent name for users who already have access to the AI chat, avoiding unnecessary interruptions.
Original PR description
AI chat channels can have an empty name, in which case their display name is computed from the linked ai_agent_id. That field is restricted with fields. NO_ACCESS, so flows that read the channel display name, such as adding an AI chat attachment to Documents, could raise an access error for regular users. Compute the AI chat display name through sudo() when reading ai_agent_id, since users who can access the AI chat may safely see the agent name. task-6547727 Forward-Port-Of: odoo/enterprise#130902
An outdated background action was removed from the accounting reports working files. This prevents unwanted behavior when users refresh the page, making the experience more reliable.
Original PR description
Remove old and useless embedded action for the working files. This action is causing some undesired behaviour when refreshing the page.
The rental dashboard now displays empty cart cards with clearer background colors, making zero-value carts easier to read. Dark mode styling was also aligned with the rest of the dashboard for a more consistent user experience.
Original PR description
When a cart in the dashboard has a value of zero, its background is gray, resulting in poor contrast. This commit fixes the issue by updating the CSS. We also add CSS for dark mode to ensure consistency with all the cards in the dashboard. Forward-Port-Of: odoo/enterprise#132104
Financial reports now display and scroll correctly on iPhones and iPads, preventing the scrollbar from being hidden behind report content. This improves usability for mobile users viewing long accounting reports without changing the desktop experience.
Original PR description
### Issue: On iPhone and iPad (reduced window), the scrollbar is hidden behind the report on long scrollable pages This affects all browsers on iOS and iPadOS — Apple forces the use of WebKit (its…
### Issue: On iPhone and iPad (reduced window), the scrollbar is hidden behind the report on long scrollable pages This affects all browsers on iOS and iPadOS — Apple forces the use of WebKit (its rendering engine) on all of them, including Chrome and Firefox ### Steps to reproduce (on iPhone): - Install `l10n_es` (contains scrollable reports by default) - Switch to the ES company - Open the Tax Report and try to scroll Before the fix, the scrollbar renders behind the report content ### Cause: `o_content` was added unconditionally in commit https://github.com/odoo/enterprise/commit/d60ea6e0f3245e394fd0cee5f22f52aff2a79e2e But its role differs between desktop and mobile, and its presence on mobile triggers a WebKit compositor bug On desktop, `o_content` is required: `.o_action` stays `overflow: hidden`, so only `.o_content` (`overflow: auto`) can scroll the report Per the CSS flexbox spec, a flex item won't shrink below its content size unless its `overflow` is not `visible` Without `o_content`, the div keeps `overflow: visible`, refuses to shrink, overflows `.o_action`, and the excess is silently clipped — content becomes unreachable, not just visually different On mobile, the framework flips scroll responsibility to `.o_action` (`overflow: auto`) and forces `.o_content` back to `overflow: initial` `o_content` is therefore not needed on mobile On WebKit (iOS/iPadOS), keeping `o_content` on mobile is harmful: it sits as a non-scrolling `position: relative` node between the real scroll ancestor (`.o_action`) and descendants that require special compositing — the sticky `thead` and the fixed-position mobile chatter This configuration causes WebKit's compositor to miscalculate the Root layer bounding box This geometry mismatch is the most likely explanation for why the native scroll indicator renders behind the report instead of on top of it Removing `o_content` on mobile avoids this node entirely and restores correct compositor geometry ### Notes: Tested on Android (Blink) with and without `o_content`: no visual difference and identical compositor layer geometry confirmed via Chrome DevTools — no regression introduced The `padding-bottom` on `.o_account_report_scroll_container` is unrelated — it is applied unconditionally and exists for a separate bug (last row clipped on scroll) opw-6191827 Forward-Port-Of: odoo/enterprise#132241 Forward-Port-Of: odoo/enterprise#128528
Rental pickup and return time selectors now include the business closing hour as an available option. This prevents customers from missing valid end-of-day or shift-end times when scheduling rentals online.
Original PR description
Add the "Work to" hour to the time options for both pickup and return. E.g.: Monday, from 9h to 12 and from 13h to 17h. This configuration will result in the following time options: 9:00-10:00-11:00-12:00-13:00-14:00-15:00-16:00-17:00. opw-6538617 Forward-Port-Of: odoo/enterprise#130683
Fixes an issue where selecting a highlighted OCR date on a vendor bill did not update an already-filled Bill Date field. Users can now correct extracted bill dates from the document preview without the field losing focus and ignoring their selection.
Original PR description
**Steps to reproduce:** 1. Upload a vendor bill with OCR digitization (pdf in ticket attachments) 2. Make sure the Bill Date field already has a value 3. Click into the Bill Date field so the OCR…
**Steps to reproduce:** 1. Upload a vendor bill with OCR digitization (pdf in ticket attachments) 2. Make sure the Bill Date field already has a value 3. Click into the Bill Date field so the OCR boxes appear on the attachment preview 4. Click on a different date box in the attachment to correct the value **Issue:** The field is not updated with the clicked box's value. Instead, the field simply loses focus and the OCR boxes disappear, as if the user had clicked outside the field. This only happens when the date field already has a value; it works fine when the field is empty. **Cause:** - When a date field has a value, the date widget renders it as a button and only swaps in the real `<input>` once focused [1] - Removing the button triggers `onBlurFieldWidget`, and when the datepicker is focused, it triggers `onFocusFieldWidget` once again: https://github.com/odoo/odoo/blob/89650a5f44b5835028dba57a9ff6fa30515bc5ec/addons/web/static/src/views/fields/datetime/datetime_field.js#L204-L214 - The datetime picker's popover uses `useClickAway`, which reacts to `pointerdown` on `window` to detect clicks outside itself and close the popover. - Clicking a box in the attachment preview is therefore caught by this listener before anything else: it closes the popover, removing the currently focused DOM node and firing a `focusout`. - `ExtractMixinFormRenderer` reacted to that `focusout` by resetting the active field and destroying the box overlay. Since the box's own value-selection ran on `click`, the last event in the `pointerdown → mousedown → mouseup → click` sequence, the reset had already been done, so the click was lost. **Fix:** - Apply the box's selection on `pointerdown` instead of `click`, so it runs synchronously in the same event dispatch that triggers the popover's close logic, guaranteeing it executes before any asynchronous re-render can remove the field's state. - Remove the legacy `pointerdown` listener in `ExtractMixinFormRenderer.`. Because our box now listens to `pointerdown`, it was intercepting the event and breaking selection for images [1] - https://github.com/odoo/odoo/pull/218387 opw-6511803 Forward-Port-Of: odoo/enterprise#131935 Forward-Port-Of: odoo/enterprise#130192
Tax return attachments are now generated only once during the correct step of the return process. This prevents duplicate files from being created, reducing confusion and keeping submitted tax return records cleaner.
Original PR description
We now call _generate_locking_attachments at review and submit so it was generating two times the attachments. The fix is to always call at submit. And for the review stage we only call it when there is no submit step. Forward-Port-Of: odoo/enterprise#132193 Forward-Port-Of: odoo/enterprise#131888
This update adds safeguards so interface actions are only handled when the related screen component is ready. It reduces occasional errors in areas such as Documents, Knowledge, Work Orders, Sign, and Studio promotion dialogs, improving reliability without changing user workflows.
Original PR description
The commit [1] introduced some issues. The dom events could trigger while the component is not mounted yet. To fix this, this commit introduces a new hook `useExternalRef` which sets a signal to a given element when the current component is mounted and removes it when the component will unmount. The mix `useExternalRef` + `useListener` brings back the removed `useExternalListener` behaviour. [1]: https://github.com/odoo-dev/enterprise/commit/aa92285ee2bb0ae4e528c77b3f2a40d7412a8b5d Forward-Port-Of: odoo/enterprise#132049 Forward-Port-Of: odoo/enterprise#130111
This fix prevents certain page interactions from running before their screen components are fully ready. It helps avoid intermittent errors in areas such as API documentation, automation actions, project sharing, search suggestions, emoji selection, resizable panels, and quick record creation.
Original PR description
The commit [1] introduced some issues. The dom events could trigger while the component is not mounted yet. To fix this, this commit introduces a new hook `useExternalRef` which sets a signal to a given element when the current component is mounted and removes it when the component will unmount. The mix `useExternalRef` + `useListener` brings back the removed `useExternalListener` behaviour. [1]: https://github.com/odoo-dev/odoo/commit/918be39e1ad0bd83012cf02840ff412abe9b3548 Forward-Port-Of: odoo/odoo#289046 Forward-Port-Of: odoo/odoo#286159
Point of Sale now reloads its configuration each time it opens, instead of relying on potentially outdated cached data. This ensures cash register balances changed in the backend are accurately reflected for staff at the start of a POS session.
Original PR description
If the cash register balance was updated from the backend, for example by manually adding a reconciliation line, the next time the POS was opened, it could use the cached `pos.config` data and therefore display an outdated cash balance. The POS configuration contains settings and computed values that may change without updating its `write_date`, making it difficult to reliably determine whether the cached data is still up to date. Always force the loading of `pos.config` data when opening the POS to ensure that the latest configuration and cash balance are retrieved from the server. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6574133 Forward-Port-Of: odoo/odoo#288279
This update corrects an issue in the HR Payroll employee view. It helps ensure employee payroll information is displayed or managed more reliably for HR teams.
Sales order product selection now shows only the units of measure and packaging options that belong to the variant currently selected. This prevents customers and sales users from choosing packaging that is not actually available for that product variant.
Original PR description
Issue Before This Commit: ======================== Currently, when a product variant has multiple UoMs, those UoMs appear for all variants when selecting a product in a Sale Order Line, even though…
Issue Before This Commit: ======================== Currently, when a product variant has multiple UoMs, those UoMs appear for all variants when selecting a product in a Sale Order Line, even though they are only available for a specific variant. Steps to Reproduce: ========================= 1: Install the sale and sale_management modules. 2: Enable Units of Measure and Packagings. 3: Create two variants, V1 and V2, and set an Extra Packaging of 'Pack of 6' on V2. 4: Add the product to a Sale Order Line. A product configuration wizard will open. 5: Select V2. The Unit and 'Pack of 6' UoMs are correctly displayed. 6: Select V1. Both UoMs are still displayed, even though 'Pack of 6' is not available for V1. Cause of the issue: ========================= When the variant is changed to V2 in the wizard, _get_basic_product_information is called. At that point, the condition is true, so available_uoms is updated with the UoMs available for V2. However, when the variant is changed back from V2 to V1, the method is called again, but V1 does not have multiple UoMs. Therefore, product_or_template._has_multiple_uoms() returns False, and available_uoms is not updated. As a result, the UoMs from V2 remain in available_uoms and are incorrectly displayed for V1. After This Commit: ======================== Update _get_basic_product_information to ensure that the available UoMs are updated whenever the variant changes. This ensures that only the UoMs available for the selected variant are displayed. Forward-Port-Of: odoo/odoo#289160 Forward-Port-Of: odoo/odoo#288515
Creating an onsite event from the Onsite action now uses the current user's employee record when no employee is provided. This prevents errors and ensures the new event is visible in the expected kanban view.
Original PR description
The Onsite action only sets the hr_skills_event_add_employee key in its context, without any employee. Reading default_employee_id directly then raised a KeyError. Even before that, no attendee was added, so the new event did not match the domain of the action and stayed hidden in the kanban view. We now fall back on the employee of the current user. taskid-6361432 Forward-Port-Of: odoo/odoo#288241
An unused step was removed from maintenance request creation. This cleanup does not change how requests are created, but reduces unnecessary processing and keeps the maintenance code easier to maintain.
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#289007 Forward-Port-Of: odoo/odoo#286132
This fix makes key POS sales products mandatory so users cannot remove settings that the checkout flow depends on. It prevents blank screens and errors when selling products or handling sales order down payments in Point of Sale.
Original PR description
Step to reproduce: - install `pos_sale` - create a pos and go to settings - remove product from `Default Sale Product` - start pos and select a product Observation: - we will get a blank screen and…
Step to reproduce:
- install `pos_sale`
- create a pos and go to settings
- remove product from `Default Sale Product`
- start pos and select a product
Observation:
- we will get a blank screen and error in browser console
```
TypeError: Cannot read properties of undefined (reading 'id')
at get orderDisplayProductName (point_of_sale.assets_prod.min.js:20914:497)
at get orderDisplayProductName (point_of_sale.assets_prod.min.js:27593:14)
```
- similar case when we de-select downpayment product and load a SO
with downpayment
Cause:
- `default_product_id` was introduce in commit[1] which is necessary for
description first order line
- if we remove this field, for pos config, `this.config.default_product_id`
is undefined, and accessing its id raises error
[1] https://github.com/odoo/odoo/commit/0ce605f8db9aa9901bf6b14c4888e5bcc0734401
Fix:
- Made both fields required=True, and removed the now-redundant JS-side
guards that previously enforced this on the client.
- Both fields use a callable `default=` that resolves an xmlid created in
pos_sale_data.xml. During module init, ORM invokes this default to
backfill existing rows *before* data files are loaded, so it resolves to
`None`, leaving rows null and causing the NOT NULL constraint to fail.
- Added `_init_column_default_products` (via `init_storage`) to create
minimal placeholder products and register their xmlids ahead of the
constraint check, so the default resolves correctly on first init.
`pos_sale_data.xml` still loads afterward and updates these same records
- With this in place, the previous `post_init_hook` backfill is no longer
needed and has been removed.
Why not adding a upgrade script
- when creeating the new column, as we have defined a `default` property for both fields, they are populated.
- in case a db is missing the xml id for such products, they are re-created and populated again.
- so there is no chance, we will face any error during upgrade.
opw-6458117
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#282002Debit notes created from credit notes or vendor credit notes now show a clear smart button label. This helps users quickly understand the source document without confusion or missing text.
Original PR description
Issue: - The smart button was displayed without a label when a debit note was created from a credit note or vendor credit note. Fix: - Display 'Credit Note' or 'Refund' as the smart button label based on the source document. Impact: - Smart buttons now display the correct label for each debit note origin. task-6578525 Forward-Port-Of: odoo/odoo#288542
Warehouse batch and wave picking rules now behave more consistently when users select overlapping grouping options. This prevents unnecessary batch creation and cancellation, and ensures automatic batching includes compatible pickings as expected.
Original PR description
Following the merge of batch and wave pickings, there is no longer a clear separation between the 'group_by' settings at the UI level, users can therefore select settings in both modes (e.g. destination and week). This resulted in the creation of a 'batch' picking followed by its cancellation, then a 'wave' one is either selected for merging or created. We have decided to not consider anymore batch pickings when a wave setting is set. Furthermore, if batch creation is set to 'automatic' while compatible pickings exists, the next confirmed picking will include only one of them into the batch, leaving the others as-is. The picking_ids field has also been fixed in the form view. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#288856
The Attendance calendar now visually marks holidays and other unavailable days in grey, matching the experience in the Time Off app. This helps managers and employees interpret attendance schedules more accurately and avoid confusion around non-working days.
Original PR description
The calendar view on Attendance app should look similar to the one on Time Off app, with holidays greyed out. task-6576916 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#289102
This change ensures purchase order notification templates are updated correctly during upgrades. It prevents an error that could occur when editing only the unit price on a confirmed purchase order in migrated databases.
Original PR description
In this commit: eadf127 the `track_po_line_template` template was added in a `noupdate` file. The commit specifies: “put their declaration in no update when not done if template has no technical code or complex dependency on underlying code;” However, this is not actually the case for the two templates in this file. This did not cause any error in v17, but errors started appearing later because of #254602, which modified this code and the related Python code, leading to an error when no product quantity is changed. Steps to reproduce in a 19.3 database migrated from v19: - Create a purchase order with one product line and confirm it. - Only change the unit price of that line. - Error: "Error rendering template: ..." While this can also be considered a migration issue, I think the simpler and more logical solution is to remove the noupdate from this file. opw-6518729 Forward-Port-Of: odoo/odoo#288463
This fixes a minor display issue in Kanban views by preventing placeholder elements from receiving regular card styling. It helps keep the Kanban layout cleaner and avoids unnecessary visual styling during interactions.
Original PR description
This PR excludes `.o_kanban_ghost` elements from a kanban record selector to ensure they don't receive some style that is not necessary. task-6585469 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#289245
This fixes an accounting issue where some batch payments could remain marked as sent even after the related vendor bill and payment were fully paid. The system now refreshes the payment matching status correctly, helping finance teams see accurate batch payment statuses.
Original PR description
A payment on a journal without outstanding account has no journal entry, so it is matched as soon as it is paid. When the bill it pays is reconciled later on, _compute_state turns it to 'paid', but assigning a field from within a compute doesn't notify the fields depending on it: is_matched stays False and any batch payment holding that payment stays in 'sent' state. Mark is_matched for recomputation explicitly, as 18.0 already does since d8de234. Steps to reproduce: - On the Bank journal, leave the outstanding account empty on the outbound payment method line - Post a vendor bill - Register a payment on it - Put that payment in a batch payment and validate the batch - Create a MISC entry and reconcile the bill with it - Issue: bill and payment are 'Paid' but the batch stays 'Sent'. Forward-Port-Of: odoo/odoo#288981 Forward-Port-Of: odoo/odoo#288460
This fix restores Viva.com payments in self-order kiosks after a recent change caused them to fail when certain access information was missing. Businesses using Viva.com for kiosk payments can continue taking orders without payment interruptions.
Original PR description
Since odoo/odoo#284182, Viva.com is not working in the self order kiosk due to the `accessRight` field not being present. There was already a fallback in place for this situation but a missing optional chaining `?` stopped it from working. This commit adds the `?` to fix the error. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#289145
This fix ensures custom product attribute values entered through Point of Sale are carried into inter-company sales and delivery documents. Businesses using POS ship-later flows with inter-company purchasing will now see the correct product descriptions on related delivery slips, reducing confusion and fulfillment errors.
Original PR description
*= sale_purchase_inter_company_rules Step to reproduce: - install `sale_purchase_stock_inter_company_rules` and pos with demo - from setting : - enable Multi-Step Routes - enable all options for…
*= sale_purchase_inter_company_rules
Step to reproduce:
- install `sale_purchase_stock_inter_company_rules` and pos with demo
- from setting :
- enable Multi-Step Routes
- enable all options for Inter-Company Transactions (for both companies)
- go to routes, un-archive MTO route
- create a product "A" with routes "MTO" and "buy"
- make the product available for pos (add into `Misc` category)
- create a attribute with custom attribute value and link it to "A"
- in vendor list, add "My Company (Chicago)" as vendor
- switch to Chicago company, for same product add some other vendor
- switch back to "My Company (San Francisco)"
- for pos, in setting enable "Allow Ship Later"
- open Furniture pos, create a order with Product "A"
- go to payment page and select "Ship Later" and pay
- a RFQ is created for this pos order, open and confirm it
- switch to "My Company (Chicago)"
- open sale order (remove "my quotation" filter)
- notice a quotation created from company 1, confirm it.
- open linked delivery slip
Observation:
- the delivery slip will not have description (custom value for attribute for A
is lost)
Cause:
- when preparing vals for SO for inter-company transaction from
`_prepare_sale_order_line_data` we never considered order from pos
- hence in this case, order lines never had custom attributed linked to them
- the description is computed from the attributes from SO
- SO never had them to begin with
Fix
- we introduced a method `_get_pcavs_from_pos_order` which fetch such attributes from pos order too
- to accomplish this we introduce a new module As there is no dependency with purchase and pos
opw-6213076
Forward-Port-Of: odoo/enterprise#131896
Forward-Port-Of: odoo/enterprise#119233A failing automated test for the Time Off Gantt planning view was corrected so it works consistently when demo data changes the user's time zone. This helps keep quality checks reliable and reduces the risk of blocking future updates for reasons unrelated to customer-facing behavior.
Original PR description
- the test `test_gantt_view_duration_based_schedule_with_leaves` was failing with demo data because the unavailability depends on the user tz which changes from False without demo to Europe/Brussels with demo data task-6584290 Forward-Port-Of: odoo/enterprise#132133
Indian payroll payment reports now stop when an employee has no bank account on record. This prevents payroll files from being generated with missing payment details, reducing the risk of failed or incomplete salary payments.
Original PR description
The payment report check looked at existing Indian bank accounts with an invalid IFSC. An employee withno bank account added nothing to it, so they passed the check and the report was generated with no account for them. task-6580632 Forward-Port-Of: odoo/enterprise#132097
This fixes a Belgian payroll calculation rule so it applies the correct employer contribution code. It helps ensure payroll results use the intended contribution and reduces the risk of incorrect payroll amounts or reporting.
Original PR description
One-line fix to use the correct contribution task-6526911 Forward-Port-Of: odoo/enterprise#132107
The Colombian Libro Diario report no longer fails when comparison options are enabled. It also now includes journal entries without a partner and keeps required report headers visible, helping businesses maintain complete legally required reporting.
Original PR description
## [FIX] l10n_co_reports: fix UNION ALL crash with multiple column groups ### Issue: Any comparison mode (Period, Analytic, etc.) in the Libro Diario raises an Odoo Server Error ### Cause: Each…
## [FIX] l10n_co_reports: fix UNION ALL crash with multiple column groups
### Issue:
Any comparison mode (Period, Analytic, etc.) in the Libro Diario raises an Odoo Server Error
### Cause:
Each sub-query in the `UNION ALL` had its own `ORDER BY` SQL only allows one global `ORDER BY` on a `UNION ALL`, or parentheses around each query — neither was the case
### Steps to reproduce:
- Install `l10n_co_reports` and `accountant`
- Enable Developer Mode in Settings
- Open the Libro Diario report and click the gear icon (top right)
- In the Options tab, enable Period Comparison
- Enable the Comparison for the Previous Period
Before the fix, an error is raised
------------------------------
## [FIX] l10n_co_reports: include partnerless entries in Libro Diario
### Issue:
Journal entries without a partner are excluded from the report but are legally required to appear
### Cause:
`_get_domain` called `super()` which adds `('partner_id', '!=', False)` to the domain, filtering out all partnerless entries
The SQL query also used a `JOIN` instead of `LEFT JOIN` on `res_partner`, excluding lines with no partner at the DB level
### Notes:
`NULL` values for `partner_name` or `line_label` caused the JS to hide the corresponding column headers
`header.js` matches columns to their header by `column_group_index`/`expression_label` and skips `None` values
Fixed by using `COALESCE` to return an empty string instead
### Steps to reproduce:
- Install `l10n_co_reports` and `accountant`
- Create a Journal Entry without a partner or label
- Open the Daily Journal Report
Before the fix, the entry doesn't appear
After the fix, check that PARTNER and LABEL headers are visible
opw-6430728
Forward-Port-Of: odoo/enterprise#132066
Forward-Port-Of: odoo/enterprise#129674The online payment flow now performs its checks in the correct sequence before starting a payment action. This reduces the chance of payment attempts being blocked or handled incorrectly due to validation order issues.
Original PR description
No task ID Forward-Port-Of: odoo/enterprise#132165
When a Belgian employee leaves because a fixed-term contract has ended, the contract record is now correctly marked as fixed-term. This keeps payroll and HR history accurate and ensures the change is visible in the employee activity log.
Original PR description
Set the `fixed_term` boolean field to True on the employee contract version whenever a Belgian departure with the 'Fixed Term' reason is processed. Changes are properly tracked in the employee's chatter. To test: 1. Create a Belgian employee with a contract start and end date. 2. Click on 'End of Collaboration'. 3. Select 'Fixed Term' as the end reason and confirm. 4. Check the employee chatter to verify that 'Fixed Term' is set to True (No -> Yes). Task: 6528392 Forward-Port-Of: odoo/enterprise#132110
The VoIP call flow editor now correctly replaces an existing connection when users rewire a call route to a new destination. This prevents broken or rejected links and avoids misleading duplicate-connection warnings, making call flow changes more reliable.
Original PR description
## Summary - Grabbing an already-connected output port and dragging it to a new target used to search for another output port instead of an input port, so the old connector was removed without ever…
## Summary - Grabbing an already-connected output port and dragging it to a new target used to search for another output port instead of an input port, so the old connector was removed without ever being replaced. - Dropping a new connection onto an output port that was already at its connection limit was rejected outright instead of replacing the existing connection. - A successful reconnect could still show "This connection already exists.": `onConnect` feeds the new connection back through props synchronously, and `onWillUpdateProps` can sync it into the store before `connectPorts`'s own post-connect validation runs, making the connection look like a duplicate of itself. ## Test plan - [ ] Open a call flow, connect an output port to a target, then drag that same output port to a different target: the old link is removed and the new one is created in one action. - [ ] Drag a new connection onto an output port that already has one: the old link is replaced instead of showing a rejection. - [ ] Confirm no "This connection already exists." notification appears for a valid reconnect. Forward-Port-Of: odoo/enterprise#131942
This fix ensures product descriptions expand to the right height when edited in delivery picking forms. Users can now view and edit full product descriptions without text being partially hidden, improving accuracy during warehouse operations.
Original PR description
**Issue** The height is not correctly computed in the picking form when editing product description. **Steps to reproduce** - Create a delivery for a product - Add a description to it - Click on…
**Issue** The height is not correctly computed in the picking form when editing product description. **Steps to reproduce** - Create a delivery for a product - Add a description to it - Click on editing the description -> Observe that the description is partially hidden because the widget height is incorrectly computed **Cause** Since commit https://github.com/odoo/odoo/commit/e4f4171e1bc838840c0bd6111cd78f348b201ac2, `useProductAndLabelAutoresize` no longer assigns a height to the widget root. The corresponding widget is `MoveProductLabelField`, which extends `ProductNameAndDescriptionField`: https://github.com/odoo/odoo/blob/91b59f285248c120fe9e3e5f6b6f086ea7be2837/addons/stock/static/src/views/picking_form/stock_move_product_label.js#L5 It uses `useProductAndLabelAutoresize`: https://github.com/odoo/odoo/blob/91b59f285248c120fe9e3e5f6b6f086ea7be2837/addons/product/static/src/product_name_and_description/product_name_and_description.js#L54-L56 **Solution** Explicitly add a div around the product display and description to still use the `Autoresize` Forward-Port-Of: odoo/odoo#280243 Forward-Port-Of: odoo/odoo#271564