Daily updates from Odoo
Tuesday, January 6, 2026
66 changes · saas-19.1
Resolved issues and error corrections
This update fixes an issue where employees with past accrual allocations weren't correctly accounting for future leave days. Now, leave requests are only deducted from available days if there's a possibility of accruing more vacation time before the leave date. This ensures accurate tracking of available time off.
Original PR description
Description of the issue/feature this PR addresses: This ticket: https://www.odoo.com/odoo/project/49/tasks/5218745 In the above ticket, an employee Norbert Loibl had an accrual allocation from Feb.…
Description of the issue/feature this PR addresses: This ticket: https://www.odoo.com/odoo/project/49/tasks/5218745 In the above ticket, an employee Norbert Loibl had an accrual allocation from Feb. 2023 to May 2024. Since then, all his allocations have been regular allocations, so he is no longer accruing vacation days. But, Norbert’s future leaves do not get counted against the “Days Available” displayed on his Time Off Dashboard. Current behavior before PR: If an employee had an accrual allocation (of the relevant type, e.g. past vacation allocations won’t affect sick leave) at any point in time, their future leaves do not get counted against the “Days Available” on their Time Off Dashboard. Desired behavior after PR is merged: If an employee has an accrual allocation between today’s date and the date of a future leave, that future leave does not get counted against the “Days Available” on their Time Off Dashboard. That way, we will count a leave against “Days Available” unless there is a possibility of accruing more days off before the leave. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241216 Forward-Port-Of: odoo/odoo#238977
This update corrects a warning related to employee compensation calculations within the US payroll module. The change restores a key logic element to accurately identify employees without worker compensation, ensuring payroll reports are reliable. This fix was implemented as part of a larger refactoring effort.
Original PR description
> note: to be fw'd till 19.0 (will be fixed in master by https://github.com/odoo/enterprise/pull/99256) description: following the refactor (https://github.com/odoo/enterprise/pull/83136), the warning (`hr_payroll_dashboard_warning_employee_wa_without_worker_compensation`) has been altered. fix: this commit adds back `not` to compute the `employees_without_worker_compensation` accurately. :) task-5407490 Forward-Port-Of: odoo/enterprise#101663
This update fixes an issue where the DIN5008 invoice report didn't include Incoterm information. The fix adds the necessary logic to display the Incoterm code and location, ensuring compliance with DIN5008 standards. This improves invoice accuracy and reporting for international transactions.
Original PR description
**Steps to reproduce:** 1. Install the modules account and l10n_din5008. 2. Go to Settings and set DIN5008 as the default invoice report template. 3. Navigate to Configuration → Settings and set a default Incoterm. 4. Create a new customer invoice. 5. Print the DIN5008 Invoice Report. **Issue:** The DIN5008 invoice report did not display the Incoterms, while other invoice layouts printed them correctly. **Cause:** This was due to missing logic in l10n_din5008 report to include Incoterm data. Confirmed with TSB that the DIN5008 layout should display Incoterms. **Fix:** This commit adds the Incoterm information to the DIN5008 template data: - Always include the Incoterm code - If an Incoterm location is set, display it as `CODE - LOCATION` **opw-5349267** Forward-Port-Of: odoo/odoo#240688 Forward-Port-Of: odoo/odoo#238682
This update resolves a technical error that prevented timesheets from correctly linking to sales orders when multiple matching orders existed. The fix ensures the timesheet always connects to the first applicable sales order, maintaining consistent functionality. This prevents a 'singleton' error and ensures accurate timesheet reporting.
Original PR description
Steps to reproduce: ------------------------------ 1. Install `industry_fsm_sale` module. 2. Open the settings of the field-service project and open the invoicing page 3. Add one employee on the…
Steps to reproduce:
------------------------------
1. Install `industry_fsm_sale` module.
2. Open the settings of the field-service project and open the invoicing page
3. Add one employee on the Invoicing page and create a new product with a Unit Price
4. On the product form, set the same value in the Sales Price field
5. Create a Sale Order with two sale order lines that use the same product and the same quantity
6. In Field Service create a Task for the same customer and set one of the sale order lines in the Sales Order Item field.
7. Create one timesheet for the task using the same employee added in the Invoicing page. Save the timesheet and click Mark as done
Observation:
------------------------------
A singleton traceback occurs when marking the task done:
```
raise ValueError('Expected singleton: %s' % record)
ValueError: Expected singleton: sale.order.line(62, 63)
```
Issue:
------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/31663b503c75dc2a83cc9585280df02f4d704e89/industry_fsm_sale/models/project_task.py#L507-L511
According to our scenario, we will get two SOL for the same product `id` and `price_unit` Which on further used to link the SOL to timesheet. Following code assumes the single SOL and gives singleton error https://github.com/odoo/enterprise/blob/31663b503c75dc2a83cc9585280df02f4d704e89/industry_fsm_sale/models/project_task.py#L553-L554
Solution:
------------------------------
When building the `sols_by_product_and_price_dict` using the key
(product_id, price_unit), When multiple sale order lines exist for the same key,
only keep the one that comes first in the sequence to maintain the consistency.
as in following code:
https://github.com/odoo/enterprise/blob/a7b79f79d90a37fb2458f05bcf439c109f1d756f/industry_fsm_sale/models/account_analytic_line.py#L15-L20
This ensures the timesheet always links to the first applicable sale
order line, matching existing behavior.
opw-5373018
Forward-Port-Of: odoo/enterprise#101774This update fixes issues with image dropping, copying, and pasting within the website builder, ensuring images with captions are handled correctly and formatting is preserved. It resolves duplication errors and incorrect attribute handling, leading to a more reliable and user-friendly editing experience.
Original PR description
**Current behavior before PR:** - When dragging and dropping elements with attributes and classes, any non-whitelisted attributes and classes were removed during the `cleanForPaste` process. This…
**Current behavior before PR:** - When dragging and dropping elements with attributes and classes, any non-whitelisted attributes and classes were removed during the `cleanForPaste` process. This caused structural issues and loss of formatting after the drop. - When an image had a caption and only the image was selected and cut, the image was removed but the caption incorrectly remained - When dragging and dropping an image without an active selection on the image, the image was not removed during the drop. This resulted in the image being duplicated, one at the original position and another at the drop location. - When selecting an image with a caption and performing copy-paste, only the image was copied and pasted. **Desired behavior after PR is merged:** - An `application/vnd.odoo.odoo-editor` dataTransfer type is now set during `dragstart` for editor elements. As a result, we no longer need to clean the `dataTransfer` content during drop, preserving the original structure and preventing the loss of attributes and classes. - Cutting an image that contains a caption now correctly removes both the image and its associated caption. - The image is now selected on pointerdown event . As a result, when the image is dropped, deleteSelection correctly removes the original image before inserting the new one, preventing duplication. - Now, when an image with a caption is selected and copy-pasted, the entire image along with its caption is correctly copied and pasted. task: 4914451 Forward-Port-Of: odoo/odoo#240788 Forward-Port-Of: odoo/odoo#217125
This update resolves an issue where unnecessary dialogs appeared during One-click Payment in the POS system, leading to errors. The fix ensures that orders are validated correctly and users are smoothly redirected back to the previous screen if validation fails. This enhances the overall reliability and usability of the One-click Payment feature.
Original PR description
steps: - Configure a default preset as Delivery or Takeout and enable One-click Payment - Open the POS restaurant. - Open any table and add a product. - Click the One-click payment method. issue: - Unnecessary dialogs appear on the ReceiptScreen (e.g., customer selection or time-slot selection), followed by traceback. reason: - The order is validated on the ProductScreen during One-click Payment and ProductScreen creates new draft order. fix: - After this commit, new order will not be created on the ProductScreen with One-click Payment.. - If validation fails (e.g., an RPC error), it will redirected back to the previous screen. - In case of Delivery preset, on discard do not remove Delivery preset. task-5391389 Forward-Port-Of: odoo/odoo#239038
This update fixes a visual issue in Odoo's Chatter where attachments and emoji reactions would overlap, creating a cluttered and difficult-to-read message view. By adding strategic spacing, the update ensures a cleaner, more consistent layout for all message types, improving overall user experience.
Original PR description
**Description of the issue/feature this PR addresses:** ---------------------------------------------- In version 19, when a message in the Chatter includes an attachment and an emoji reaction is…
**Description of the issue/feature this PR addresses:** ---------------------------------------------- In version 19, when a message in the Chatter includes an attachment and an emoji reaction is added, both elements appear visually too close to each other. This overlap creates a cluttered look and reduces readability in the message view. **Current behavior before PR:** ---------------------------------------------- - Emoji reactions and attachment previews are rendered too close together. - Negative or insufficient top margin on the reactions container causes overlap. - Visual inconsistency between text-only messages and messages with attachments. **Desired behavior after PR is merged:** ---------------------------------------------- - Proper spacing between attachments and emoji reactions in the Chatter. - Consistent, clean layout across all message types. - Improved readability without affecting compactness for text-only messages. Task-5259482 ---------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at https://www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237943
This update fixes an issue where the website's highlight color didn't automatically update when the overall theme was changed. The fix ensures that text highlights, particularly in the footer, now correctly reflect the selected theme colors, providing a consistent and visually appealing user experience. This improves brand consistency and user satisfaction.
Original PR description
Steps to reproduce: 1. Go to the theme tab and change the colors of the main preset. 2. Select any text in the footer. 3. Expand the toolbar and click the highlight option. Issue: The highlight…
Steps to reproduce: 1. Go to the theme tab and change the colors of the main preset. 2. Select any text in the footer. 3. Expand the toolbar and click the highlight option. Issue: The highlight selector still uses the default purple color instead of adapting to the updated theme preset. This happens because the text highlight color uses "--o-color-1", which does not update when the theme colors are modified. Fix: Used "var(--hb-cp-o-color-1)" as the default text highlight color instead of "--o-color-1", ensuring the highlight automatically adapts to theme changes. Before This Fix: | highlight selector color before changing theme preset | highlight selector color after changing theme preset | |-----------------------------|---------------------------------| | <img width="450" height="404" alt="image" src="https://github.com/user-attachments/assets/c92eed7e-1856-4e08-879a-a74e2506ab9c" /> | <img width="399" height="389" alt="image" src="https://github.com/user-attachments/assets/9a938e80-9e01-49fd-b6a1-cf9baaa64358" /> | After This Fix: | highlight selector color before changing theme preset | highlight selector color after changing theme preset | |-----------------------------|---------------------------------| | <img width="394" height="413" alt="image" src="https://github.com/user-attachments/assets/674958bc-7df7-44fa-97c0-5ae78608dc6a" /> | <img width="408" height="428" alt="image" src="https://github.com/user-attachments/assets/1d48ca49-7d18-4681-8443-b9887eef0dbf" /> | task-5375414 Co-author: Alay Patel <alap@odoo.com> Forward-Port-Of: odoo/odoo#238471
This update addresses technical issues impacting the HR EDI module, specifically resolving errors identified during automated testing and correcting a problematic SQL query. These fixes ensure the module's core functionality operates reliably and consistently, aligning with previous Odoo 19.0 releases.
Original PR description
- Fixing runbot errors raised by the flow tests, consistent with 19.0+ version - Fixing neutralize.sql runbot-237635 runbot-237637 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242007
This update clarifies delivery addresses in the delivery slip report by explicitly labeling them 'Delivery Address'. It also simplifies customer information labels to 'Customer' to prevent confusion. These changes enhance operational efficiency and reduce errors in order fulfillment.
Original PR description
To resolve ambiguities and improve operational efficiency: 1. The delivery address is explicitly labeled 'Delivery Address'. Ensuring no doubt about the final destination. 2. The label for the customer's primary information has been updated from 'Customer Address' to simply Customer, which prevents operators from mistaking it for the delivery point. Backport of https://github.com/odoo/odoo/pull/220019 Task: 3379926 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#241988
This update enhances the import action's flexibility by allowing users to specify the target model through parameters. This change provides retrocompatibility for existing import actions and ensures continued functionality for modules like Account and Bank Statement imports. It addresses a previous issue where a prior change partially reverted this feature.
Original PR description
This commit follows up the commit [1] and allows adding an `model` to the parameters of the `import` action, for retrocompatibility purposes. Note that, this retrocompatibility existed before the commit [2], which was partially reverted by the commit [1]. [1] https://github.com/odoo/odoo/commit/7e351d87a5b6faad5bef447bdb077b7637f9c936 [2] https://github.com/odoo/odoo/commit/033d6afe36426067a7bada8b812898169d7968de Forward-Port-Of: odoo/odoo#241993
This update removes a previously implemented fix for the account import action. A similar correction has been addressed in a related extended class, making this reversion redundant. This ensures consistent functionality and avoids unnecessary code changes.
Original PR description
Since [1] the fix on account_import_action is not needed anymore, a similar fix is done in the extended class. [1] https://github.com/odoo/odoo/commit/7e351d87a5b6faad5bef447bdb077b7637f9c936 Forward-Port-Of: odoo/enterprise#103216
This update clarifies the documentation for a feature within the Odoo account module. Previously, it wasn't clear that the 'force create' function didn't actually create new records, but instead updated existing ones. This change ensures better understanding and consistent use of this functionality.
Original PR description
I have adding a docs for force_create that I have added in a previous task as it was not clear for some colleagues that it do not create but still updates the available records 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#241995
This update fixes a minor visual issue on the user profile page where course tags were being cut off at the bottom. The change ensures all tags are fully visible, maintaining a consistent and professional appearance. This was implemented to improve the user experience and prevent a potential negative impression.
Original PR description
In the website profile page, the course tags are slightly cut on the bottom. This commit adapts the block size to fit the entire tag. Note that the combo of fixed height / hidden overflow is actually intended to only show a single line of tags and not all of them, to avoid having a variable course card total height. Task-5457464 Forward-Port-Of: odoo/odoo#241897
This update corrects a bug that caused subscription order processing to repeat unnecessarily, leading to potential delays. The fix ensures that order progress is accurately tracked, preventing reprocessing and improving the reliability of subscription order management. This resolves a technical issue impacting order processing efficiency.
Original PR description
Before this commit, when the continue instruction was called before the _subscription_commit_cursor call, the order would be reprocessed again and and again. Commit with a progress=1 was commited but if the continue was called before, progress with 0 was never called. Forward-Port-Of: odoo/enterprise#102142
This update resolves a recurring issue that caused calendar popover tests to fail intermittently. The change simplifies the test by reducing reliance on strict timing, ensuring the test consistently passes and accurately verifies the popover's final placement. This improves the reliability of our calendar functionality.
Original PR description
This commit addresses a timing issue in the calendar popover rendering test. Previously, `runAllTimers` was used to wait for the popover animation to complete before verifying its position. However, this approach was not fully reliable, leading to flaky test results. The solution removes the dependency on `runAllTimers` and slightly relaxes the position assertion. This allows the test to pass even if the animation has not fully completed, prioritizing the correctness of the final placement logic over the animation timing. runbot-error-237534
This update resolves a technical issue that prevented users from accessing holiday attests in debug mode. The fix adds a necessary data field to the component's configuration, ensuring the system correctly processes departure requests and avoids error messages.
Original PR description
Issue: in debug mode, the function `validateProps` is called on the component so it raises an error because `payslipsYear` is in the props but not defined in the schema Steps to reproduce (developer mode): - fill in the departure notice period and payslip wizard - try to open departure: holiday attests from the cog menu - you get a traceback because of unknown key `payslipsYear` Fix: added `payslipsYear` to the props definition task-id: 5398621 Forward-Port-Of: odoo/enterprise#101605
This update fixes a reporting error in the French P&L statements. The 'owner remuneration' account (644) was incorrectly categorized as 'tax and duties'. This change ensures accurate reporting of wages and salaries for French businesses, aligning with accounting standards.
Original PR description
Account '644 owner remuneration' was in the 'tax and duties' category in the french P&L but it belongs to the 'wages and salaries' category task-5446018 Forward-Port-Of: odoo/enterprise#103214 Forward-Port-Of: odoo/enterprise#103061
This update enhances the security of our expense tracking system by adding a crucial layer of protection during database copies. This ensures that database copies created for support investigations won't inadvertently impact the live production system or customer data. It addresses a rare scenario related to new account creation, making the overall neutralization process more robust.
Original PR description
This commit adds a complement to the neutralization necessary for the hr_expense_stripe module. The main neutralization is handled by the certificates module, but this covers a rare edge case (creation of new accounts in production mode for companies that do not already have an account), and makes the overall neutralization more bullet proof. ---------------------------------------------------------------------- The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. Forward-Port-Of: odoo/enterprise#102702
This update resolves an issue where color fields within editable lists weren't consistently saving changes when using the 'bottom' editing mode. Previously, edits to color fields were lost. This fix ensures that color field changes are now reliably saved, improving data accuracy and usability within Odoo's list views.
Original PR description
This commit fixes the issue where editing a field with widget="color" does not save it when the list is in editable="bottom" mode. project.task~5262582 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#238644
This update resolves an error that prevented managers with basic employee management rights from accessing employee appraisals. The fix ensures that users only see the appraisal button when they have the necessary appraisal permissions, improving system stability and preventing unexpected errors. This change ensures consistent access control for appraisal functionality.
Original PR description
An error occurs when a user with `Employee Management` rights, but without any appraisal rights, tries to open an employee’s appraisals. **Steps to Reproduce:** 1) Install Appraisals App.(with Demo).…
An error occurs when a user with `Employee Management` rights, but without any appraisal rights, tries to open an employee’s appraisals. **Steps to Reproduce:** 1) Install Appraisals App.(with Demo). 2) Log in as admin, open Marc Demo in Settings > Users & Companies > Users, and set `Employees: Officer (Manage all employees)` under HR section. 3) Log in as Marc Demo and open any employee profile (e.g., Anita Oliver). 4) Click on `Appraisals smart button`. **Error:** `IndexError: tuple index out of range` **Root Cause:** When a user has only employee management rights, `self.appraisal_ids` received in the method at [1] becomes an empty tuple. Accessing `self.appraisal_ids[0].id` therefore raises an `IndexError`. **FIX:** If no `appraisal_ids` are available, return the list view of appraisals, matching the behavior from previous versions. [1]- https://github.com/odoo/enterprise/blob/3ee1df0b806f9c73d79b8b55fcc7d55b530d9e6b/hr_appraisal/models/hr_employee.py#L169-L180 sentry-7032734789 Forward-Port-Of: odoo/enterprise#99662
This update fixes a visual issue where the search panel was being cut off when navigating deep within the hierarchy view. The change allows the hierarchy content to scroll properly, ensuring a full and usable experience for users managing complex data structures. The fix also stabilizes a key test case.
Original PR description
Issue: - The search panel was getting clipped when navigating deep into the hierarchy. - `.o_content` enforced `height: 100%` and `overflow: hidden`, preventing the hierarchy from expanding and blocking vertical scroll. - The JS test "drag node to scroll" queried `.o_content`, which is no longer the actual scrollable container in the hierarchy view, causing intermittent test failures. Fix: - Allow `.o_content` to grow and remove overflow restrictions only in the hierarchy view. - Enable vertical scrolling on `.o_hierarchy_view.o_action` to support large hierarchies. - Update the test to query `.o_hierarchy_view.o_action` so it targets the correct scrollable element. Impact: - Restores proper scrolling behavior. - Prevents search panel truncation and preserves full UI usability. - Stabilizes the hierarchy drag-scroll test without impacting other views. Task: 5326054 Forward-Port-Of: odoo/odoo#236823
This update corrects a problem where delivery pickings remained 'Waiting Another Operation' after cancelling a related manufacturing order (MTO). The fix reuses existing logic to properly unlink stock moves and update availability, ensuring deliveries can be confirmed correctly. This prevents delays in order fulfillment.
Original PR description
Issue ----- After cancelling a MO created by a SO (MTO), user cannot reserve quantity from stock for the delivery picking. This happens for both MO & Reception as long as they are multi-step. Steps…
Issue ----- After cancelling a MO created by a SO (MTO), user cannot reserve quantity from stock for the delivery picking. This happens for both MO & Reception as long as they are multi-step. Steps to reproduce ----- - Enable multi step routes - Set WH to 3-step manufacturing - Create a product - empty bom - MTO & manufacturing routes - 5 in stock - Create a SO for the product - Cancel the linked MO - Open the delivery picking - Click "Check Availability" > The product is not getting reserved from stock > The delivery picking is still "Waiting Another Operation" Cause ----- The problem happens in `action_cancel` https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L1995 In 1-step case, `move.propagate_cancel` is false so we go through https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L2017-L2021 where `move_dest_ids` is the move of the delivery picking. This makes it so that, when we go to the delivery picking and do `action_assign` we go through the first condition while skipping the second of https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L1929-L1931 instead of going into the `else` part https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L1947-L1949 In 3-step, when we `action_cancel`, `move.propagate_cancel` so we go through https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L2009-L2014 which lacks the swap to MTS and unlink `move_dest_id` logic. Solution ----- We can re-use the logic of unlink and MTS swap to `move_dest_ids` that were not cancelled by https://github.com/odoo/odoo/blob/0eb44aec8867e292f8258df02045efe7fbd3303f/addons/stock/models/stock_move.py#L2012 This also takes care of the problem of the status of the delivery picking being `waiting` instead of `confirmed` because it gets recomputed https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L754 and since it was set to MTS, it goes into the `else`part of https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L2202-L2216 ----- Ticket: opw-5124380 Forward-Port-Of: odoo/odoo#241738 Forward-Port-Of: odoo/odoo#237890
This update adds a new test case to ensure that work entries are generated correctly within the HR module. This fix addresses a potential issue with the work entry generation process, enhancing the reliability and accuracy of HR workflows. The test confirms the fix implemented in a previous pull request.
Original PR description
This commit adds a test for this fix PR: https://github.com/odoo/odoo/pull/239855 task-5413594 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#240185
This update includes a new test to verify the correct generation of work entries within the l10n_be_hr_payroll module. This fix ensures accurate payroll calculations for Belgian businesses using this module, addressing a potential issue with work entry creation. The addition of this test enhances the reliability of the payroll system.
Original PR description
This commit adds a test for this fix PR: https://github.com/odoo/odoo/pull/239658 task-5413594 Forward-Port-Of: odoo/enterprise#102217
This update resolves an issue where a reporting view was incorrectly referencing a non-existent element in Odoo. By adjusting the priority of the views, the system now correctly displays information, ensuring accurate reporting for Mexican EDI stock transactions. This fix was coordinated with a related community PR.
Original PR description
Currently, `base_vat.view_partner_base_vat_form` creates a new div `vat_vies_container`, which is later referenced by the `l10n_mx_edi_stock.mx_partner_operator_form` view. **Root cause:** When the corresponding fix is applied in the community PR, both views end up having the same priority. In this situation, the `mx_partner_operator_form` view applied before `vat_vies_container` is created, causing it to reference a div that does not yet exist (see commit [1]). **Fix:** This commit ensures that the priority of `l10n_mx_edi_stock.mx_partner_operator_form` is lower than `base_vat.view_partner_base_vat_form`, and the container is created before it is referenced. Related community PR: https://github.com/odoo/odoo/pull/241707 [1]: https://github.com/odoo/odoo/pull/161962/commits/653a3eae0bd848cff5862288f30333aa43ae8fe9 opw-5443833
This update improves the clarity of our gratuity reports by now including information on how gratuity is calculated. Previously, this crucial detail was missing, making it difficult to understand the report's figures. This change ensures greater transparency and accuracy for financial reporting.
Original PR description
Before: - We were not printing any information about how gratuity is being calculated. After: - We are going to print information about how gratuity is being calculated. task-5454700
This update fixes an issue where Odoo incorrectly processed partner names consisting of only one word. Previously, these names resulted in an empty first name field. Now, single-word names are correctly assigned to the first name, ensuring accurate partner data is displayed and processed.
Original PR description
Description of the issue/feature this PR addresses: The name splitting logic fails when the partner name contains only one word, resulting in an empty first name. Current behavior before PR: Splitting a single-word name returns an empty first name and assigns the word to the last name. Desired behavior after PR is merged: A single-word name is correctly assigned to the first name field, leaving the last name empty. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241926
This update fixes an issue where navigation using the up/down arrow keys within the HTML editor was not working correctly when inserting stars. The fix ensures that the star-containing lines are properly accessible and selectable, improving the user experience. This resolves a minor usability problem.
Original PR description
When put on a single line, the `o_stars` blocks are not reachable by up/down keyboard navigation because they lack `FEFF` characters to put the cursor. This commit fixes this be removing the outdated `200B` characters that were introduced in [1] and making `o_stars` surrounded by `FEFF`. Steps to reproduce: - Write two lines of text - Add a third line between the two by pressing enter at the end of the first one - Insert stars with `/stars` - Navigate with up/down arrow - Notice that the line with the stars is not skipped - Press Backspace before the stars and before the third line so that everything is on the same line - Press Enter before and after the stars to put then back in three lines - Navigate with up/down arrow => The line with the stars was skipped task-5392572 Forward-Port-Of: odoo/odoo#239432
This update fixes an issue where HR Officers could access restricted functionality within employee forms, leading to potential errors. The changes limit access to 'Create User' and certain data views to authorized HR Managers, ensuring data security and proper user permissions within the HR module. This prevents unauthorized actions and maintains data integrity.
Original PR description
* = hr_work_entry
Steps to reproduce:
- Install 'hr' and 'hr_work_entry'.
- Log in as an HR Officer.
- Open an employee form and click:
- 'Create User'
- 'Work Entries' smart button
- 'History' smart button
Cause:
- 'Create User' was visible to HR Officers, but only users with Settings rights
('base.group_erp_manager') can create 'res.users', causing an AccessError.
- The 'Work Entries' and 'History buttons were visible to HR Officers, but
fields as 'contract_date_start' which only HR Managers can read when
payroll is not installed.
Fix:
- Restricted 'Create User' to 'base.group_erp_manager'.
- Limited the 'History' smart button to 'hr.group_hr_manager'.
- Limited the 'Work Entries' smart button to 'hr.group_hr_manager'.
Task - 5188997
Forward-Port-Of: odoo/odoo#235923This update resolves an issue where HR Officers without payroll access could still view and modify salary adjustments data. The fix restricts access to sensitive payroll information and ensures that users only see relevant data based on their roles, improving data security and user experience.
Original PR description
* = hr_contract_salary Steps to reproduce: - Install 'hr', 'hr_payroll', 'hr_work_entry', and/or 'hr_contract_salary'. - Log in as an HR Officer without payroll access. - On an employee form: -…
* = hr_contract_salary
Steps to reproduce:
- Install 'hr', 'hr_payroll', 'hr_work_entry', and/or 'hr_contract_salary'.
- Log in as an HR Officer without payroll access.
- On an employee form:
- Switch to the 'Salary Adjustments' tab.
- Edit/save a record (tracking reads 'salary_offer_ids').
- Click the 'Work Entries', 'History', or 'Offers' smart buttons.
Cause:
- HR Officers could still reach payroll-only data:
- 'salary_offer_ids' (one2many to 'hr.contract.salary.offer') triggered
tracking reads on a model restricted to HR Managers/Recuriters.
- The 'Salary Adjustments' tab and offer buttons remained visible even when
the user lacked payroll rights.
- The payroll overrides changed 'contract_date_start' to
'hr_payroll.group_hr_payroll_user', so the 'Work Entries'/'History' buttons
show AccessErrors while the buttons stayed visible.
Fix:
- Restricted 'salary_offer_ids' to 'hr.group_hr_manager'.
- Made the 'Salary Adjustments' tab visible only to
'hr_payroll.group_hr_payroll_user' and existing 'Offers' buttons stay for
HR Managers.
- Added dedicated overrides giving 'Work Entries' and 'History' buttons the
'hr_payroll.group_hr_payroll_user' group when payroll is installed.
Task - 5188997
Forward-Port-Of: odoo/enterprise#99234This update fixes a potential issue where printing failed on Windows systems. The change adds a safety net to catch errors during printing, ensuring a more stable and reliable print experience. This improves the overall user experience for Odoo users on Windows.
Original PR description
This commit adds the try/except block around print_raw method of the virtual iot box to allow catching exceptions when printing on Windows Forward-Port-Of: odoo/odoo#238774 Forward-Port-Of: odoo/odoo#238633
This update resolves a bug that prevented users from exporting data from the MPS (Material Requirements Planning) view. The issue stemmed from a recent change that incorrectly pulled data from a related model, causing an error. Now, the export function correctly displays the expected fields from the 'mrp.product.forecast' model.
Original PR description
Steps to reproduce: - Go to MPS - Select one or more records - Click on Action > Export - Search and expand "Forecasted quantity at date" - Select "Forecasted quantity at date/Minimum to Replenish" - Export Before: A traceback is raised with the following error: "ValueError: Invalid field 'min_to_replenish_qty' on 'mrp.product.forecast'" This is caused by the model being overwritten by "mrp.production.schedule". The regression was introduced by commit ac52882, which added a default model "mrp.production.schedule". After: The export works correctly with sub fields. https://github.com/odoo/enterprise/commit/ac52882891a9ede6a5b008ac39fc62b82b7bf813 opw-5406704 Forward-Port-Of: odoo/enterprise#103097
This update fixes an issue where holiday carryover days weren't accurately calculated, leading to discrepancies in the number of days expiring. The change ensures that accrued holiday days are correctly added before the expiration date is determined, resulting in accurate holiday accrual and reporting.
Original PR description
To reproduce: ============= - Create an accrual plan: - Carryover date: allocation - One level: - Accrues 2 days. - Accrual date: monthly on 1st of each month - Starts immediately on allocation start…
To reproduce:
=============
- Create an accrual plan:
- Carryover date: allocation
- One level:
- Accrues 2 days.
- Accrual date: monthly on 1st of each month - Starts immediately on allocation start date - Carryover policy: all days carry over - Carried over days validity: 3 months.
- Create an allocation that uses the above accrual plan on 23/09/2025:
- Starts on 01/07/2024
We should have 30 days in total with 24 expiring on 01/10/2025 but we only have 22 expiring on 01/10/2025.
Problem:
========
When `accrued_gain_time` of the accrual plan is 'start', in the `_process_accrual_plans` method, the property `expiring_days` is set when the first accrual still hasn't been added to the `number_of_days` (it is usually added at the [end of the loop](https://github.com/odoo/odoo/blob/18.0/addons/hr_holidays/models/hr_leave_allocation.py#L596)).
Solution:
=========
In the `_process_accrual_plans`, add the accrued days to the `number_of_days` before the `expiring_days` is set.
[opw-4963163](https://www.odoo.com/odoo/all-tasks/4963163)
Forward-Port-Of: odoo/odoo#240738
Forward-Port-Of: odoo/odoo#233424This update fixes a technical issue that caused an error when reconciling invoices with multiple bank transactions. The fix ensures the reporting of invoice line amounts is accurate, even when multiple bank statements are used for reconciliation. This improves the reliability of financial reporting within the system.
Original PR description
### Issue description: The `_compute_full_amount_switch_html` method assumes that `reconciled_lines_excluding_exchange_diff_ids` contains at most one line (which is true only for move lines of bank statement lines). However, if an invoice is reconciled with multiple bank transactions, when accessing the `full_amount_switch_html` for any move line in the invoice, it triggers `ValueError: Expected singleton`, as the compute method uses the reconciled_lines as if they are a single line. ### Steps to reproduce: 1. Create an invoice 2. Reconcile the invoice with multiple bank transactions. 3. Perform a read on the `full_amount_switch_html` field on the invoice line from the invoice (using the web tool, or add the field to any view). 4. You will get `ValueError: Expected singleton: account.move(XX, XX)` opw-5224135 Forward-Port-Of: odoo/enterprise#103193 Forward-Port-Of: odoo/enterprise#102048
This update addresses a critical issue by implementing a 'neutralization' process for the l10n_gt_edi module. This ensures that support teams can safely examine database copies without risking disruptions to live customer data or impacting the main production database. It's a standard security practice to allow for safe troubleshooting.
Original PR description
This commit adds the missing neutralization necessary for the l10n_gt_edi module The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. Forward-Port-Of: odoo/enterprise#102695
This update ensures that Point of Sale line merges are only successful when the discount and unit price are identical. Previously, merging worked inconsistently, leading to potential errors. This change provides a more reliable and predictable merging process for Point of Sale orders.
Original PR description
Only allow merging lines if they have the same discount and unit price. Before this commit, you were able to merge lines with different discounts or unit prices only if the source order contained the line with the discount/price change. It was not working the other way which was inconsistent. task-id: 5189949 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232963
This update adds a critical neutralization process for the l10n_tw_edi_ecpay tax module. This ensures that support teams can safely examine database copies without risking changes to the live production system or impacting customer data. This is a standard security practice to allow for safe troubleshooting.
Original PR description
This commit adds the missing neutralization necessary for the l10n_tw_edi_ecpay module introduced in [1] The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. [1] https://github.com/odoo/odoo/pull/223132 Forward-Port-Of: odoo/odoo#240975
This update fixes an issue where the hours view would overlap with the progress bar display in the Gantt view when work entries were activated in sparse mode. This enhancement ensures a cleaner and more functional user experience for managing work entries within the Gantt chart.
Original PR description
When the work entry is activated in sparse mode prevent the hours view from overlapping. task-5410789 Forward-Port-Of: odoo/enterprise#101939
This update fixes an issue where imported DTE invoices in a multi-company environment incorrectly assigned tax to the wrong company. The fix ensures that the tax aligns with the company receiving the invoice, improving financial accuracy and compliance. This resolves inconsistencies during import processes.
Original PR description
**PROBLEM**
When importing a DTE from mail (using fetchmail) in a multicompany setting, there can be company inconsistencies during the import, i.e. the product created during the import belong to the right company, but the tax on a move line belong to another company.
**STEP TO REPRODUCE**
1. Create 2 CL companies with those VAT number: 22060449-7, 77697621-0
2. Set an incoming mail server for bills
3. Send XML to the mailbox (see in the ticket for the xml, one of them should trigger the bug, it depends on the order you created the companies).
4. Run a fetchmail scheduled action.
**CAUSE**
On the creation of the move line for the DTE bill, we retrieve the default purchase tax using `self.env['account.chart.template'].ref('OTAX_19')`. There is no guarantee this tax belong to the recipient company. We should use the default purchase tax of the recipient company instead.
opw-5378068
Forward-Port-Of: odoo/enterprise#102274This update resolves an installation problem that previously caused the website rental module to fail during setup. The fix moves a key function to the correct module, ensuring compatibility with the website's installation order and preventing installation errors. This improves the reliability of the rental pricing feature.
Original PR description
## Steps To reproduce: 1. On a local environment, install **`website_sale_renting`** using `-i website_sale_renting` 2. During installation, the process reaches **`website_sale`**. 3. A traceback is…
## Steps To reproduce: 1. On a local environment, install **`website_sale_renting`** using `-i website_sale_renting` 2. During installation, the process reaches **`website_sale`**. 3. A traceback is raised while loading `website_sale/data/mail_template_data.xml`. --- ## Issue * The installation fails during **`website_sale`** because the mail template calls `_get_rental_pricing_description()` on `sale.order.line`, but the method is not available at that stage. --- ## Cause: * `_get_rental_pricing_description()` existed previously but was defined in **`website_sale_renting`**. * A recent design PR- odoo/odoo#213186 introduced a `t-if="hasattr(combo_line, 'is_rental')"` guard in the `website_sale` mail template. * Since `mail.template`'s body_html data is parsed as HTML, the template cannot be safely extended via XPath in other modules. * Module installation order is: `sale → sale_renting → website_sale → website_sale_renting` * When **`website_sale`** is installed: * `sale.order.line` already has the `is_rental` field (from `sale_renting`) * but `_get_rental_pricing_description()` is not yet present, as it is only loaded with `website_sale_renting` This causes the guard to pass while the method call fails, leading to a traceback during installation. --- ## Solution: * Move `_get_rental_pricing_description()` to the **`sale_renting`** module, alongside the `is_rental` field. * This ensures the method is always available whenever rental logic is enabled and makes `website_sale` mail templates safe regardless of installation order. opw-5454946 Affected Version-saas~19.1
This update ensures the Live Chat info panel automatically opens or closes based on your previous preference. Previously, users had to manually adjust the panel each time they switched between chats. This change improves the user experience by streamlining the Live Chat interface.
Original PR description
**Purpose of this PR:** Previously, the livechat info panel would always open by default when switching between chats, regardless of the user's preference. This required users to manually close the panel repeatedly. This commit persists the panel's toggle state, so the panel remains open or closed based on the user's last choice across all livechat sessions. Task-5291258 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238472
This update resolves a bug where the 'snippet_carousel_clickable_slides' tour would fail to function correctly when users pressed the Enter key. The fix redirects users to use the Tab key, which doesn't trigger the same issue, ensuring the tour consistently works as intended.
Original PR description
__Before this commit:__ The tour `snippet_carousel_clickable_slides` sometimes fails because the URL anchor does not get removed when Enter is pressed. __Reason:__ When inputting in an `Autocomplete`, the `loadingPromise` is set and it's only resolved after the sources are loaded. If Enter is pressed before it is resolved, the `onchange` event is not fired because [`preventDefault` is called inside `onInputKeydown`][1]. __Fix:__ Use Tab in `snippet_carousel_clickable_slides` instead of Enter because Tab doesn't have this behavior. [1]: https://github.com/odoo/odoo/blob/6c07ba93171eb25be64ef990d047915fac2f3381/addons/web/static/src/core/autocomplete/autocomplete.js#L401 runbot-234687
This update resolves a sporadic test failure related to how partner suggestions are sorted, specifically when messages are sent. The fix ensures the test accurately reflects the system's data by waiting for the necessary updates to be processed before verification, preventing incorrect sorting results.
Original PR description
Before this commit, the test "Sort partner suggestions by recent chats" fails non-deterministically due to a race condition. This failure occurs because the test relies on the `last_interest_dt` timestamp being updated after sending a message to "User 2". Although the message post triggers a bus notification to update the store, the UI displays the message optimistically. As a result, the assertion for the message's existence occasionally passes before the bus notification was processed, leaving the sorting logic to run with stale data (where "User 2" was still ranked behind "User 3"). This commit fixes the issue by waiting for the sidebar to reorder "User 2" to the top. Since the sidebar ordering relies on the same server data (last_interest_dt) as the suggestion sorting, this ensures the store has processed the bus event before the test verifies the suggestion order. runbot-237553 Forward-Port-Of: odoo/odoo#241619
This update fixes an issue where helpdesk ticket creation would fail due to incorrect access permissions across different companies. The change prevents unnecessary data fetching in sudo, ensuring users only access resources within their own company when creating tickets. This improves stability and prevents errors for users with multi-company setups.
Original PR description
Before this commit, the `resource_ids` field in `res.users` model was fetched in sudo due to the `resource_calendar_id` related field in `res.users` and so the user will get the resources of members…
Before this commit, the `resource_ids` field in `res.users` model was fetched in sudo due to the `resource_calendar_id` related field in `res.users` and so the user will get the resources of members in a helpdesk team from another company than the current one(s). The problem is since the current user does not have access to those resources due to the multi company rule, he will get a traceback when he will try to create a ticket from that helpdesk team if the assignement method is ramdom and a user with resource exists in another company. This commit makes sure the resource_ids field in res.users is not fetched in sudo to correctly determine which user to set to the ticket when the current user tries to create a ticket. Steps to reproduce the issue: ---------------------------- 1. Install helpdesk module 2. Create a new company B 3. Create a new user with helpdesk user access right (or use Marc demo) and give the company B to that user 4. Select that new company created in step and go to helpdesk app. 5. Create an helpdesk team with auto-assignment set to "randomly" and set admin user as members in that helpdesk team 6. log in as the user created in step 3 7. make usre the company selected is the one created in step 2 8. create a ticket in the helpdesk team created in step 5 Expected behavior: ----------------- The ticket should be created without any issue. Actual behavior: --------------- An access error is raised because the current user does not have access to the resource of admin user since it is not in the same company than the current one. opw-5223717 Forward-Port-Of: odoo/enterprise#102910 Forward-Port-Of: odoo/enterprise#102859
This update fixes a usability issue in the Kanban view where dropdown items within cards weren't easily navigable or highlighted on hover. The team added a styling class to these items, ensuring they function correctly and provide a better user experience for selecting options within Kanban cards.
Original PR description
Issue:
Dropdown item-ish (such as `<a class="dropdown-item">` and ViewButton) inside kanban cards dropdown do not have the proper hover styling and are not navigable.
Steps to reproduce:
- Go to project -> open any card dropdown menu ("...") -> Items are not navigable
- Go to CRM -> open any card dropdown menu ("...") -> Items are not highlighted on hover
Fix:
This commit adds the "o-navigable" class to dropdown items and view buttons
which are inside a kanban card's dropdown menu, this makes them navigable
and adds proper hover and focus styling.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#240090This update enhances the reliability of video calls within Odoo by extending the time allowed for a successful ping to the server. Previously, a missed ping would immediately drop the call, but now the system allows for a 1 minute and 15 second window, preventing disconnections when the Odoo server experiences temporary slowdowns. This ensures smoother and more consistent video communication.
Original PR description
Before this commit, the ping to keep rtc sessions alive was done every 30 seconds and had a 1 minute timeframe to successfully ping, which meant that missing a single ping would drop the rtc session. This commit increases the timeframe to 1 minutes and 15 seconds so that one ping can be missed. This can help preventing disconnections when the Odoo server is slow, as calls can work fine without a stable connection to the odoo server (since P2P and SFU connections are independent from Odoo once the connections are initialized). task-5177246 Forward-Port-Of: odoo/odoo#234553
This update resolves a bug where the system incorrectly used the default company when synchronizing bank accounts in companies other than the primary one. The fix ensures the correct company context is passed, preventing errors and improving data accuracy. This ensures all bank account synchronization processes function correctly regardless of the company being used.
Original PR description
This issue was caused by missing context propagation after a recent refactor: the bank account selection widget did not pass the active context to the callback, and the subsequent doActionButton call was executed without `allowed_company_ids` or `cids`. As a result, the backend environment was initialized with the default company instead of the currently active one. This commit restores the context chain by ensuring the bank account selection widget correctly forwards the context to the callback. To make this flow even safer, we now rely on the link's `company_id` when creating the journal, falling back to self.env.company only if the link has no defined company (shouldn't happen). While not ideal, this fallback provides reasonable protection as long as context propagation remains correct. Task ID: 5452455
This change corrects a technical issue in the Attendance Analysis reporting feature. The system was incorrectly using a monetary widget for cost-related fields, leading to a traceback. Removing this widget resolves the problem and ensures accurate reporting calculations.
Original PR description
### Steps to reproduce: - Navigate to Planning > Reporting > Planning / Attendance Analysis - From measure select Attendance Cost or Cost Difference or Planned Cost - A traceback will pop up ### Cause: We are using widget monetary for the three fields in the view while their field type is float and there is no currency field defined in the model ### Fix: Remove the monetary widget from the view In master we will do something like this commit https://github.com/odoo/enterprise/pull/99059/commits/17f05bef0dad3e9645b6e0ed8df14d3308440812 opw-5438221 Forward-Port-Of: odoo/enterprise#103067
This update resolves an issue where filtering a Kanban view would lose its settings after reopening a record. The fix ensures that filtered views remain active and accurately reflect changes made within the Kanban, improving user workflow and data consistency. It addresses a bug related to cached data and group filtering.
Original PR description
Have a kanban view with progressbar and some records. Click on a progressbar to filter a column. Then open a record and come back. From that point, the data of the filtered kanban is in cache. Now,…
Have a kanban view with progressbar and some records. Click on a progressbar to filter a column. Then open a record and come back. From that point, the data of the filtered kanban is in cache. Now, open a record again, and make a change in the form that will have an impact in the kanban (e.g. that will move a record from a column to another). Come back to the kanban view, which will instantly show the data from the cache, and that will be then updated once the rpc returns. At that point, the view is still correct, but the cache callback has already erased the groups information (in particular, the extraDomain of the filtered column). So, if you open a record and come back a last time, the view is no longer correct: the column that is supposed to be filtered displays all records. Introduced by [1] This commit basically reverts [1] and fixes the original issue differently. When we receive the result of a web_read_group, we can trust it and determine that a group for which we receive records (or groups) is open. [1] https://github.com/odoo/odoo/pull/226312 Task~5387553 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#240593
This update resolves a memory error that occurred when processing recurring invoices with a large number of subscriptions. By optimizing how the system retrieves data, the change significantly reduces memory consumption, improving the stability and performance of the invoicing process. This prevents potential system slowdowns and errors.
Original PR description
A MemoryError can be thrown when running the scheduled action `_cron_recurring_create_invoice` on large databases. When there are lots of subscriptions, sale.orders and account.move.lines, the…
A MemoryError can be thrown when running the scheduled action `_cron_recurring_create_invoice` on large databases. When there are lots of subscriptions, sale.orders and account.move.lines, the compute method overwrite `_get_invoiced` in the sale_subscription module can consume a lot of memory. The issue is mostly coming from the search on account.move.line. In case a lot of account.move.lines have a subscription_id, the search to get `all_subscription_ids` is going to return a lot of records. Then, accessing any field on this recordset will prefetch all the prefetchable fields, leading to a MemoryError. This commit fixes that by manually fetching the fields we need on account_move_line. Since `subscription_move_lines` is not used anywhere else and `move_by_origin` only contains ids, the number of queries stays the same while the memory consumption plummets. #### Benchmark In a database with 236 000 account.move.line with a non-null subscription_id, running the schedule action with 5 subscriptions to invoice consumes at least 1.7GB (MemoryError raised). After this commit it consumes 191MB. <img width="1918" height="943" alt="sale_subscription_before" src="https://github.com/user-attachments/assets/e868921f-e691-47c3-8474-edb9a1d22d0b" /> <img width="1920" height="949" alt="sale_subscription_after" src="https://github.com/user-attachments/assets/78e9fc31-4c5f-4369-8bd0-494ca2c693fd" /> Forward-Port-Of: odoo/enterprise#102364
This update resolves a technical issue that prevented users from correctly selecting kanban records when navigating with the keyboard (specifically, using `shift+space`). The fix ensures that the kanban record is now selected as expected, improving the user experience within the Odoo interface. This change was made to ensure smooth and reliable navigation.
Original PR description
Before this commit: When navigating the kanban view using the keyboard, pressing `shift+space` for the first time to select a kanban record caused a traceback. After this commit: The traceback no longer occurs, and the kanban record is correctly selected. task-5410164 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240389
This update fixes an issue where resizing images within website pages broke responsiveness on smaller screens (like mobile). The change ensures images adapt correctly to different display sizes by using percentage-based widths and automatic height adjustments, maintaining image quality across devices.
Original PR description
Problem: On website pages, resizing an image using the transform option breaks responsiveness across display sizes. After resizing on desktop, the image may overflow its container on smaller screens. Cause: The resize logic currently sets both width and height in `px`. Once fixed in pixels on a large screen, the image no longer adapts when the responsive container becomes smaller on mobile. Solution: Use a percentage value for `width` and set `height` to `auto`. This preserves responsiveness while keeping the aspect ratio correct. Using `height: auto` is required because setting both width and height in percentages would still ignore height in practice. Steps to reproduce: - Add a card snippet to a website page. - Resize the image. - Switch the display mode to mobile. - Observe that the image is no longer responsive. opw-5368040 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241416
This update fixes a problem where incorrect error messages were displayed when creating employees with negative fixed allowance values. The fix isolates error handling to payroll validation, ensuring users receive the precise error message needed to correct the issue. This improves data accuracy and simplifies the employee onboarding process.
Original PR description
Issue: * When creating an employee with negative fixed allowance values, the system should show a payroll validation error. * Instead, a leave-related error from hr_holidays always appeared because the module wrapped the entire create() method in a broad try/except, catching all ValidationError messages including those from payroll. Fix: * Restricted the try/except only to the part that actually creates a new leave entries. Impact: * Users now see the correct and relevant error message when the fixed allowance values are invalid. task-5383700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238984
This update resolves an issue where changing a blog author's contact information would incorrectly update their avatar in the website builder. The fix ensures that avatar updates are handled properly, maintaining accurate display across the blog post pages. This improves the visual consistency and accuracy of author information for website visitors.
Original PR description
With the [website builder refactor], the avatar of the author of a blog post is updated when the author is changed. But with the [replication of fields] in the builder, if the avatar is present several times on the page with different options, the replication would overwrite some instances with the options of another. This commit avoids the avatar field from getting replicated by updating the avatar of mutated fields in a `normalize_handlers`. Steps to reproduce: - Open website builder on a blog post - Enable the "Sidebar" - Enable the "Author" in the sidebar - Click on the name of the author in the page (any of the 2 instances) - Change the "Contact" associated with the author of the post - Bug: the avatar in the sidebar is now small and round like the other [website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 [replication of fields]: 7d7d6df5aaff52f740a54fe5234f0f778e3d4905 Forward-Port-Of: odoo/odoo#240933 Forward-Port-Of: odoo/odoo#234985
This update fixes an issue where the chat hub's hidden menu appeared too light in dark theme, impacting readability. The change reverts to a darker background style, enhancing accessibility and the visibility of key elements like the close button. This ensures a better user experience for all users, especially those using dark mode.
Original PR description
In dark theme, the chat bubble message previews have dark background for improved readability of text. The chat hub hidden menu was intended to use same color scheme, but this was mistakenly removed from style improvements to discuss. The default style of popover is too light in dark theme. This commit reverts to style before 19.0, using darker background. This improves accessibility of item selection and the "x" button. Before / After <img width="278" height="405" alt="Screenshot 2026-01-05 at 18 05 18" src="https://github.com/user-attachments/assets/d764adbf-5378-4d59-870d-baf159920898" /> <img width="288" height="410" alt="Screenshot 2026-01-05 at 18 31 03" src="https://github.com/user-attachments/assets/142605cf-fab6-499d-95fa-71fcbb7ec36a" /> Forward-Port-Of: odoo/odoo#242094
This update fixes an issue where the version timeline in the HR module would disappear when zoomed out and introduce a scrollbar when zoomed in. The fix ensures all versions are visible regardless of zoom level, providing a cleaner and more intuitive user experience for managing versions.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: . When you zoom-out below 100%, the other versions from the version bar disappear, leaving only the active one . Wen zoom-in, a side vertical scrollbar appear Desired behavior after PR is merged: . all versions on timeline appears normally without sides scrollbar task-5401380 Forward-Port-Of: odoo/odoo#239315
This update quietly resolves a warning message that occasionally appeared during Odoo startup. The warning was related to an imported library and didn't impact functionality, but was causing tracebacks in the logs. This change improves the stability and clarity of Odoo's startup process.
Original PR description
Importing `PyKCS11` was raising the following warning: ``` py.warnings: <frozen importlib._bootstrap>:488: DeprecationWarning: builtin type SwigPyObject has no __module__ attribute ``` It doesn't cause any issue, but adds two tracebacks in the logs on Odoo startup. This commit simply hides the warning.
This update ensures that the bill date field is now mandatory when creating or editing invoices. Previously, users could skip this important field, leading to potential data inconsistencies. Requiring the bill date improves data accuracy and helps ensure proper accounting record-keeping.
Original PR description
Make bill date required on form view to display a 'Missing required field' notification when not set. task-5361931 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238911
This update fixes an issue where newly created buttons in the Odoo form editor weren't correctly focused or displayed. The fix ensures the sidebar shows the button's properties immediately after creation, providing a smoother user experience. This improves usability for users building custom forms.
Original PR description
Have an arch with many conditional button in the header Click on Add a button in the form editor. Before this commit, the new button was not correctly focused and the sidebar did not display the properties of the new button. This was because we gave the wrong xpath coordinates to focus to the editor. After this commit, this flow works as expected task-5364798 Forward-Port-Of: odoo/enterprise#102380 Forward-Port-Of: odoo/enterprise#101059
This update resolves an issue preventing users from editing the 'test_type_id' field within quality checks when adding steps in the Shop Floor module. This change ensures users can accurately configure quality checks, improving workflow efficiency and data accuracy. It's a minor fix impacting the MRP Work Order and Quality modules.
Original PR description
This commit fixes the problem where the `test_type_id` of the `quality_check` is readonly when adding a step in Shop Floor. Task-5404503 Forward-Port-Of: odoo/enterprise#102810
This update resolves an issue where a website tour feature timed out during testing, specifically when searching for products. The fix ensures the tour waits for the dropdown to populate before initiating a search, preventing unnecessary clicks and ensuring a smoother user experience. The `searchNeeded` parameter has also been removed for simplification.
Original PR description
__Behavior before commit:__ When `searchNeeded` is `true`, `changeOptionInPopover` adds a step to search the option in the dropdown. This step is not working if the dropdown is not ready. This causes `add_to_cart_snippet_tour` to timeout when the tests are run with demo data because the products created in the python side of the test are not showing directly. If the demo data are not included and `searchNeeded` is `true`, it is useless to search. Furthermore in this case, it might click on the item before the search request is finished. The popover will then be kept open when the request end (without result because the search will exclude the already selected item). __Fix:__ - Wait for the dropdown to be ready by waiting for the items to appear in the dropwdown. Then only make the search if the item isn't already in the list. - Remove the now useless `searchNeeded` parameter runbot-234680 Forward-Port-Of: odoo/odoo#240193
This update fixes an issue where child manufacturing orders weren't correctly updating quantities when the parent order was modified. The change ensures that all quantities are converted to the same UoM (product's UoM) during calculations, preventing incorrect quantity adjustments in child MOs. This improves the accuracy of production planning.
Original PR description
Problem: When a manufactured product uses a component whose UoM is different from its reference UoM, for example the component’s UoM is dozens but units are used on the BoM line, updating the…
Problem: When a manufactured product uses a component whose UoM is different from its reference UoM, for example the component’s UoM is dozens but units are used on the BoM line, updating the quantity to produce on the parent MO causes the child MO’s quantity to roduce to update incorrectly. This is because the new quantity to produce on the child MO is calculated with quantities in different UoMs. Purpose: To ensure that the child MO’s quantity to produce updates correctly when the parent MO’s quantity to produce is updated. This is achieved by making sure the quantities that get added together are both the same UoM, in this case the product’s UoM. Steps to Reproduce on Runbot: 1. Create product_a with the MTO route and UoM set to pack of 6. 2. Create a BoM for product_a that creates 1 pack of 6 products. 3. Create product_b. 4. Create a BoM for product_b that creates 1 unit and uses 3 units of product_a. Make sure the component line shows 3 units instead of 0.5 pack of 6. 5. Create a manufacturing order for 1 unit of product_b and confirm it. 6. There should be a child MO for 0.5 pack of 6 of product_a. 7. On the parent MO update the production quantity to 2 units. 8. Observe that the child MO is now for 3.5 pack of 6 instead of 1 pack of 6. opw-5414085 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241692
This update resolves a bug that caused Odoo to crash when a user's session data (specifically, the 'persona' information) was missing. The fix ensures Odoo gracefully handles this situation, improving stability and preventing disruptions for users. This change primarily impacts the email functionality within Odoo.
Original PR description
<img width="889" height="290" alt="image" src="https://github.com/user-attachments/assets/c2519e22-f7c4-4d53-885d-01674b248260" /> Forward-Port-Of: odoo/odoo#242060
This update fixes inaccuracies in the VAT report formulas used in the Lithuanian (l10n_lt) localization. The changes ensure more accurate VAT calculations and reporting, improving the reliability of financial data within Odoo.
Original PR description
With this PR, some wrong formulas in VAT report will be updated. task-5447677 Forward-Port-Of: odoo/odoo#241802
This update resolves an issue where attachments weren't consistently displayed on leave request forms after saving. The fix addresses a technical limitation in how Odoo handles attachments linked to leave requests, ensuring that attachments are correctly reflected when the form is reloaded or viewed. This improves the user experience for creating and managing leave requests.
Original PR description
to reproduce: ============= - from form view, create a leave request with an attachment - save the leave request - the attachment is not displayed on the form (reloading the page shows it correctly)…
to reproduce:
=============
- from form view, create a leave request with an attachment
- save the leave request
- the attachment is not displayed on the form (reloading the page shows it correctly)
Problem:
========
- When sving the leave request, we call `web_save` which will handle the creation, then calls `web_read` to read the updated data back from the server.
- Even though `web_read` and `web_save` are called in the same transaction, but `web_read` doesn't see `attachment_ids` because of the limited implementation of Many2oneReference (ir.attachment.res_id):
- Its `_update_inverses` won't be called when the value is changed when `field.write`
- when `record.attachment_ids = attachment`, the ORM won't automatically set `attachment.res_model = record._name`
Solution:
=========
as work arround, we can call `invalidate_recordset` for leave requests after setting `attachment_ids` in `_inverse_supported_attachment_ids` so that `web_read` will read the correct value from database.
opw-5157790
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#233003