Daily updates from Odoo
Tuesday, January 6, 2026
74 changes · 19.0
Enhancements to existing features
This PR updates the Odoo accounting module to allow for the translation of the 'Pay Now' label, improving localization for users in different languages. This ensures consistent and accurate display of this key payment label across all Odoo environments.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update streamlines the Fiskaly setup process for Odoo Enterprise users in Austria. The changes include automatic credential authentication attempts, a simplified user interface with clearer guidance, and automated configuration of Fiskaly settings. This improves usability and ensures correct Fiskaly integration.
Original PR description
Task: [#5354476](https://www.odoo.com/odoo/project/1737/tasks/5354476) --- The Fiskaly configuration for Austrian companies has been edited: - Generating new credentials will try to authenticate right after generating them. - The *Test Fiskaly* buttons is now only visible in debug mode. - The *Generate Credentials* button won't be visible if the authentication has been successful except if the user is in debug mode. - The *Authenticate Keys* button is only available when the authentication has failed. - The *Manage by Odoo* checkbox has been removed and we force its value to True when generating new credentials. - An alert is displayed to guide the user depending on the state of the Fiskaly configuration (not authenticated, must regenerate credentials, etc).
This update enhances the organization of our internal JavaScript code by making key utility functions and constants available for import across Odoo modules. This change improves code maintainability and allows for greater flexibility in how these tools are utilized within the Enterprise platform. It's a foundational improvement for future development.
Original PR description
This commit puts export in front of some of the blackbox js utils/services/constants to make them importable from other files in the future. Forward-Port-Of: odoo/enterprise#99445 Forward-Port-Of: odoo/enterprise#99391
This update automatically sends email notifications to applicants when a recruiter declines their application, provided a pre-defined email template is available for that refusal reason. This streamlines the recruitment process by ensuring timely communication and improves the applicant experience. It also defaults to using the appropriate email template for each refusal.
Original PR description
In this commit, we make the toggle button "Send Email" enabled by default whenever the refusal reason has an email template, including the reason selected by default in the wizard. TaskID: 5245023 Forward-Port-Of: odoo/odoo#234759
This update enhances the visibility of VAT return status, alerting users immediately when a file is rejected by tax authorities. Previously, errors were only logged in the chatter, making it difficult for users to quickly identify and address issues. Now, return statuses will display color-coded alerts, providing a clear visual indication of any problems.
Original PR description
Many localisations require some returns (mainly: VAT return) to be sent by API to tax authorities. It frequently happens that the file is rejected by the authorities for xyz reasons. In that case, the response is logged in the return chatter but we should make the failure visual so users directly know that an issue occurred. For that, we'll allow the states widget to be colorful. Now localisation can add custom error messages and alert types and the widget will be colored accordingly and the error message will appear on hover. `task: 5365547`
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 an employee can still accrue more vacation time before the leave date. This ensures accurate tracking of available leave balances.
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 resolves a warning related to employee compensation calculations within the US payroll module. The team has corrected a formula to accurately identify employees without worker compensation, ensuring payroll reports are reliable. This change was part of a larger refactoring effort and is a minor fix.
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 users couldn't navigate up and down using the keyboard when inserting stars within the HTML editor. The fix ensures proper cursor placement, allowing for seamless navigation and a better 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
This update resolves a technical issue that caused a 'singleton' error when marking tasks as complete in Field Service. The fix ensures that timesheets are correctly linked to the first applicable sale order line when multiple options exist, preventing errors and ensuring accurate timesheet recording. This improves the reliability of the Field Service workflow.
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 an issue where the DIN5008 invoice report wasn't showing Incoterm information. The change adds the necessary logic to include Incoterm codes and locations on this specific invoice layout, ensuring compliance with reporting requirements. This improves the accuracy of invoices generated using the DIN5008 template.
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 fixes a visual issue in Odoo's Chatter where attachments and emoji reactions appeared too close together, creating a cluttered and difficult-to-read message view. The change adds spacing to ensure a cleaner, more professional appearance for all messages, regardless of whether they contain attachments.
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 a technical issue that caused a traceback to appear after canceling an order with a default preset (like 'Takeout or Delivery') in the restaurant POS. The fix redirects the user to the correct screen and prevents a new order from being created, ensuring a smoother order cancellation process.
Original PR description
### step to reproduce: - Set default preset to "Takeout or Delivery" in restaurant config. - Open restaurant . - Open any table and add a product. - Cancel the order using the action button. ### issue: - A popup appears asking to select a partner/floating order name, followed by a traceback. ### cause: - Traceback occures as next screen is loaded after order deletion. ### fix: - Redirect to the default screen before deleting the order. - Ensure that no new order is created when the next screen is the floor screen. task: 5092951 Forward-Port-Of: odoo/odoo#237885 Forward-Port-Of: odoo/odoo#227925
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 now consistently reflect the selected theme colors, providing a more visually consistent 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 fixes an issue where the UBL XML generated for invoices was incorrectly including the 'Invoice address' suffix in the partner name. The change ensures that the commercial partner's name is used, aligning with standard Odoo XML generation and improving the accuracy of invoices.
Original PR description
The dict-to-xml helpers were still using `partner.display_name` which includes the 'Invoice address' suffix. Changed to use `partner.commercial_partner_id.display_name` when partner name is not available, to match the fix in https://github.com/odoo/odoo/pull/232819 for the standard XML generation. task-4614564 Forward-Port-Of: odoo/odoo#241985 Forward-Port-Of: odoo/odoo#241250
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 reduces potential confusion among users.
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 reporting issue in the French P&L reports. The 'owner remuneration' account (644) was incorrectly categorized as 'tax and duties'. This change ensures accurate reporting of wages and salaries in accordance with French 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 fixes a visual bug where the search panel in the hierarchy view was getting clipped when navigating deep within the organization structure. The fix ensures the hierarchy content scrolls correctly, maintaining the position of the search and control panels. This improves the user experience for navigating complex hierarchies.
Original PR description
Issue: The hierarchy renderer was missing the standard .o_renderer class, so global layout and scrolling rules were not applied. Fix: Add .o_renderer on the hierarchy renderer root a to correct scrollable container. Impact: Restores expected scrolling behavior in hierarchy view Task: 5326054 Forward-Port-Of: odoo/odoo#236823
This update fixes a visual issue on the user profile page where course tags were being cut off at the bottom. The change adjusts the layout to ensure all tags are fully visible, maintaining a consistent and professional appearance. This improves the user experience by preventing content truncation.
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 resolves an issue where color fields within editable lists weren't saving changes when using the 'bottom' editing mode. Previously, edits to color fields were lost. Now, color field changes are reliably saved when using the standard 'bottom' editing experience, ensuring data accuracy and a consistent user experience.
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 clarifies delivery slip reports by explicitly labeling the delivery address as 'Delivery Address' and simplifying customer information labels. These changes reduce potential errors and improve the accuracy of delivery information, leading to smoother operations.
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 resolves a bug where changing a blog post author's contact information would incorrectly update the associated avatar in the website builder. The fix ensures the avatar remains consistent and correctly displays, addressing a visual inconsistency within the blog post editor.
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 (and avoids the weird removal of `o_dirty`) by updating the avatar of mutated fields in a `normalize_handlers`. Steps to reproduce: - Open website builder on a blog post - Enable the "Sidebar" - Enable the "Author" in the sidebar - Click on the name of the author in the page (any of the 2 instances) - Change the "Contact" associated with the author of the post - Bug: the avatar in the sidebar is now small and round like the other [website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 [replication of fields]: 7d7d6df5aaff52f740a54fe5234f0f778e3d4905 Forward-Port-Of: odoo/odoo#234985
A recent update unintentionally removed the ability to sort sale order lines. This fix corrects a technical issue caused by a previous change that prevented sorting. Users can now properly sort their sale order lines, improving order management efficiency.
Original PR description
#### Versions: 19.0+ ### Issue: Sale order line rendered is not sortable anymore like it was in previous versions. #### Steps to reproduce: 1- Create a sale order. 2- Add multiple sale lines. 3- As you see sale lines are not sortable. ### Cause: This is done due to #219253, which has overridden `isSortable` to return `False` on `SectionAndNoteListRenderer`. `SectionAndNoteListRenderer` is a superclass of `SaleOrderLineListRenderer`, which causes it not to be sortable. opw-5407880
This update resolves an issue where filtering a Kanban view with progress bars would lose its state after reopening a related record. The fix ensures that filtered views remain accurate, even after navigating to and from records, maintaining data consistency and a better user experience. This prevents unexpected behavior when updating Kanban records.
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
This update fixes a bug in the payroll calculation for Belgium (l10n_be_hr_payroll) that prevented the correct calculation of commission losses during specific contract end scenarios and public holidays. The fix ensures that the correct commission loss logic is executed, leading to accurate payroll processing.
Original PR description
When we enter in the conditions regarding the the end of a contract and the public holidays, it return and does not enter in the part of the code that handle the loss of commission on public holidays. So instead of returning the res, we just continue to the next condition.
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 addresses a previously reported restriction.
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
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 situations where this data isn't available, improving stability and preventing disruptions to user workflows. This change primarily impacts the email and communication features within Odoo.
Original PR description
<img width="889" height="290" alt="image" src="https://github.com/user-attachments/assets/c2519e22-f7c4-4d53-885d-01674b248260" />
This update resolves an issue where product amounts remained at zero after removing optional lines from a Sales Order. The fix ensures that when optional lines are unset, the product quantities and prices are correctly restored, preventing inaccurate order totals. This improves the reliability of sales order calculations.
Original PR description
**Steps to produce:** - Install the `Sales` module. - Create a Sales Order. - Add a section and some products under it. - In the section menu (three dots), click Set Optional. - Again, open the…
**Steps to produce:** - Install the `Sales` module. - Create a Sales Order. - Add a section and some products under it. - In the section menu (three dots), click Set Optional. - Again, open the section menu and click Unset Optional. **Issue:** - After unsetting the optional, the product amounts remain `0`. **Root cause:** - At[1], when setting options, both quantity and price are reset to `0`. - When unsetting optional, only the quantity is restored, leaving the price at `0`. **Solution:** - When unsetting optional, explicitly trigger the onchange on the field `product_uom_qty` using `.update()`. [1]https://github.com/odoo/odoo/blob/27cd0a3fea1b47a85a4f3d397b052bbec08e182b/addons/sale_management/static/src/fields/sale_order_line_field/sale_order_line_field.js#L138-L140 Before: <img width="1198" height="476" alt="image" src="https://github.com/user-attachments/assets/01dee1d6-2870-4222-8a6c-724fbfff8da1" /> After: <img width="1214" height="453" alt="image" src="https://github.com/user-attachments/assets/63ed4eb4-27cf-4b15-a957-c28a46a3ca42" /> opw-5368488 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a bug that prevented users from exporting data from the MRP MPS view. The issue stemmed from a recent change that incorrectly pulled fields from a related model. Now, exporting data from the MPS view functions correctly, ensuring accurate data export for forecasting.
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 resolves a minor issue impacting the accuracy of account reports within the MRP module. The changes include re-enabling tests for related modules, ensuring the continued reliability of financial reporting and calculations. This improves the overall stability of the enterprise version.
This update fixes a bug where resizing images within website pages broke responsiveness on smaller screens (like mobile). The change ensures images adapt correctly to different display sizes, preventing overflow and maintaining a consistent user experience across devices. This improves the visual quality and usability of our website content.
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
This update resolves an issue where pressing 'shift+space' in the kanban view initially caused a system error. Now, users can reliably select kanban records using this keyboard shortcut, improving usability and workflow efficiency.
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
This update resolves a critical issue in the l10n_gt_edi module by implementing a 'neutralization' process. This ensures that database copies created for support investigations won't unintentionally impact the live production database or customer data. It allows for safer troubleshooting and duplicate database analysis.
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 resolves an issue where zooming out on the version timeline caused other versions to disappear. It also addressed the appearance of a vertical scrollbar when zooming in. The fix ensures all versions are visible and scrollable without a sidebar, providing a smoother user experience.
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
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 related to their allowance data. 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
This update corrects inconsistencies in how stock valuation is calculated, particularly related to manufacturing and subcontracting processes. Specifically, it re-enabled tests for stock valuation in manufacturing, ensuring accurate accounting for finished goods and resolving issues with incorrect value computations. This improves the reliability of financial reporting.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where Odoo incorrectly processed partner names with only one word. Previously, single-word names resulted in an empty first name field. Now, single-word names are correctly assigned to the first name, ensuring accurate data entry and reporting for customer information.
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 one-day time off requests were incorrectly displayed as multi-day events in the Calendar app. The fix ensures that single-day leaves are accurately represented, resolving a visual inconsistency for users in specific time zones like Los Angeles. This improves the accuracy of employee schedules.
Original PR description
**Issue:** Single-day time off requests appear as multi-day events in the Calendar app when using certain tim> **Cause:** The `_compute_date_from_to()` method converts user-specified dates to UTC.…
**Issue:** Single-day time off requests appear as multi-day events in the Calendar app when using certain tim> **Cause:** The `_compute_date_from_to()` method converts user-specified dates to UTC. https://github.com/odoo/odoo/blob/028e7228cb830e47a9726bef4c82793ba4590cd5/addons/hr_holidays/models/hr_leave.py#L316-L317 The `_prepare_holidays_meeting_values()` method then uses these UTC datetime values (`holiday.date_from`, `holiday.date_to`) In Los Angeles timezone, and for a one day leave on september 17 2025 this leads to: - holiday.date_from: September 17, 2025 at 03:00 UTC - holiday.date_to: September 18, 2025 at 12:00 UTC causing a single-day leave to be displayed as a two-day event. **After fix:** - start_value: September 17, 2025 at 12:00 - stop_value: September 17, 2025 at 11:59 **Steps to Reproduce:** 1. Set the user timezone to "America/Los_Angeles" 2. Set the browser timezone to the same timezone 3. Create a one-day time off request (e.g., September 17, 2025) 4. Open the Calendar app: the event spans across two days opw-4744817 Forward-Port-Of: odoo/odoo#231662 Forward-Port-Of: odoo/odoo#224298
This update resolves errors identified during testing of the l10n_hr_edi module's flow processes, ensuring consistent functionality with the Odoo 19.0 release. It also corrects a specific SQL query issue, improving the stability and reliability of the HR EDI integration.
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 fixes a potential issue where printing errors on Windows could cause unexpected problems. By adding a safety net to catch these errors, the system is now more stable and reliable when printing, particularly on Windows devices. This ensures a smoother user experience for printing operations.
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 an issue where file attachments added to Odoo activities (like project tasks) weren't visible after saving. The fix ensures attachments are correctly displayed with download links in the activity chatter, improving usability and allowing users to access attached files seamlessly.
Original PR description
**Description of the issue/feature this PR addresses:** In Odoo 19, file attachments added to activities (for example, on Project Tasks) were not visible after saving the activity. Although the…
**Description of the issue/feature this PR addresses:** In Odoo 19, file attachments added to activities (for example, on Project Tasks) were not visible after saving the activity. Although the attachment was correctly stored, it was not rendered in the activity chatter. The root cause was that the activity note containing the embedded attachment placeholder `(<span data-embedded="file">) `was rendered as raw HTML, bypassing the HtmlViewer logic that mounts embedded file components. As a result, the attachment card and download link were missing from the UI. **Current behavior before PR:** Attachments can be added to an activity and are saved correctly. After saving the activity: * The attachment card is not displayed. * No download link appears in the activity chatter. * The activity note is rendered as raw HTML, so embedded file components are never mounted. **Desired behavior after PR is merged:** * Attachments added to activities are correctly displayed after saving. * The attachment card and download link appear in the activity chatter. * Activity notes are rendered using the HtmlViewer component, ensuring embedded files are properly mounted and displayed. **Related issue** Closes #238967 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adjusts how stock replenishment orders are created to align more closely with delivery dates. Previously, replenishment orders weren't automatically scheduled to match delivery timelines, leading to potential storage inefficiencies. Now, the system uses the product's 'deadline date' for replenishment orders created from deliveries, optimizing inventory management.
Original PR description
Issue ----- When creating a sale for a future date, the purchase of the product is not created for (sale date) - (vendor lead time). More generally, RR procurements are not created to be as close to…
Issue ----- When creating a sale for a future date, the purchase of the product is not created for (sale date) - (vendor lead time). More generally, RR procurements are not created to be as close to the delivery date as possible. Steps to reproduce ----- - Create a product with a reordering rule - Create a delivery - Scheduled Date: 31/12/2025 - Mark as Todo - Open the created incoming picking > The IN picking's scheduled date should be 31/12/2025 (no lead time) Cause ----- The IN is created using the date of the procurement, which is created in https://github.com/odoo/odoo/blob/4f5594a911c1960f620d902d507e563cdab167b9/addons/stock/models/stock_orderpoint.py#L732-L741 While it makes sense for scheduled replenishments to use the `lead_horizon_date` returned by `_get_orderpoint_procurement_date` https://github.com/odoo/odoo/blob/4f5594a911c1960f620d902d507e563cdab167b9/addons/stock/models/stock_orderpoint.py#L793-L794 For procurements created by a delivery, we want to push the IN date to as close to the delivery date as possible to minimize storage costs. Solution ----- Procurements created by replenishments are created by `action_replenish` https://github.com/odoo/odoo/blob/4f5594a911c1960f620d902d507e563cdab167b9/addons/stock/models/stock_orderpoint.py#L342-L348 (same goes for automatic ones) https://github.com/odoo/odoo/blob/4f5594a911c1960f620d902d507e563cdab167b9/addons/stock/models/stock_orderpoint.py#L368-L370 However, when we plan the delivery, we go through SM's `trigger_scheduler` https://github.com/odoo/odoo/blob/4f5594a911c1960f620d902d507e563cdab167b9/addons/stock/models/stock_move.py#L2411 This means we can give a context key to the `_procure_orderpoint_confirm` call to indicate that we want to use the orderpoint's `deadline_date` (which was introduced by 71adec9). https://github.com/odoo/odoo/blob/4f5594a911c1960f620d902d507e563cdab167b9/addons/stock/models/stock_orderpoint.py#L95-L99 ----- Ticket: opw-5223991
This update ensures that feedback entered by employees and managers on appraisals is retained when the appraisal is reopened. Previously, changes were lost, requiring users to re-enter their feedback. This fix maintains data integrity and streamlines the appraisal process.
Original PR description
Steps to reproduce: ---------------------------- 1. Install `hr_appraisal` module. 2. Go to Appraisals and open any new appraisal 3. Change or add text in Employee's feedback and Manager's Feedback…
Steps to reproduce: ---------------------------- 1. Install `hr_appraisal` module. 2. Go to Appraisals and open any new appraisal 3. Change or add text in Employee's feedback and Manager's Feedback 4. Confirm the appraisal 5. Give it a Final Rating and click Mark as Done 6. Click the Reopen button Observation: ---------------------------- The changes made to the feedback fields are lost after reopening the appraisal, feedback reverts to the template values. Issue: ---------------------------- In the feedback compute methods, the code was unconditionally assigning the appraisal template when the appraisal was in the new state. https://github.com/odoo/enterprise/blob/036002fa6415c796a9b73efa5ea85c582fafb7c6/hr_appraisal/models/hr_appraisal.py#L171-L187 Solution: ---------------------------- Preserve existing feedback when reopening an appraisal: When an appraisal is reopened, any feedback already entered by the Employee or Manager should remain unchanged. Reset feedback only when the Manager resets the appraisal: If the appraisal is in the Pending stage and the Manager chooses to reset it, then the feedbacks should be restored to the default template values. opw-5404776
This update corrects a problem where new offers created from partially signed applicant forms didn't automatically include the salary configuration template. The fix ensures the correct sign template is applied, preventing users from accessing the necessary salary settings when creating these offers. This improves the applicant experience and ensures accurate offer creation.
Original PR description
steps to reproduce: - an applicant have signed with a company car + a car to order - go to Recruitment < Offers < Partially signed < Find the applicant - click on Contract Details to access the version - create a new offer through the smart button - the offer doesn't have a sign template so the salary configurator is not accessible Fix: use `sign_template_id` instead of `contract_update_template_id` as the sign template of the offer if the version is not active (because it is created from an offer which is half signed and it's basically a new offer not an offer for contract update) task-id: 5401539
This update fixes an issue where updating the quantity of a parent manufacturing order incorrectly affected the quantity of related child manufacturing orders. The change ensures that quantities are consistently calculated in the product's standard UoM, leading to accurate updates across all manufacturing orders. This improves the reliability 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
This update corrects inaccuracies in the VAT report formulas used by the l10n_lt (Lithuania) localization module. 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
This update resolves an issue where the 'Add to Cart' tour wasn't functioning correctly with demo data, specifically when searching for products. The fix ensures the tour waits for the dropdown to populate before initiating a search, preventing timeouts and incorrect popover behavior. This improves the user experience during testing and ensures the tour works reliably.
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
This update resolves an issue where deleting a payroll rule section linked to an active contract or payslip would render the rule unusable. The change prevents deletion of these sections, ensuring payroll rules remain functional and accurate. This avoids disruption to payroll processing.
Original PR description
### Steps to Reproduce 1. Create a Salary Rule Section. 2. Link it to a Salary Rule and add it to a contract or payslip. 3. Delete the Rule Section. 4. Go back to the Salary Rule. 5. The section field is invalid/readonly, making it impossible to assign a new section or fix the rule. ### Reason Deleting a section linked to a Salary Rule breaks the link without clearing it, leaving the rule in a broken, unusable state. ### Solution Prevent the deletion of Salary Rule Sections if they are linked to a Rule that is actively used as an input in a contract or payslip. Task: 5390387
This update corrects a bug where reimbursement amounts for public transport weren't resetting to zero when the benefit was unchecked in the salary configurator. The fix ensures that the amount field accurately reflects the current benefit status, improving data accuracy and reducing potential errors in payroll calculations. This impacts employee compensation reporting.
Original PR description
Issue: public and train transport reimbursed amounts not reseting after unchecking them Steps to reproduce: - open salary configurator - check public(train) transportation - change the value in the input field - uncheck public(train) transportation - the value for the reimbursed amount doesn't reset to 0 Fix: - made the value reset for public and train transport to 0 in the ui of the configurator - made the employee amount reset to 0 in the employee form if the benefit is unchecked task-id: 5386766
This update corrects a visual issue where resizing images within the HTML editor caused a distracting flicker. The problem stemmed from inconsistent mouse coordinate tracking between the iframe and the main window. This fix ensures smoother image resizing and a better user experience.
Original PR description
Problem: After 3b28df9eb22a3eb9af129a7f756986f54b983fc3, resizing an image during transform causes a visible flicker. Cause: The same mousemove handler is attached to listeners on both the iframe and the window. When the mouse moves from the iframe to the window, `ev.pageX` and `ev.pageY` differ between the two contexts, leading to incorrect position calculations and visual flickering. Solution: When `mousemove` is triggered, correctly recompute `pageX` and `pageY` when transitioning between iframe and window contexts, ensuring consistent coordinates during resize. Steps to reproduce: - Open website/jobs. - Try to transform and resize the image on the right. - Observe a flicker while resizing. opw-5368040 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that the bill date is always required when creating invoices. Previously, users could skip this field, leading to potential data inconsistencies. Now, a clear notification will appear if the bill date isn't provided, helping ensure accurate record-keeping and reporting.
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
This update addresses a critical issue in the l10n_tw_edi_ecpay tax module, adding a necessary 'neutralization' process. This ensures that support teams can safely examine database copies without risking disruptions to the live Odoo system or impacting customer data. It's a standard security practice to isolate testing environments.
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 a bug that prevented users from creating helpdesk tickets when helpdesk teams included members from different companies. The change prevents unnecessary access checks, ensuring ticket creation works correctly regardless of company affiliation. This improves the user experience and prevents errors related to resource access.
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 resolves an issue where Odoo invoices with discounts generated for Nemhandel invoices were failing validation. The fix ensures that discounts are correctly accounted for in the invoice data, allowing for proper transmission to the customer. This improves the reliability of invoice processing through the Nemhandel system.
Original PR description
Before this fix, all the OIOUBL invoices with a discount generated by Odoo would fail the schematron validation, meaning they can't be sent to the customer through Nemhandel. The schematron enforces that the discount is taken into account at the PriceAmount, to keep the rules on lineExtensionAmount working. Also changes the import to understand that it's a discount. opw-5379474 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241687 Forward-Port-Of: odoo/odoo#241614
This update corrects a flaw in how Odoo calculates the value of kits and components during purchase orders. Previously, the entire kit value was assigned to each component, regardless of proportions. Now, the valuation is accurately distributed based on component cost shares and kit proportions, ensuring correct inventory accounting for kit products.
Original PR description
## Issue 1: Purchasing a Kit and validating the receipt sets the value of the pol to all the exploded kit moves. It should rather explode that valuation by taking care of the defined and undefined…
## Issue 1: Purchasing a Kit and validating the receipt sets the value of the pol to all the exploded kit moves. It should rather explode that valuation by taking care of the defined and undefined cost_share as well as the kit proportions. ### Steps to reproduce: - Create a kit product with 2 bom lines: - 1 x COMP1, cost_share: 20% - 2 X COMP2, cost_share: 80% - Create and confirm a PO for 1 x your kit prodcut for 1000$ - Validate the receipt #### > Both moves are valued as 1000$ ## Issue 2: The cost_share of a bom corresponding to a given variant should sum up to 100% and the valuation of kit product via a purchase order should be distributed among its exploded moves. Currently, the constraint is that the sum of all cost_share's used on the bom sum up to 100%: https://github.com/odoo/odoo/blob/7038c786ff0da782dd1895f124c272d5617379fc/addons/purchase_mrp/models/mrp_bom.py#L12-L22 and if not all lines are used by a product variant it value will be lost in the process. ### Steps to reproduce: - Create a bom: - 1 X COMP1 cost share 50% - 1 X COMP2 cost_share 50% for White - 1 X COMP3 cost share 50% for Black #### > User error: The total cost share for a BoM's component have to be 100 opw-4806023
This update fixes an issue where discount values were calculated incorrectly when using promotion programs on specific products with tax included. The fix ensures that discounts are applied accurately to the product's base price, leading to more reliable and consistent pricing for loyalty programs. This improves the accuracy of promotions and rewards.
Original PR description
When using a promotion program applied only on specific products with tax included prices, the discount value was incorrect. Steps to reproduce: ------------------- * Create a product with a price of…
When using a promotion program applied only on specific products with tax included prices, the discount value was incorrect. Steps to reproduce: ------------------- * Create a product with a price of 100$ and tax of 10% included * Create a promotion program with: - Apply on: Specific Products (the product created above) - Discount Type: $ Fixed Discount - Discount Value: 10$ * Open PoS and add the product to the order * Apply the promotion code > Observation: The value of the discount is 9.09$ instead of 10$ The same steps also applies to the discount reward applied on the whole order. Why the fix: ------------ When computing the discountable amount for the promotion it would take the amount excluding tax instead of the base price. The base price should be the unit price of the product multiplied by the quantity. As it was before here : https://github.com/odoo/odoo/blob/8568baa35c9caa4c8cd3b1f5d737e1ecbec76434/addons/point_of_sale/static/src/app/models/pos_order_line.js#L470-L474 https://github.com/odoo/odoo/blob/8568baa35c9caa4c8cd3b1f5d737e1ecbec76434/addons/pos_loyalty/static/src/app/models/pos_order.js#L1112 To do so we modified the accounting helpers to provide this value instead of computing it manually. opw-[5260067](https://www.odoo.com/web#id=5260067&view_type=form&model=project.task) opw-[5242194](https://www.odoo.com/web#id=5242194&view_type=form&model=project.task)
This update fixes an issue where attachments added to chatter activities weren't correctly displayed as previews. The team has reverted a planned change to maintain the familiar attachment overview functionality in the chatter, ensuring users can easily see attached files. This improves usability and prevents a disruption to existing workflows.
Original PR description
--- ## Short functional explanation of the error When in the chatter, we can create an activity. If we add an attachment to the notes of this activity and save it, the overview of the attachment won't show in the chatter. ## Reproduction Steps 1. Open an app that gives you access to the chatter, for instance, an invoice in Accounting. 2. Click on Activity. Click on Log a Note... and on the button Upload a file. Upload an attachment and save. ### Expected behavior The overview of the file (blue box with the name of the attachment) should appear. ### Unexpected behavior The overview doesn't appear ## Origin of the issue Since 19.0, we want to replace static rendering with embedded components everywhere for rendering attachments, but this creates issues for the rendering of the overview in the chatter. Therefore, after internal discussion, we agreed to keep rendering overviews statically. opw-5356016
This update resolves several errors that were preventing the accurate generation of Peru-specific stock reports (PLE 12.1 and 13.1). The changes correct field names and API calls within the reporting module, ensuring reports now accurately reflect stock data for Peruvian businesses. This improves the reliability of financial reporting.
Original PR description
## Summary Fix multiple `AttributeError` exceptions when generating PLE 12.1 and 13.1 stock reports: - Use `unspsc_code_id` instead of `unspsc_code` (correct field name defined in `product_unspsc`) - Use `with_context(lang=)` instead of `with_lang()` (correct Odoo API) - Use `categ_id` instead of `category_id` (correct field name on `product.template` and `product.product`)
This update fixes a crash that occurred when opening the part-time salary simulation form with a specific URL parameter. The issue stemmed from an incorrect JavaScript element creation, leading to a faulty working schedule dropdown. This change ensures the simulation functions correctly for part-time employees, preventing disruptions to payroll processing.
Original PR description
Version: - 19.0 Steps to reproduce: - Open the salary package simulation form. - Add &part=True to the URL. Issue: - Opening the salary package simulation with `&part=True` in the URL caused a JavaScript error. - The working schedule dropdown was created incorrectly, leading to a crash. Fix: - Use ownerDocument.createElement to correctly create the wrapper element in JS. - Ensure new_calendar is always defined before accessing its id when preparing payslip values. task-5265734
This update ensures that IoT Box records are correctly updated during Odoo upgrades. Specifically, the system now requires the IoT Box to provide its MAC address alongside its serial number, allowing for a seamless transition from MAC-based to serial number-based identification. This resolves an issue where older IoT Box records wouldn't update properly after upgrading to newer Odoo versions.
Original PR description
When upgrading from <v19.0 to v19.0+, the IoT Box needs to provide its mac address along with its serial number in order for the IoT Box record in the db updates the identifier from mac to serial no. see odoo/enterprise#103331
This update ensures new Odoo versions correctly include VoIP admin and officer groups for improved functionality. The change prevents inconsistencies and simplifies future upgrades by enforcing a standard approach to VoIP rights management, reducing potential customization issues.
Original PR description
Commit [1] introduced new groups for VoIP: admin and officer. Before that, the related rights came with the base admin group of Odoo. With that in mind, it made the new groups implied by the base…
Commit [1] introduced new groups for VoIP: admin and officer. Before that, the related rights came with the base admin group of Odoo. With that in mind, it made the new groups implied by the base admin group, but put them in a noupdate area of the security XML file, meaning only new databases would get the new groups assigned to the admin group. There were two possibles solutions: - An upgrade script to add the new groups to admin users (and/or the fact it is implied by the admin group). - Move the group definitions to a non-noupdate area, which re-forces the fact the VoIP groups are implied by the admin group at each upgrade, to any Odoo version. There is no guideline about this in Odoo and it is left to a per-app per-group choice. After consultation, the second solution was chosen: we prefer to enforce the fact that each new VoIP codebase, each version, relies on the fact admins are supposed to have those VoIP rights; forcing any customization of that fact to re-check it is working at each Odoo upgrade (and/or make a proper customization with custom apps instead of user manipulation). [1]: https://github.com/odoo/enterprise/commit/88b8de95e1a28a8037a386fc8fb6a044a98217e7 task-5440305
This update fixes an issue where links to headings within locked articles didn't scroll to the correct location after loading. The fix ensures that all article links, regardless of whether the article is locked, function correctly and provide a seamless user experience for navigating to headings.
Original PR description
Problem: When navigating to a link that points to a heading in a locked article, the page does not scroll to the target heading after load. Cause: When an article is locked, `HtmlViewer` is used instead of the editor. In this mode, `HeadingLinkPlugin` is not loaded, even though it is the component responsible for scrolling to elements with `data-heading-link-id`. Solution: Add the same heading link scrolling logic to `HtmlViewer` so that links to headings work consistently, even when the article is locked. Steps to reproduce: - Go to Knowledge. - Copy a heading link. - Lock the article. - Paste the URL in the browser. - When the page loads, it does not scroll to the heading. opw-5418474 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240174
This update enhances the reliability of video calls within Odoo by extending the time allowed for a successful ping check. Previously, a missed ping would immediately drop the call, but now it 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 fixes an issue where IoT Box identification wasn't correctly updated after a database upgrade. Now, IoT Boxes are identified by either their MAC address or serial number, ensuring accurate tracking and management. This change enhances the reliability of our IoT integration.
Original PR description
After upgrading a db, the IoT Box updates. Before v19.0, the IoT identifier was its mac address, after it's the serial number. We now search boxes idenfied by both mac address or serial number and update accordingly. see odoo/odoo#242212
This update fixes an issue where imported DTE invoices in a multi-company environment incorrectly assigned tax to the wrong company. The fix ensures the correct company's default purchase tax is used when creating move lines from imported invoices, improving data accuracy and compliance.
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 fixes an issue where the order of products was incorrect on delivery slips. The change ensures that move lines are printed in the correct sequence, aligning with the intended delivery order. This improves the accuracy and reliability of delivery slip reports.
Original PR description
**Steps to reproduce:** - Add 2 products in a delivery - Add the second's product move lines before the first one. - Validate and print delivery slip **Issue:** We iterate the `move_line_ids` directly which means if we have a new move line for a move with a lower id, it will push the product to the end of the delivery slip. **Example:** If we have `stock.move(1,)` with `stock.move_line(52,)` and `stock.move(2,)` with `stock.move_line(51,)`. `stock.move_line(51,)` will be printed first, which introduces a change in the order of the delivery slip. **Fix:** Iterate on `move_ids` and access `move_line_ids` through it, to print `move_lines_ids` in the same order of the `move_id`. Task: 4570203 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213400
This update fixes an issue where links to headings within locked Knowledge articles didn't scroll to the correct section after loading. By adding scrolling functionality to the `HtmlViewer` component, users can now seamlessly navigate to headings regardless of whether the article is locked, improving the overall user experience.
Original PR description
Problem: When navigating to a link that points to a heading in a locked article, the page does not scroll to the target heading after load. Cause: When an article is locked, `HtmlViewer` is used instead of the editor. In this mode, `HeadingLinkPlugin` is not loaded, even though it is the component responsible for scrolling to elements with `data-heading-link-id`. Solution: Add the same heading link scrolling logic to `HtmlViewer` so that links to headings work consistently, even when the article is locked. Steps to reproduce: - Go to Knowledge. - Copy a heading link. - Lock the article. - Paste the URL in the browser. - When the page loads, it does not scroll to the heading. opw-5418474 Forward-Port-Of: odoo/enterprise#102431
This update corrects a technical issue where sales orders were being sent to the blackbox service multiple times. The fix ensures that sales data is only transmitted once, improving data accuracy and system efficiency. This is a routine maintenance update.
Original PR description
This fix ensure we don't send twice the same NS (normal sale) to the blackbox. We only push the order to the blackbox if it does not contain a signature yet. Forward-Port-Of: odoo/enterprise#102434
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, preventing crashes and improving the stability of the invoicing process. The fix resulted in a 1.7GB memory reduction.
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 fixes an issue where the list view of vendor bills linked to analytic accounts didn't accurately reflect the number of bills available. The change ensures that all vendor bills and receipts are displayed correctly when using the 'smart button,' providing a more accurate view of expenses. This improves the usability of the expense approval process.
Original PR description
Currently, when the user clicks the vendor bill smart button from analytic accounts, the list view shows no records even though the button count is greater than 0. **Steps to replicate:** * Install…
Currently, when the user clicks the vendor bill smart button from analytic accounts, the list view shows no records even though the button count is greater than 0. **Steps to replicate:** * Install `accountant` and `hr_expense` with demo. * Enable analytic accounting from settings. * Expense > Approve and Post submitted expense * Analytic Accounts > Nebula > Vendor Bills **Observed Behaviour:** * Even though the smart button shows a count of 1 there are no records displayed in the list view. **Root cause:** * After PR [1], vendor bills were changed to receipts. Since [2] counts receipts too, the button shows a different count than the list view, as [3] does not include receipts. **Solution:** * Show purchase receipts along with the vendor bills which correctly matches with the vendor bill count. [1]: https://github.com/odoo/odoo/pull/217758 [2]: https://github.com/odoo/odoo/blob/569b2e27699a76f9bac210e61b47f8a5708c814b/addons/account/models/account_analytic_account.py#L36 [3]: https://github.com/odoo/odoo/blob/569b2e27699a76f9bac210e61b47f8a5708c814b/addons/account/models/account_analytic_account.py#L68 opw-5359320
This update resolves an issue where users couldn't initiate calls from the softphone when opening modals like email or SMS wizards. The fix adjusts the display order of the softphone to ensure it's always visible and clickable when a call is active. This improves the user experience for call handling.
Original PR description
If you get a call when opening any modal/composer like email/sms wizard, you won't be able to pick up the call as the softphone is not clickable. This is because the z-index of the softphone is less than the modal. This commit fixes that issue by making the softphone above modals only if there is a pending call. [Task-4018118](https://www.odoo.com/odoo/project.task/4018118) Forward-Port-Of: odoo/enterprise#103072
This update fixes a limitation in the HTML editor where code blocks with syntax highlighting wouldn't allow users to convert them back to regular paragraphs. A new button has been added to easily switch between syntax highlighting and standard paragraph formatting, improving the user experience for creating and editing code within notes.
Original PR description
When syntax highlighting is activated on code blocks, neither the powerbox nor the toolbar is available inside the block, making it impossible to convert it back into a paragraph. This commit adds a button to convert such code blocks back into paragraphs. Steps to reproduce: - Go to a "To Do" note - Insert a code block with `/code` => There was no way to convert it back to a paragraph task-5241467
A validation error when customizing the Sales Order Confirmation email template was resolved. This issue occurred if the 'website_sale' module wasn't installed. The fix ensures the template handles missing website information safely, preventing crashes and allowing users to customize emails without needing to install additional modules.
Original PR description
**Issue** When customizing the *Sales: Order Confirmation* mail template, a validation error appeared if the `website_sale` module was not installed. **Steps to Reproduce** 1. Go to *Settings → Technical → Email Templates* 2. Open *Sales: Order Confirmation* 3. Make inline changes and save each time → A validation error is raised. **Root Cause** The template referenced `website_id` on `sale.order`, which only exists when the `website_sale` module is installed. QWeb pre-evaluates expressions inside `<t t-if="...">` blocks, so even with `hasattr(object, 'website_id')`, the engine still tried to access `object.website_id`, causing the crash. **Fix** Guard all `website_id` usages with explicit checks: `hasattr(object, 'website_id') and object.website_id`, ensuring safe evaluation when the field is missing. opw-5180725 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where certain website-related modules, like 'ai_website', were not correctly identified for translation. The fix ensures that all modules associated with the 'website' category are now included, guaranteeing consistent translations across the platform. This improves the accuracy and completeness of translations for our website content.
Original PR description
Current behavior before PR: Only the modules with names starting with 'website' were added to the website translated modules. Causing modules such as 'ai_website' to miss translations. Desired behavior after PR is merged: All the modules related to 'website' are selected and added. task-5375210 parent support task-5210084 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that when a delivery is linked to a sale order in Odoo, the sale order's references are automatically connected to the delivery moves. This improves data accuracy and simplifies tracking of sales orders and their associated shipments. It resolves an issue where these links weren't consistently maintained.
Original PR description
Adds a test to ensure that the reference of a sale order is linked to the associated delivery moves when the delivery is linked to the so. opw-5386424 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240102 Forward-Port-Of: odoo/odoo#239697