Daily updates from Odoo
Wednesday, February 25, 2026
262 changes
43 changes
Enhancements to existing features
This update enhances UrbanPiper's functionality by allowing discounts to be applied to individual products within orders, rather than the entire order. This ensures that order totals, payments, and taxes accurately reflect these line-level discounts, improving pricing accuracy for our clients.
Original PR description
Before this commit: ================ - Discounts were only applied to the entire order. - Product-level (line) discounts were not handled in UrbanPiper. After this commit: ================ - Product-level discounts can be applied to individual products in UrbanPiper. - Order totals, payments, and taxes now correctly reflect line-level discounts. Task - 4977960 Forward-Port-Of: odoo/enterprise#108372 Forward-Port-Of: odoo/enterprise#97114
This update clarifies that commission adjustments can only be created using users who are part of an approved sales plan. Previously, adjustments could be linked to any active plan, leading to confusion. This change improves the accuracy and usability of commission management within the system.
Original PR description
Before this commit, when defining ajustment, the add_user_id and reduce_user_id could belong to any kind of active plan. It would make difficult to select the correct user when multiple plans were available. This commit ensure only approved plan can be used to create ajustments. Forward-Port-Of: odoo/enterprise#106637
This update introduces a feature to temporarily 'snooze' products in the Point of Sale system. When a product is snoozed, it appears grayed out, but remains available for ordering. A countdown timer indicates when the product will become available again, managing inventory effectively.
Original PR description
The PR will add an extra availability section on the product info popup which shows whether a product is currently available. From that section the product can then be 'snoozed', which will make it unavailable for a specified period of time. (1, 2, 4 hours, or for the entire session). When the product is unavailable there's a countdown timer on the popup showing when the product will be available again. Products which are 'snoozed' still show up on the product screen, but grayed out. The effect is purely cosmetic, as they can still be added to new orders. Task-[5170696](https://www.odoo.com/odoo/project/1737/tasks/5170696) Previous discussion-[#232625](https://github.com/odoo/odoo/pull/232625) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245891
Resolved issues and error corrections
This update prevents a crash in the payroll system that occurred when employee records lacked contract dates. The fix ensures that necessary contract date fields are populated before payroll warnings are calculated, improving the system's stability and reliability for employee data processing.
Original PR description
This commit fixes a traceback that occurred when an `hr.employee` record had no `contract_date_start` or `contract_date_end` defined, while payroll warnings depending on those fields were present. Since `warning_date` is computed based on the contract dates, the absence of the relevant field caused a crash. We now ensure that `contract_date_start` and `contract_date_end` are set before computing `warning_date` with either one. TaskID-5944876
This update resolves an issue preventing the demonstration of the new ‘planning_field_service_sale_timesheet’ feature within the Odoo Enterprise system. The change ensures the demo accurately reflects the functionality, allowing users to better understand and utilize this new tool for managing service-based sales timesheets. This improves the overall user experience and training materials.
This update corrects a technical issue where the IoT long polling process was failing due to incorrect parameter passing. The fix ensures all necessary parameters are correctly transmitted, resolving a potential disruption in receiving IoT event data. This improves the reliability of the IoT integration.
Original PR description
Before this commit, when the `_poll` method in the `iot_longpolling` called itself to listen for further events, it didn't pass in the `useLna` parameter. This caused the second call to `/event` to not use HTTP and therefore could fail. After this commit, the parameters are all passed through as expected.
This update removes outdated and unused translation files from our localization setup. Specifically, it addresses instances where translation files were left behind after previous builds, ensuring our software uses only the most current and relevant language resources. This improves the accuracy and efficiency of the Odoo platform.
Original PR description
Does 2 things: - removes obsolete modules from .weblate.json - removes phantom modules that only have .po files in it --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update removes outdated and unused translation files from our localization setup. Specifically, it addresses instances where translation files were left behind after previous updates, ensuring our software is localized correctly for a wider range of languages. This improves the quality and accuracy of the Odoo Enterprise application for international users.
Original PR description
Does 2 things: - removes obsolete modules from .weblate.json - removes phantom modules that only have .po files in it
This update fixes a problem where subcontracting production orders weren't correctly displaying all associated move lines. By ensuring each move line is linked to the receipt picking, the 'Move' detail operations button now accurately shows all serial/lot numbers, improving traceability and reducing confusion for users.
Original PR description
*: mrp_subcontracting Issue: --------------------------------- When subcontracting a lot/serial-tracked product and generating multiple subcontracting MOs by generating SN numbers or the "Create New…
*: mrp_subcontracting Issue: --------------------------------- When subcontracting a lot/serial-tracked product and generating multiple subcontracting MOs by generating SN numbers or the "Create New Production" action, only the `first serial number line` appears in the "Move" detail operations smart button. Although all move lines are correctly created on the move, this behaviour is confusing for the user. Steps to reproduce: --------------------------------- 1. Install the `mrp_subcontracting_purchase` module. 2. Create a serial-tracked product and its subcontracting BoM. 3. Create a PO with a subcontracting vendor and a product quantity greater than 1. 4. Confirm the PO and validate the resupply. 5. Open the receipt and click on the "Subcontracting Production" smart button. 6. Generate serial numbers for the product. 7. Validate the receipt and open the "Move" detail operations smart button. 8. Only one line (the first serial number) is shown, while the move actually contains all move lines. Cause: --------------------------------- When serial numbers are generated from the subcontracting MO view, or when a new MO is created using the "Create New Production" action introduced in [PR](https://github.com/odoo/odoo/pull/218377), new move lines are created without setting the `picking_id`. As a result, these move lines are linked to the stock move but not directly to the picking. Since the "Move" detail operations smart button relies on the picking’s `move_line_ids`, the newly created move lines are not displayed. With this commit: --------------------------------- The `picking_id` is now set on newly created move lines. This ensures that all move lines are directly linked to the picking, allowing the "Move" detail operations smart button to display all serial/lot lines correctly and improving traceability for the user. And also When working with a subcontracting order, if the user opens the lot/serial number generation wizard from the subcontracting production and directly clicks 'Apply' without creating or assigning any lot/serial number, Odoo raises the following traceback: `IndexError: tuple index out of range` This issue has also been fixed here. Forward-Port-Of: odoo/odoo#243988
This update resolves issues preventing early bill printing with the Italian fiscal printer. The fix addresses a traceback caused by incorrect data handling and ensures the receipt prints correctly, improving the restaurant's order fulfillment process.
Original PR description
Fix 1: ------- Using the early receipt printing option leads to a traceback when using the italian fiscal printer. Steps to reproduce: ------------------- * Setup the italian fiscal printer for a…
Fix 1:
-------
Using the early receipt printing option leads to a traceback when using the italian fiscal printer.
Steps to reproduce:
-------------------
* Setup the italian fiscal printer for a restaurant
* Enable Early Receipt printing
* Open restaurant
* Open a table, add an item to cart
* Try the early print option
> Observation: Traceback
Why the fix:
------------
Initially the traceback is related to trying to read `decimal_places` out of undefined. The current order doesn't have yet a currency.
To solve this initial issue we can just take the currency of the config if there's none on the order. The pos does not handle multicurrency so the order will always have the same currency as the config anyway.
After solving this part another issue would still happen. If the order was no sent to the kitchen yet. Such orders are not yet synced to the backend and do not have an id of type number. If the order had been send to the display.
This scenario was sending the printer, the data to print and with a successful print we were trying to sync data to the server with
```
await this.data.write("pos.order", [order.id], updateData);
```
which was triggering an error in `orm_services` with `validatePrimitiveList`.
> Invalid ids list: pos.order_4
If we try to reprint AGAIN the bill for some reason, we get another traceback. It's because the nb_print is now 1 and therefore we now try to print with
```
printResult = await this.fiscalPrinter.printContentByNumbers({
order: order,
});
```
which will try to split undefined here
```
this.receiptNumber = this.props.order.it_fiscal_receipt_number;
const dateParts = this.props.order.it_fiscal_receipt_date.split("/");
```
Those two last issues are solved by not syncing the data to the server when we simply print the bill early.
-------
-------
Fix 2:
-------
Currently the early printing option does not work as desired. The fiscal printer does not print the receipt.
Steps to reproduce:
-------------------
* Setup the italian fiscal printer for a restaurant
* Enable Early Receipt printing
* Open restaurant
* Open a table, add an item to cart
* Try the early print option
> Observation: the printer stops in the middle of printing the receipt
Why the fix:
------------
The early receipt was trying to be printed as a fiscal document. However it cannot be considered as such.
We backport this fix that enables basic receipt printing and alter it to also work with early printing.
Fix being backported: https://github.com/odoo/enterprise/commit/b8fd13b802729ccee080ab14f2958d59f57d0f97
There are a few differences between the early receipt and the basic print, mainly the fact that prices need to be shown on the early receipt.
There are a few differences with the original commit. In the documentation of the printer, `printNormal` uses data and the original commit mixes between `data` and `message` so it is harmonized here.
opw-5387572
Results:
-----------
Basic receipt:
<img width="672" height="835" alt="image" src="https://github.com/user-attachments/assets/3de96523-22db-4a27-adbd-3464802604aa" />
Early receipt:
<img width="658" height="842" alt="image" src="https://github.com/user-attachments/assets/f6b7ab24-e27b-4deb-8d5f-1b0c41bb28f0" />
Forward-Port-Of: odoo/enterprise#108161
Forward-Port-Of: odoo/enterprise#105511This update corrects a bug in the invoice processing system. When internal users forward supplier bills through a specific email alias, the system incorrectly added the internal user as the vendor. This prevented proper OCR processing and auto-population of document fields, leading to errors. This fix ensures that the system only creates invoices with a registered supplier partner.
Original PR description
Currently we have an issue with OCR flow, where if internal users forward an email from an internal email address, the internal user is added as vendor Steps to reproduce: - Setup email alias for journal "Purchases" - From an internal user email, forward a supplier bill to the vendor bill alias Issue: If the supplier is not already a registered partner, the bill will be created with the internal user set as partner. This will break OCR flow where the missing document fields will be auto populated from the bill opw-5487368 Forward-Port-Of: odoo/odoo#246352
This update fixes a bug where users could accidentally create duplicate lines within Point of Sale orders. The change ensures that if a user attempts to create a line that already exists, it's updated instead, preventing data inconsistencies and improving order accuracy. This improves the overall reliability of the Point of Sale system.
Original PR description
Before this commit, it could happen that a user send a request to the backend to create a pos.order.line that already exists because it didn't know it was already synced for some reason (the page was reloaded before getting the response and the frontend was then relying on indexedDB for example). It would then send a create command and we would have multiple lines with the same values. We have a constraint that usually works but for people where the bug happened before the constraint was created, the constraint would not be created and so the bug could still happen We now prevent that by changing the create command into an update command if the line to create already exists by comparing its uuid to the uuids of the lines related to the order. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249109
This update fixes a potential issue where special products used in point-of-sale (like those with discounts or tips) could be accidentally deleted or archived. This change adds a safeguard to ensure these products remain available in the POS, minimizing errors and maintaining accurate sales data. It's a critical fix to prevent disruptions to the point-of-sale system.
Original PR description
Before this commit, it was possible to delete or archive some products even if they were special for the pos (discount, tips, settle, etc.). This commit adds a mechanism to prevent this and reduce the risk of errors linked to missing products in the pos. Enterprise PR: https://github.com/odoo/enterprise/pull/95789 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230865 Forward-Port-Of: odoo/odoo#229074
This update ensures that essential products like 'settle due' and 'deposit' are automatically configured for all Point of Sale (POS) settings when the pos_settle_due module is installed. Previously, these products were only available in POS sessions without open sessions, causing potential issues. This change guarantees consistent product availability across all POS configurations.
Original PR description
Before this commit, when the module pos_settle_due was installed, the special products (settle due, deposit, settle invoice) were only set on the POS configurations that did not have any open session. This could lead to issues when trying to use these products in a POS session of a configuration that did not have them set. Now, the special products are set on all POS configurations when installing the module. Community PR: https://github.com/odoo/odoo/pull/229074 Forward-Port-Of: odoo/enterprise#96788 Forward-Port-Of: odoo/enterprise#95789
This update fixes a problem where users attempting to print resumes with incorrect templates received a generic error message. Now, when an invalid template is used, a detailed traceback is displayed, making it easier for support teams to diagnose and resolve the issue. This improves the user experience and streamlines troubleshooting.
Original PR description
Currently, when a user tries to print a resume with an invalid template there’s no traceback to show what went wrong. **Steps to produce:** * Install `hr` with demo data * Modify the view…
Currently, when a user tries to print a resume with an invalid template there’s no traceback to show what went wrong. **Steps to produce:** * Install `hr` with demo data * Modify the view `report_employee_cv` by adding `<div t-if=o.no/>` * Print resume of any employee **Observed Behavior:** Currently it only shows the error in [1], with no context or traceback to explain what went wrong. **Root cause:** * This happens because the route doesn’t include the website parameter. Without it, the system treats the route as non–front end [2], so the error handler never reaches [3].That means [4] never loads the templates [5], and the browser just gets a plain response at [6]. **Solution:** * Catching and raising UserError shows appropriate traceback. **Before:** <img width="1606" height="796" alt="image" src="https://github.com/user-attachments/assets/d5432fbf-d016-46a9-bade-8e8408848c66" /> **After:** <img width="1832" height="928" alt="image" src="https://github.com/user-attachments/assets/6f0413ca-a82a-487d-888f-81be6f0fab03" /> [1]: https://drive.google.com/file/d/1qJLkFGw4bEclqKihdUI-4bjJofdFArEc/view?usp=sharing [2]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L386 [3]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L611 [4]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L573-L576 [5]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/views/http_routing_template.xml#L139 [6]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L575 Related: https://github.com/odoo/enterprise/pull/100142 opw-5167898 Forward-Port-Of: odoo/odoo#250286 Forward-Port-Of: odoo/odoo#237262
This update fixes a problem where users wouldn't receive helpful information when trying to print PDF payroll reports with incorrect document layouts. Now, when an invalid layout is used, a detailed traceback is displayed, making it easier to identify and correct the issue. This improves the user experience and troubleshooting of payroll reports.
Original PR description
Currently, when a user tries to print a PDF report with an invalid document layout template, there’s no traceback to show what went wrong. **Steps to produce:** * Install payroll with demo data. *…
Currently, when a user tries to print a PDF report with an invalid document layout template, there’s no traceback to show what went wrong. **Steps to produce:** * Install payroll with demo data. * Settings > Configure Document Layout then Edit Layout * Add non-existent field `<div t-if='o.no'/>` * Payroll > All payslips > print any payslip **Observed Behavior:** * Currently it only shows the error in [1], with no context or traceback to explain what went wrong. **Root cause:** * This happens because the route doesn’t include the website parameter. Without it, the system treats the route as non–front end [2], so the error handler never reaches [3].That means [4] never loads the templates [5], and the browser just gets a plain response at [6]. **Solution:** * Catching and raising UserError shows appropriate traceback. **Before:** <img width="1601" height="507" alt="image" src="https://github.com/user-attachments/assets/f7f208f0-cdd7-410e-87e7-32a9651df9d8" /> **After:** <img width="1847" height="928" alt="image" src="https://github.com/user-attachments/assets/c73522d6-2632-422b-b1d1-234e6c61ed2e" /> [1]: https://drive.google.com/file/d/1qJLkFGw4bEclqKihdUI-4bjJofdFArEc/view?usp=sharing [2]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L386 [3]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L611 [4]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L573-L576 [5]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/views/http_routing_template.xml#L139 [6]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L575 Related:https://github.com/odoo/odoo/pull/237262 opw-5167898 Forward-Port-Of: odoo/enterprise#108438 Forward-Port-Of: odoo/enterprise#100142
This update resolves an issue that prevented users from clicking the Work Entries button when an overtime record lacked a 'Stop' time. The fix corrects a technical error related to comparing date/time values, ensuring the button functionality is now consistently available. This improves the user experience when managing overtime attendance.
Original PR description
Clicking the Work Entries smart button raises a traceback when an overtime record has no Stop (time_stop). Steps to reproduce the error: - Install ``hr_work_entry_attendance`` module with demo data -…
Clicking the Work Entries smart button raises a traceback when an overtime record has no Stop (time_stop). Steps to reproduce the error: - Install ``hr_work_entry_attendance`` module with demo data - Activate developer mode - Create an Employee A > Settings > Set Default Ruleset in Overtime Ruleset In Payroll Tab, Work Entry Source: ``Attendances`` and set Contract - Create an overtime attendance > Save > Open the Overtime Details > Unset the ``Stop(time_stop)`` > Save - Open Employee A > Click on Work Entries smart button Traceback: ```py TypeError: '<' not supported between instances of 'bool' and 'datetime.datetime' ``` https://github.com/odoo/enterprise/blob/56c3723a925f718ba39d11cde12933542ebcd7c1/hr_work_entry_attendance/models/hr_version.py#L49-L52 When ``stop(time_stop)`` is unset in the overtime, ``ot.time_stop`` is False, causing ``min()`` to compare a ``datetime`` with ``False``, which raises the above traceback. sentry-7169332615 Forward-Port-Of: odoo/enterprise#103764
This update fixes a technical issue related to invoice generation when using BIS3 files for B2C transactions. Previously, certain checks were performed unnecessarily. Now, the system correctly handles B2C scenarios where the EndpointId might be missing, ensuring accurate invoice creation without impacting core functionality.
Original PR description
…peppol checked Some people are using BIS3 files even for B2C. They give the xml files to the accountant for him/her to import the file and generate the invoice in the accounting software. In that case, since it's a B2C transaction, the EndpointId might not be set but that's ok since it's only used to generate the invoice. opw-5952109 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249751
This update fixes a bug in the Odoo 19.0 version where the 'Copy Existing Operations' button was missing from BoM operation tabs. This prevents users from easily copying operations from other bills of materials, impacting efficiency. The fix backports functionality previously introduced in 19.1 to ensure consistent user experience.
Original PR description
### Steps to reproduce the bug: - Install mrp - Go to manufacturing app - Go to products -> bills of materials - Create a new bill of material for a product - Go to the operations tab - No 'copy…
### Steps to reproduce the bug: - Install mrp - Go to manufacturing app - Go to products -> bills of materials - Create a new bill of material for a product - Go to the operations tab - No 'copy existing operations' button appears if at least one operation is already created ### The problem: In version 19.0, the "Copy Existing Operations" button is missing from the BoM operations tab when no operations have been defined yet for the current BoM. While this feature was fully functional in version 18.4, it became inaccessible in 19.0 to users due to a UI reorganization introduced in commit https://github.com/odoo/odoo/commit/80e6ed658fb43584bc2fad673ca40d9af6cf0ab6 that accidentally omitted the "Copy Existing Operations" button. Currently, users are forced to manually create at least one operation before they can see the option to copy from other BoMs. ### The reason to introduce the fix: The ability to copy operations is useful also when starting with an empty BoM if operations in other BoM's have been already created. Since this fix has already been implemented in version 19.1 via commit https://github.com/odoo/odoo/commit/02e837c959381523170c653da099328e9855a4e4, this PR backports that changes to 19.0 to restore feature parity and improve the user experience. opw-5906667 Forward-Port-Of: odoo/odoo#250411 Forward-Port-Of: odoo/odoo#248225
This update fixes a bug where navigating to pages with breadcrumbs caused a crash when the website header was disabled. The change ensures the website interaction safely handles pages without a header, improving stability and user experience. This resolves a technical issue that could disrupt customer journeys.
Original PR description
When the header is disabled globally via the Theme tab in edit mode, navigating to a page containing a breadcrumb caused a crash. The PageBreadcrumb interaction did not handle the case where no header was present on the page. This commit updates the interaction to safely handle pages without a header. Task-ID: 5927177 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#248080
This update fixes a bug where shifts crossing midnight were incorrectly flagged as overtime for employees in timezones like India. The change ensures accurate overtime calculations regardless of the employee's timezone, improving payroll accuracy. It also includes updates to internal code and added testing for reliability.
Original PR description
**Description of the issue/feature this PR addresses:** Fix the overtime calculation logic for resources in timezones ahead of UTC (specifically Asia/Kolkata +05:30) where shifts crossing midnight incorrectly attribute the second half of the shift as overtime. **Current behavior before PR:** shifts crossing midnight incorrectly attribute the second half of the shift as overtime. **Desired behavior after PR is merged:** . Fix version_periods_by_employee interval . Update get_dates() method to return date objects . Add corresponding tests coverage task-5949757 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249410
This update adapts the MRP module to a new time display format (e.g., '1h 23m 45s') introduced with recent changes. It replaces outdated formatting functions and removes confusing references to 'minutes' to ensure consistent and intuitive reporting within the MRP system. This improves clarity and usability for users.
Original PR description
With the changes made to float_time, every display is now showing `1h 23m 45s` instead of `83:45` (for example). This PR aims to adapt the MRP module to the new display. We're also replacing all uses `formatFloatTime` by `formatDuration` since the former is being depreciated. Finally, we're removing mentions of `minutes` in MRP since it is now counter-intuitive with the new display. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that time-related data within the MRP modules (like production planning) is consistently recorded and displayed in minutes. The change replaces an older formatting method with a new one, improving the accuracy and reliability of time-based reports and calculations. This update affects how production schedules and work orders are managed.
Original PR description
Make sure that time fields in mrp modules are in minutes. Add a new widget in mrp_plm for updates on time data types. Replace formatFloatTime by formatDuration.
This update resolves an initial flicker in the live chat category within the messaging menu. Previously, the category would appear and disappear briefly when opened. The fix introduces a new field to ensure the category is reliably displayed, preventing users from being unexpectedly directed to a different chat category.
Original PR description
Before this PR, the live chat category in the messaging menu would flicker when opened initially. This occurs because the category is displayed only when users have live chats to show. However, this information is available only after the channels are fully fetched, which causes the flicker. This is problematic because users may accidentally click and end up in a different category. This commit fixes the issue by introducing the `show_livechat_category` field, which is initially returned by the server depending on whether the user has pinned live chats and is later updated by its compute function. task-5475290 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 CABA taxes were incorrectly included in tax reports when part of a tax group. The change ensures that CABA taxes are properly excluded from reports, preventing duplicate amounts and improving the accuracy of financial reporting. This resolves a bug impacting invoice and reconciliation processes.
Original PR description
How to reproduce: - Create one CABA tax and one normal tax. - Create a tax group containing both taxes. - Create an invoice using this tax group. - In the tax report, the CABA tax appears even when the invoice is unpaid. - After reconciliation, the CABA tax amount is duplicated in the report. When the CABA tax is part of a tax group, it is selected in _read_generic_tax_report_amounts_no_tax_details. Since the tax group has tax_exigibility = 'on_invoice', the CABA tax inside the group is incorrectly included by the query. opw-5468074 Forward-Port-Of: odoo/enterprise#105888
This update resolves an issue causing errors when editing addresses within the customer portal. The fix ensures accurate address validation by correctly comparing data, preventing form errors and improving the user experience. This was triggered by a recent code change.
Original PR description
**Steps to reproduce:** - Create a DB with l10n_ar and l10n_ar ecommerce - Go to Settings > Invoicing > Fiscal Localization - Select the 'Argentina - Argentine Generic Chart of Accounts for…
**Steps to reproduce:** - Create a DB with l10n_ar and l10n_ar ecommerce - Go to Settings > Invoicing > Fiscal Localization - Select the 'Argentina - Argentine Generic Chart of Accounts for Registered Accountants' package - Create a website, and a portal user - Add a main and a secondary address to the user using the website form in 'My Account' - Go to the secondary address and change any field - Click on Save Address - Multiple errors will appear on the form (reproducible with other similar config) (and in logs: `UserWarning: unsupported operand type(s) for "==": 'l10n_latam.identification.type()' == '1'`) **Issue:** In `address_form_fields` some hidden input field are used to add specific non-editable values to the forms. This breaks the address validation of `CustomerPortal` in `def _validate_address_values` due to the following comparison: `partner_sudo[commercial_field_name] != address_values[commercial_field_name]` which try to compare recordsets with the given ids. **Fix:** Cast relational field to their id values to ensure they can be properly compared to the website form values. related fix which introduces the input issue: https://github.com/odoo/odoo/commit/0ee91631214c34b650342a0210ee8db27764f252 opw-5247171 Forward-Port-Of: odoo/odoo#244532
This update corrects a display issue in the Timesheet grid view where the total overtime was incorrectly showing 'Weekly Overtime'. The fix renames this cell to 'Total Overtime' to accurately reflect overtime totals across all time periods (day, week, or month) viewed in the grid.
Original PR description
### Issue: When displaying the month in the grid view and hovering the bottom right cell, where the total overtime is displayed, it shows "Weekly overtime". ### Steps to reproduce: - Open Timesheet app - In "My Timesheet", display the grid in day or month - Hover the bottom right cell - It displays "Weekly Overtime" ### Solution: Rename it to "Total overtime" to handle all periods (day, week, month). opw-5502864 Forward-Port-Of: odoo/enterprise#108480 Forward-Port-Of: odoo/enterprise#107642
This update fixes a labeling error in Odoo invoices for Qatar. Previously, the invoice amount description used 'Rial' instead of the correct 'Riyal'. This change ensures accurate currency representation for Qatar-based transactions, improving financial reporting and compliance.
Original PR description
Steps to reproduce: 1- Install Accounting and 'l10n_qa' modules 2- Switch to Qatar company and enable "Total amount of invoice in letters" under accounting settings 3. Issue an invoice and preview it The issue: The description of the amount uses "Rial" Expected behavior: The amount should use "Riyal" opw-5919587 Forward-Port-Of: odoo/odoo#250299
This update prevents unnecessary performance updates (mutations) on website buttons, which can cause instability and errors. By ensuring the loading effect is only applied when needed, the website builder and related processes will run more smoothly and reliably. This improves the overall user experience and reduces potential issues with the design theme updates.
Original PR description
__Before commit__ When using `makeButtonHandler`, a loading effect is applied to the button if the handler takes more than 400ms to execute. However, if the handler finishes sooner, the effect is…
__Before commit__ When using `makeButtonHandler`, a loading effect is applied to the button if the handler takes more than 400ms to execute. However, if the handler finishes sooner, the effect is still briefly added and removed, triggering a DOM mutation. If a button is clicked and the website builder opens immediately after, this mutation may be recorded in the current history step despite being unnecessary. This causes the `design-themes` tour `theme_menu_hierarchies` to fail in a non-deterministic way with the following warning: "should not have any 'characterData', 'remove' or 'add' mutations in current step when you update the selection" __Fix__ Ensure the loading effect is never added if the handler execution time is shorter than the debounce duration. This fix is applied to both `makeButtonHandler` functions in the codebase. The test case is only added for the interaction use case, as the other instance resides in legacy code. runbot-229803 Forward-Port-Of: odoo/odoo#248242
This update fixes an issue where pasting content into the website editor, particularly within iframes, would unexpectedly remove unremovable elements. The change adjusts how the editor handles inline elements, ensuring that elements are preserved during the paste process. This improves the user experience and prevents data loss.
Original PR description
*: website Before this commit: when a editable container is wrapped inside a non-contenteditable, which could happen inside an iframe, pasting on a selection including an unremovable element will remove the element. This is because the config parameter `allowInlineAtRoot` is false by default, the editable container of Contact us button is considered as the edition boundary, and then `wrapInlinesInBlocks` is called on it at insert, which removes invisible nodes in the wrapping process. After this commit: we now use predicates to decide areInlinesAllowedAtRoot We add a predicate specifically for the container of Contact Us button, to allow inline element in the root. The `wrapInlinesInBlocks` won't be called on the container on paste anymore. task-5109662 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246987 Forward-Port-Of: odoo/odoo#241836
This update resolves a test failure related to video calls within the Odoo platform. The fix ensures the system correctly handles video stream toggles, preventing unexpected behavior and improving the reliability of the call testing process. This contributes to a more stable and predictable user experience.
Original PR description
Before this commit, the following discuss call test may fail non-deterministically: ``` @mail/discuss/call/call/auto-focus participant video in one-to-one call in chat window ``` This happens at the…
Before this commit, the following discuss call test may fail non-deterministically: ``` @mail/discuss/call/call/auto-focus participant video in one-to-one call in chat window ``` This happens at the step where it checks that when inside the discuss meeting view, having another participant enable a video stream does not auto-focus the card. The test was failing and auto-focusing the card because the simulated toggling of enabling the video stream happens before the side-effect of rendering to toggle the flag that meeting view is on. So the handling of event that video stream is toggled on was mistakenly considering outside of meeting view. This commit fixes the issue by awaiting a `data-active` on the UI if meeting view, which ensures the rendering of meeting view is complete and store is aware of meeting view being open, before triggering the event that simulates toggling of video stream. This technique is borrowed from `DiscussApp` component that requires a similar technique to determine whether a chat window must auto-open or not, which also requires making sure the store knows precisely when `DiscussApp` is logically open. Fixes runbot-error-240554 Forward-Port-Of: odoo/odoo#250174
This update resolves an issue where the 'typing' indicator on chat channels remained visible indefinitely. The fix ensures that timeout registrations are directly tied to typing state updates, preventing incorrect expiration scheduling due to timestamp duplication. This improves the user experience by accurately reflecting when a user is actively typing.
Original PR description
Typing expiration was indirectly tied to typing timestamp updates. Typing timestamps are second-precision, so two consecutive typing events can carry the same timestamp value. In that case, the timestamp field may not be considered updated on the client. The expiration timeout is then not re-armed even though typing is set to true. When that happens, the typing indicator can remain visible indefinitely unless an explicit "stop typing" event is received. This change makes timeout registration depend on typing state updates directly. Expiration is always scheduled when typing becomes active, regardless of timestamp equality. [task-4922630](https://www.odoo.com/odoo/project/1519/tasks/4922630) Forward-Port-Of: odoo/odoo#250146 Forward-Port-Of: odoo/odoo#249796
This update resolves an issue where the "..." button in meeting chat was causing excessive spacing, making message bubbles appear too small. The fix adds the necessary padding to message actions, ensuring a cleaner and more comfortable user experience. This improves the overall readability and visual appeal of the chat interface.
Original PR description
Before this commit, message actions in meeting chat were taking too much space, reducing the size of message bubbles. This happens because the "..." button had no explicit padding and thus fall-backed to the default padding of a button, which is way too much. This commit fixes the issue by providing the proper padding to message actions in the inline presentation, which is necessarily with a tiny padding. Before / After <img width="297" height="565" alt="Screenshot 2026-02-20 at 18 38 05" src="https://github.com/user-attachments/assets/580bd0ff-ff3a-4830-bac4-6764e78863e2" /> <img width="296" height="562" alt="Screenshot 2026-02-20 at 18 37 41" src="https://github.com/user-attachments/assets/2f3eda5e-4016-402f-9450-157fe7be69bc" /> Forward-Port-Of: odoo/odoo#249880
This update addresses a critical maintenance task, ensuring our tax code data is current. The tax codes haven't been updated in four years, and this fix ensures continued accurate tax calculations within the Odoo Enterprise system. Future enhancements will allow users to initiate this update automatically.
Original PR description
It's been 4 years since the last update [1]. No codes were removed. At some point it would be nice to add this to the avatax_sync_company_params() method so it can be initiated by the user. But we need to update this file regardless, and the mechanism would need to be smart enough to not cause duplicates when e.g. the user has synced it themselves, we then update the csv and they then update the module. [1] https://github.com/odoo/enterprise/pull/30220 opw-5928245 Forward-Port-Of: odoo/enterprise#108209
This update fixes a bug where canceled POS orders with future dates weren't fully removed from the system. Now, cancellations are correctly applied in both the POS interface and the backend, ensuring accurate order tracking and preventing phantom orders. This improves the reliability of our self-checkout process.
Original PR description
Before this fix, when we placed an order from the self-checkout with a preset slot for a future date, we weren't able to cancel it from the POS. The UI showed it as canceled, but after refreshing, the order was still there. Now, when we cancel an order scheduled for the future, it is correctly canceled both in the UI and in the POS. task : 5246089 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248616 Forward-Port-Of: odoo/odoo#235775
This update resolves an issue where stock quantities were being rounded incorrectly when scanning barcodes on delivery orders. The fix ensures more accurate stock updates, preventing discrepancies in inventory levels. This improves the reliability of order fulfillment and reduces potential errors.
Original PR description
To reproduce the issue: - Create a stock quantity of product1 for example of 275.84 kg in PACK1 - Create a delivery order of 3.6 kg - Go to the delivery order on stock barcode - Scan PACK1 - The new line is created as 272.2399999999 Forward-Port-Of: odoo/enterprise#108366 Forward-Port-Of: odoo/enterprise#89300
This update fixes an issue where the appointment type form's time fields were cutting off content. The changes align the time field format with a recent update and remove unnecessary details like 'hour(s)' and seconds, resulting in a cleaner and more user-friendly appointment form.
Original PR description
Purpose ======= Fix the appointment type form view float time fields length to not crop content. Specification ============= Following odoo/odoo#240555 the float time field format has been updated. Adapting all the appointment form view float time fields length to match the new format and not crop the content. Removing useless "hour(s)" suffix as the time representation, whether it's hours or minutes, is now represented inside the field format. Hiding the seconds as it's not relevant for appointments. Task-5717052
This update corrects a technical issue preventing the successful submission of GİB e-Dispatch documents through the Nilvera integration. The previous system incorrectly passed the stock picking company, leading to an error. Now, the correct company environment is passed, ensuring smooth document submission.
Original PR description
# Description of the issue this PR addresses - When sending a GİB e-Dispatch document using l10n_tr_nilvera_edispatch, an error is raised during document submission. - The issue occurs in StockPicking._l10n_tr_nilvera_submit_document when sending request with Nilvera client. - The signature of _get_nilvera_client was updated but the params were not # Current behavior before PR - When attempting to send a GİB e-Dispatch document, the system raises an error. - The method _l10n_tr_nilvera_submit_document calls _get_nilvera_client with self.company. - stock.picking does not have a company field. - This results in an attribute error during client initialization and prevents document submission. # Desired behavior after PR is merged - The correct field self.env.company is passed to _get_nilvera_client. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where warehouse names with only numbers (e.g., '01') were displayed incorrectly in the barcode app. The fix removes a browser setting that was causing numerical warehouse codes to be reversed, ensuring accurate and consistent display of warehouse names for all users.
Original PR description
### Steps to detect the bug: - Download stock apps - Enable "storage locations" settings under warehouse index - Change name of warehouse with a name composed only of numbers (ex. 01) - Create a…
### Steps to detect the bug:
- Download stock apps
- Enable "storage locations" settings under warehouse index
- Change name of warehouse with a name composed only of numbers (ex. 01)
- Create a product (with barcode number)
- Insert a number of products available with smart button "on hand"
- Create a new delivery for that product
- Go to barcode app and search for the delivery you just created
- Click on it and see that the name of the warehouse will be stock/01 instead of the correct 01/stock
### The problem:
The previous configuration used direction: rtl; on the warehouse name
element in the barcode app. So if the string contains only letters the
standard visual order is maintained, however, when the string consists
entirely of numbers the rtl property forces the browser to reorder them
from right to left.
### The reson to introduce the fix:
By removing this property, it is ensured that numerical warehouse codes are displayed in their natural sequence without being flipped.
opw-5730199
Forward-Port-Of: odoo/enterprise#107920This update resolves an issue where validating purchase receipts for kits with different unit of measure categories caused errors. The fix ensures accurate quantity calculations when a purchase order is placed in a foreign currency, preventing receipt validation failures. This improves the reliability of purchase order processing.
Original PR description
Steps to reproduce ------------------ 1. Enable Units of Measure and Automatic Valuation. 2. Create: Product KIT, stockable, UoM category Unit, UoM = Units. BoM for KIT with at least one component…
Steps to reproduce
------------------
1. Enable Units of Measure and Automatic Valuation.
2. Create:
Product KIT, stockable, UoM category Unit, UoM = Units.
BoM for KIT with at least one component whose UoM is in a different
category (e.g. m from Length).
3. Go to the product's category and set the Costing Method to Average
Cost (AVCO) and the Inventory Valuation to Automated.
4. Create a PO for KIT in a currency different from the company currency.
5. Confirm the PO and validate the receipt.
Issue
-----
Validating the receipt raises:
> The unit of measure m defined on the order line doesn't belong to the
> same category as the unit of measure kit defined on the product…
If you keep the PO currency equal to the company currency, the same kit
and BoM work and the receipt posts correctly.
Cause of the issue
------------------
Validating the receipt will call the `_action_done` of stock.move's and generate the related accounting entries. During this call and the currency of the PO is different from the company currency the `_generate_valuation_lines_data` will call the `_get_currency_convert_date` method:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L134-L140
This call will in turn call the `_get_qty_received_without_self`:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L121-L122
which was not written to handle kit products since it assumes that the product of the PO is the same as the one of the related move:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L102-L108
Fix
---
The qty_received is relevant to the _get_currency_convert_date as the method compares the qty_invoiced with the qty_received to determine whether to use the Invoice Date (when qty_invoiced > qty_received) or the Receipt Date.
https://github.com/odoo/odoo/blob/888e086dc6c7823b07993e90f70e2849e988fa7a/addons/purchase_stock/models/stock_move.py#L122-L126
For kits, `qty_received` must be calculated by aggregating component
moves to accurately determine this status. Since the standard logic
crashes due to UoM mismatch, the override in `purchase_mrp` is
necessary to provide the correct quantity for this date selection.
opw-5030761
Forward-Port-Of: odoo/odoo#248883
Forward-Port-Of: odoo/odoo#236276This update fixes an issue where shift start and end times weren't correctly reflecting the assigned shift template, even when employees had fixed schedules. The change ensures shift times align with the template, providing accurate scheduling for employees with varying working hours. This improves the reliability of shift planning.
Original PR description
__ ## Short functional explanation of the error Let's say we create a role containing employees with fixed schedules. Then, we create a shift template that applies on this role. When we create a…
__ ## Short functional explanation of the error Let's say we create a role containing employees with fixed schedules. Then, we create a shift template that applies on this role. When we create a shift, the starting and ending hours will take into consideration the hours of the employee's fixed schedule, instead of aligning with the shift template start and end hours. As discussed with XBO, the start and end hours of the shift should align with the shift template, despite the fixed working schedules having different start and end hours. ## Reproduction Steps 1. Go to Planning. Click on Configuration tab > roles. 2. Create a role and add an employee as a resource This employee has to have a fixed working schedule. 3. Click on Configuration tab > Shift Templates. 4. Create a new Shift Template. Select starting and ending hours different from the employee's fixed schedule. Select the role you just created. 5. Click on Schedule tab > By resource and click on New. 6. Select the role you just created. ### Expected behavior The start and end hours should align with the shift template start and end hours. ### Unexpected behavior The start and end hours are aligned on the employee's fixed working schedule: if the employee has a schedule from 8 to 16h36 and the shift template goes from 10 to 18, the starting and ending hours will be 10 to 16h36. ## Origin of the issue We kept computing the working intervals of employees, even if a shift template was set: https://github.com/odoo/enterprise/blob/8b00363e5e461f11b9736354d94e520e21932e71/planning/models/planning.py#L656-L664 Which isn't necessary in the case where a shift template has been set, as the start and end time are determined by the shift template, and not the employee's schedule. __ opw-5898509 Forward-Port-Of: odoo/enterprise#108187 Forward-Port-Of: odoo/enterprise#107018
This update fixes an issue where Verifactu invoices were incorrectly generating an 'F1' type instead of the required 'F3' type when fully invoicing. The change ensures the correct invoice type is used, aligning with Spanish tax regulations and preventing potential compliance problems. This update ensures accurate VAT reporting for Spanish customers.
Original PR description
To reproduce ------------- 1. Install `l10n_es_edi_verifactu_pos`, and select the ES company 2. Make an order in PoS with a price less than 400, and don't invoice it. 3. Close the PoS session, then…
To reproduce ------------- 1. Install `l10n_es_edi_verifactu_pos`, and select the ES company 2. Make an order in PoS with a price less than 400, and don't invoice it. 3. Close the PoS session, then go to PoS > Orders, and select the previously made order 4. It will have a Verifactu generated document with invoice type as 'F2', which is correct since it's a simplified order. 5. Click invoice to invoice the order; the invoice is no longer simplified. Notice now that the new Verifactu document has an invoice type of 'F1', which corresponds to a normal non simplified invoice. However, since the new invoice is replacing an old simplified one, it should be of type 'F3' instead. The fix ------- When fully invoicing, we check if the order had a linked Veri*factu document of type F2, which means we are now replacing it and should set the type of the new invoice to F3 instead of F1. Sources: -------- Difference between 'F1', 'F2', and 'F3' invoice types: https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/procedimientos-facturacion.html?faqId=bdbd20022fe06910VgnVCM100000dc381e0aRCRD opw-5343973 Forward-Port-Of: odoo/odoo#242274
This update removes unnecessary HTML wrapping from article content. Previously, a 'div' tag was added during processing to handle parsing complexities, which increased the article's HTML depth. This change improves the overall structure and efficiency of article formatting without impacting functionality.
Original PR description
Prior to this commit, `_get_transformed_body_from` wrapped the source body in a `div` because `lxml.html.fragment_fromstring` is used with a `create_parent=True` argument. That argument is required because otherwise, the function throws an error if there are multiple root nodes in the parsed string, which is frequent in an article body. The final returned string still contained that additional `div` ancestor. This does not break an article per se, but repeated usage would increase the html structure depth by 1 every time, and that additional `div` was not part of the function desired transformations. task-5960616 Forward-Port-Of: odoo/enterprise#108310
23 changes
Enhancements to existing features
This update clarifies that commission adjustments can only be created using users who are part of approved subscription plans. Previously, adjustments could be linked to any active plan, leading to confusion and incorrect user selections. This change improves the accuracy and manageability of commission settings.
Original PR description
Before this commit, when defining ajustment, the add_user_id and reduce_user_id could belong to any kind of active plan. It would make difficult to select the correct user when multiple plans were available. This commit ensure only approved plan can be used to create ajustments. Forward-Port-Of: odoo/enterprise#106637
Resolved issues and error corrections
This update resolves a technical issue preventing the correct download of the AW timesheet application on Linux systems. The fix ensures that users can properly access and install the timesheet component, improving the overall user experience. This change focuses on internal technical improvements.
This update corrects a bug where internal users were incorrectly added as vendors when supplier invoices were received via email forwarding. This issue was causing problems with our OCR (Optical Character Recognition) process, which relies on accurate partner information. The fix ensures that invoices are correctly associated with the actual supplier, maintaining the integrity of the OCR workflow.
Original PR description
Currently we have an issue with OCR flow, where if internal users forward an email from an internal email address, the internal user is added as vendor Steps to reproduce: - Setup email alias for journal "Purchases" - From an internal user email, forward a supplier bill to the vendor bill alias Issue: If the supplier is not already a registered partner, the bill will be created with the internal user set as partner. This will break OCR flow where the missing document fields will be auto populated from the bill opw-5487368 Forward-Port-Of: odoo/odoo#246352
This update fixes a problem where users attempting to print resumes with incorrect templates received a generic error message. Now, when an invalid template is used, a detailed traceback is displayed, making it easier to identify and resolve the issue. This improves the user experience and streamlines troubleshooting.
Original PR description
Currently, when a user tries to print a resume with an invalid template there’s no traceback to show what went wrong. **Steps to produce:** * Install `hr` with demo data * Modify the view…
Currently, when a user tries to print a resume with an invalid template there’s no traceback to show what went wrong. **Steps to produce:** * Install `hr` with demo data * Modify the view `report_employee_cv` by adding `<div t-if=o.no/>` * Print resume of any employee **Observed Behavior:** Currently it only shows the error in [1], with no context or traceback to explain what went wrong. **Root cause:** * This happens because the route doesn’t include the website parameter. Without it, the system treats the route as non–front end [2], so the error handler never reaches [3].That means [4] never loads the templates [5], and the browser just gets a plain response at [6]. **Solution:** * Catching and raising UserError shows appropriate traceback. **Before:** <img width="1606" height="796" alt="image" src="https://github.com/user-attachments/assets/d5432fbf-d016-46a9-bade-8e8408848c66" /> **After:** <img width="1832" height="928" alt="image" src="https://github.com/user-attachments/assets/6f0413ca-a82a-487d-888f-81be6f0fab03" /> [1]: https://drive.google.com/file/d/1qJLkFGw4bEclqKihdUI-4bjJofdFArEc/view?usp=sharing [2]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L386 [3]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L611 [4]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L573-L576 [5]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/views/http_routing_template.xml#L139 [6]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L575 Related: https://github.com/odoo/enterprise/pull/100142 opw-5167898 Forward-Port-Of: odoo/odoo#250286 Forward-Port-Of: odoo/odoo#237262
This update fixes a problem where users received a generic error message when trying to print invalid PDF reports. Now, when an error occurs, a detailed traceback is displayed, making it easier to identify and resolve the issue with the document layout. This improves the user experience and troubleshooting process.
Original PR description
Currently, when a user tries to print a PDF report with an invalid document layout template, there’s no traceback to show what went wrong. **Steps to produce:** * Install payroll with demo data. *…
Currently, when a user tries to print a PDF report with an invalid document layout template, there’s no traceback to show what went wrong. **Steps to produce:** * Install payroll with demo data. * Settings > Configure Document Layout then Edit Layout * Add non-existent field `<div t-if='o.no'/>` * Payroll > All payslips > print any payslip **Observed Behavior:** * Currently it only shows the error in [1], with no context or traceback to explain what went wrong. **Root cause:** * This happens because the route doesn’t include the website parameter. Without it, the system treats the route as non–front end [2], so the error handler never reaches [3].That means [4] never loads the templates [5], and the browser just gets a plain response at [6]. **Solution:** * Catching and raising UserError shows appropriate traceback. **Before:** <img width="1601" height="507" alt="image" src="https://github.com/user-attachments/assets/f7f208f0-cdd7-410e-87e7-32a9651df9d8" /> **After:** <img width="1847" height="928" alt="image" src="https://github.com/user-attachments/assets/c73522d6-2632-422b-b1d1-234e6c61ed2e" /> [1]: https://drive.google.com/file/d/1qJLkFGw4bEclqKihdUI-4bjJofdFArEc/view?usp=sharing [2]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L386 [3]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L611 [4]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L573-L576 [5]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/views/http_routing_template.xml#L139 [6]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L575 Related:https://github.com/odoo/odoo/pull/237262 opw-5167898 Forward-Port-Of: odoo/enterprise#108438 Forward-Port-Of: odoo/enterprise#100142
This update fixes an issue where the 'Call Settings' header in chat windows was visually obscured due to a missing background color. The fix ensures the header remains properly positioned and readable, preventing overlapping text and improving the user experience. This resolves a minor visual inconsistency.
Original PR description
Before this commit, when opening the "Call Settings" in a chat window, the header of the action panel was missing a background color. Because of this, when scrolling down, the Action panel title was floating above the content and the text was overlapping, making it hard to read. This comes from `.bg-inherit` that requires the parented chain to rigorously have `.bg-inherit` too until reaching an actual bg color. In this case, one parent container lacked it, which is what this commit fixes. Task-5867464 (point 84) Before / After <img width="382" height="465" alt="Screenshot 2026-02-24 at 16 06 32" src="https://github.com/user-attachments/assets/f5c4a309-c60a-4e9b-bef0-06ee7ba731b8" /> <img width="386" height="468" alt="Screenshot 2026-02-24 at 16 06 18" src="https://github.com/user-attachments/assets/fea35f8f-2a76-4c40-b51e-28dbfce3a281" /> Forward-Port-Of: odoo/odoo#250398
This update fixes a technical issue related to invoice generation when using BIS3 files for B2C transactions. Previously, R010/R020 checks were performed unnecessarily. Now, these checks only occur when PEPPOL is enabled, ensuring accurate invoice processing for all transaction types.
Original PR description
…peppol checked Some people are using BIS3 files even for B2C. They give the xml files to the accountant for him/her to import the file and generate the invoice in the accounting software. In that case, since it's a B2C transaction, the EndpointId might not be set but that's ok since it's only used to generate the invoice. opw-5952109 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249751
This update corrects a bug where the total hours displayed in the planning Gantt view were inaccurate due to timezone discrepancies. The fix ensures that shift durations are calculated correctly, regardless of the employee's timezone, providing more reliable planning data. This improves the accuracy of time tracking and scheduling.
Original PR description
Description: ----------- When viewing planning shifts in the gantt view, the total hours column displayed wrong totals due to timezone misalignment in work interval calculations. Steps to reproduce:…
Description: ----------- When viewing planning shifts in the gantt view, the total hours column displayed wrong totals due to timezone misalignment in work interval calculations. Steps to reproduce: ------------------- 1. Create an employee with a fixed working schedule (e.g., 8am-12pm, 1pm-5pm with 1-hour lunch break) 2. Ensure the employee's timezone differs from UTC (e.g., Europe/Brussels UTC+1) 3. Create a shift for this employee covering their full working day (8am-5pm) 4. Open the planning gantt view and check the total hours column for that day 5. Expected: 8 hours total | Actual: 7 hours total (with hours misaligned by timezone offset) Root Cause: ----------- In version 19.0, `_gantt_progress_bar_resource_id` used `.replace(tzinfo=pytz.UTC)` when building work intervals, which only changes the timezone label without converting the actual time values. This caused a timezone offset mismatch in the frontend's hour-by-hour comparison. Solution: --------- Replace `.replace(tzinfo=pytz.UTC)` with `.astimezone(pytz.UTC)` to properly convert datetime values to UTC before sending to the frontend. opw-5190244 Forward-Port-Of: odoo/enterprise#104185
This update resolves a rounding issue in the stock barcode functionality that resulted in inaccurate stock quantities being recorded during delivery order processing. Specifically, when scanning barcodes, the system was incorrectly rounding down stock amounts, leading to discrepancies. This fix ensures more precise stock tracking.
Original PR description
To reproduce the issue: - Create a stock quantity of product1 for example of 275.84 kg in PACK1 - Create a delivery order of 3.6 kg - Go to the delivery order on stock barcode - Scan PACK1 - The new line is created as 272.2399999999 Forward-Port-Of: odoo/enterprise#108366 Forward-Port-Of: odoo/enterprise#89300
This update fixes an issue where the FAIA report incorrectly classified partners as suppliers instead of customers, particularly when credit notes were involved. The change allows partners to be correctly identified as both customers and suppliers, ensuring accurate reporting of financial balances. This resolves a discrepancy impacting the SAFT report generation.
Original PR description
1. Create a contact (with minimal details). 2. Create a customer invoice for that contact **last month** with `quantity = 300`. 3. Create a credit note for that invoice **this month**. 4. Create…
1. Create a contact (with minimal details). 2. Create a customer invoice for that contact **last month** with `quantity = 300`. 3. Create a credit note for that invoice **this month**. 4. Create another customer invoice for the same contact **this month** with `quantity = 100`. In the FAIA report (XML), within the General Ledger section, the partner is incorrectly classified as a supplier instead of a customer. In the method _saft_fill_report_partner_ledger_values from account_saft, he partner type is determined based on whether the balance is negative. However, a negative balance can result from a credit note, where the partner is still a customer and not a supplier. Furthermore, a partner can be both a supplier and a customer. This commit allows a partner to be both a customer and a supplier. If both receivable and payable are 0 we set the partner type to customer to keep the behavior from e9640caf29e967fe7d8c6fe303b5a8d7a866437e opw-5360924 Forward-Port-Of: odoo/enterprise#106559 Forward-Port-Of: odoo/enterprise#100749
This update resolves an issue causing errors when editing addresses within the customer portal. The fix ensures accurate address validation by correctly comparing form values with related data, preventing unexpected errors and improving the user experience. This was triggered by a recent change in how address fields were handled.
Original PR description
**Steps to reproduce:** - Create a DB with l10n_ar and l10n_ar ecommerce - Go to Settings > Invoicing > Fiscal Localization - Select the 'Argentina - Argentine Generic Chart of Accounts for…
**Steps to reproduce:** - Create a DB with l10n_ar and l10n_ar ecommerce - Go to Settings > Invoicing > Fiscal Localization - Select the 'Argentina - Argentine Generic Chart of Accounts for Registered Accountants' package - Create a website, and a portal user - Add a main and a secondary address to the user using the website form in 'My Account' - Go to the secondary address and change any field - Click on Save Address - Multiple errors will appear on the form (reproducible with other similar config) (and in logs: `UserWarning: unsupported operand type(s) for "==": 'l10n_latam.identification.type()' == '1'`) **Issue:** In `address_form_fields` some hidden input field are used to add specific non-editable values to the forms. This breaks the address validation of `CustomerPortal` in `def _validate_address_values` due to the following comparison: `partner_sudo[commercial_field_name] != address_values[commercial_field_name]` which try to compare recordsets with the given ids. **Fix:** Cast relational field to their id values to ensure they can be properly compared to the website form values. related fix which introduces the input issue: https://github.com/odoo/odoo/commit/0ee91631214c34b650342a0210ee8db27764f252 opw-5247171 Forward-Port-Of: odoo/odoo#244532
This update fixes an issue where the documentation index wasn't correctly reflecting the latest changes. Previously, the system was relying on cached versions of the documentation, leading to outdated information. Now, the system regenerates the index whenever the 'disable cache' option is selected, ensuring users always see the most current documentation.
Original PR description
Access /doc/index.json with the "disable cache" checkbox from the devtools checked. To index is generated again (emitting warnings in the logs may some docstrings be broken) but it still uses the attachment that was cached by the server. It should not use the server attachment. Reference-to: c67f64d7025c ([FIX] api_doc: respect no-cache directive on index) 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#249504
This update fixes a labeling error in Odoo invoices for Qatar. Previously, the invoice amount description incorrectly used 'Rial'. The change ensures the correct 'Riyal' label is displayed, improving accuracy and compliance for users operating in Qatar. This resolves a minor issue impacting invoice presentation.
Original PR description
Steps to reproduce: 1- Install Accounting and 'l10n_qa' modules 2- Switch to Qatar company and enable "Total amount of invoice in letters" under accounting settings 3. Issue an invoice and preview it The issue: The description of the amount uses "Rial" Expected behavior: The amount should use "Riyal" opw-5919587 Forward-Port-Of: odoo/odoo#250299
This update fixes an issue where kits with multiple components were incorrectly showing a zero cost when using FIFO or average costing methods. Now, the system accurately calculates the total cost of a kit based on its individual components, ensuring accurate inventory and sales reporting. This improves the reliability of kit costing within the Odoo system.
Original PR description
Before this commit, if a kit had multiple components, the cost of the line was counted as zero if the product cost method was FIFO or average. opw-5911338 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247833
This update fixes a technical issue that caused unnecessary website updates and potential errors during the website builder process. By preventing redundant loading effect mutations, the system now operates more smoothly and reliably, particularly when the website builder is immediately launched after a button click.
Original PR description
__Before commit__ When using `makeButtonHandler`, a loading effect is applied to the button if the handler takes more than 400ms to execute. However, if the handler finishes sooner, the effect is…
__Before commit__ When using `makeButtonHandler`, a loading effect is applied to the button if the handler takes more than 400ms to execute. However, if the handler finishes sooner, the effect is still briefly added and removed, triggering a DOM mutation. If a button is clicked and the website builder opens immediately after, this mutation may be recorded in the current history step despite being unnecessary. This causes the `design-themes` tour `theme_menu_hierarchies` to fail in a non-deterministic way with the following warning: "should not have any 'characterData', 'remove' or 'add' mutations in current step when you update the selection" __Fix__ Ensure the loading effect is never added if the handler execution time is shorter than the debounce duration. This fix is applied to both `makeButtonHandler` functions in the codebase. The test case is only added for the interaction use case, as the other instance resides in legacy code. runbot-229803 Forward-Port-Of: odoo/odoo#248242
A recent update to the Odoo mailing builder caused a crash when using company team snippets. This fix corrects a renaming issue within the system, ensuring the builder functions correctly and avoids unexpected errors. The change updates a component name to resolve a compatibility problem.
Original PR description
The `Img` component was renamed `Image` in commit [1]. In the forward port [2], a template with usage of `Img` was not updated to use `Image` instead, resulting in an issue when using the company teams snippet. How to reproduce: - create a new mailing using the builder - add the s_company_team_shapes snippet - click on an `<img>` element Issue: - crash (Img component is missing) Solution: - rename Img to Image [1]: https://github.com/odoo/odoo/commit/a22e22acacc9d54f39d0f07acc3054cd2a33f61e [2]: https://github.com/odoo/odoo/commit/d2b56435736e8d507434c1378cb68fae23e8511f task-5963711
A minor bug preventing users from selecting a cashier when opening the Point of Sale (POS) has been resolved. The issue stemmed from a renaming of a variable without updating related references, causing an error. This fix ensures a smooth and reliable POS experience for users.
Original PR description
Since this commit: https://github.com/odoo/enterprise/commit/52e2f216528bcb0e67844ac2164f647fee4a2a95 The clockState variable was renamed without modifying the other references. This causes a traceback when trying to select a cashier while opening the POS. This has now been fixed by restoring the previous variable name.
This update resolves an issue where users could trigger a type error when creating custom domain filters in the sale order list. The fix ensures that a field name is always provided, preventing the error and allowing users to successfully apply filters. This improves the stability and usability of the sales order management feature.
Original PR description
Currently, an error occurs when user tries to validate a domain with no field name. Steps to install: - Install `sale_management` > Open sale order list view > Turn on debug mode. - Click on search…
Currently, an error occurs when user tries to validate a domain with no field name.
Steps to install:
- Install `sale_management` > Open sale order list view > Turn on debug mode.
- Click on search bar > Custom filter > Click on field and remove its field name written below the list of fields.
- Click validate.
Error:
```
TypeError: Empty field name in condition ('', '=', 1)
```
Cause:
- As the field name was emptied by the user the [line] will raise a TypeError during the domain validation.
- Till `19.0` any error during domain validation was handled through [here] which was later changed to handle only ValueErrors through this [commit].
Solution:
- Handled TypeErrors during domain validation.
[line]: https://github.com/odoo/odoo/blob/260b9c0417ed2278429fcdd7f50d61786d4e9beb/odoo/orm/domains.py#L841
[here]: https://github.com/odoo/odoo/blob/a220fb71c036c93fa1e75d4d37127e5eda0118f9/addons/web/controllers/domain.py#L34
[commit]: https://github.com/odoo/odoo/commit/a1434c32e9f4dd226d512677fd96e3051b908d8b#diff-e5da86414a8020b2843fb359453238e4977027d30f73f1fa792ca63ddd8fa2a7L34-R23
sentry-7278978488
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue where the website builder's tab selection was disrupted when sections were hidden and translated. Specifically, the builder switched to a fallback tab instead of the 'customize' tab. This fix ensures the builder consistently displays the correct tab when working within the translate environment, improving user workflow and accuracy.
Original PR description
With commit 3a80ac79c5b0193911e8ddab442660b315562639, the builder option plugin is not a custom one in translate. And the builder option plugin automatically switches to a fallback tab (instead of customize tab) when containers are de-activated. This happens when the user hides an invisible element. This commit fixes it by skipping swithing to fallback tab if the builder is in translation mode. Steps to reproduce: - Open website builder - Drop a section - Make it invisible on desktop - Add a language to the website - Open builder in translate mode - Click on the eye of invisible elements to show the invisible section - Click again to hide it - Bug: the sidebar left the "customize" tab and switched to "block" tab task-5475107
This update resolves an issue where archived employees were still visible in the attendance Gantt view. The change ensures that only currently active employees are displayed, improving the accuracy and clarity of the attendance reporting tool. This prevents confusion and ensures data reflects the current employee status.
Original PR description
Steps to reproduce: 1. install `hr_attendance_gantt` 2. create an employee 3. make attendance records for the employee in the previous months 4. archive the employee When opening the gantt view of the attendance, a row appears for the archived employee, with no attendance showing up. This commit adds a constraint to only show the active employees. opw-5490119 Forward-Port-Of: odoo/enterprise#107613 Forward-Port-Of: odoo/enterprise#106486
This update addresses a critical maintenance task, updating tax codes in the Odoo Enterprise system after a 4-year period. This ensures continued accurate tax calculations and avoids potential disruptions to financial reporting. A future enhancement will allow users to initiate this update automatically.
Original PR description
It's been 4 years since the last update [1]. No codes were removed. At some point it would be nice to add this to the avatax_sync_company_params() method so it can be initiated by the user. But we need to update this file regardless, and the mechanism would need to be smart enough to not cause duplicates when e.g. the user has synced it themselves, we then update the csv and they then update the module. [1] https://github.com/odoo/enterprise/pull/30220 opw-5928245 Forward-Port-Of: odoo/enterprise#108209
This update fixes an issue where warehouse names with only numbers (like '01') were displayed incorrectly in the barcode app. The fix removes a browser setting that caused numerical warehouse codes to be reversed, ensuring they are always shown in the correct order. This improves the user experience when scanning products.
Original PR description
### Steps to detect the bug: - Download stock apps - Enable "storage locations" settings under warehouse index - Change name of warehouse with a name composed only of numbers (ex. 01) - Create a…
### Steps to detect the bug:
- Download stock apps
- Enable "storage locations" settings under warehouse index
- Change name of warehouse with a name composed only of numbers (ex. 01)
- Create a product (with barcode number)
- Insert a number of products available with smart button "on hand"
- Create a new delivery for that product
- Go to barcode app and search for the delivery you just created
- Click on it and see that the name of the warehouse will be stock/01 instead of the correct 01/stock
### The problem:
The previous configuration used direction: rtl; on the warehouse name
element in the barcode app. So if the string contains only letters the
standard visual order is maintained, however, when the string consists
entirely of numbers the rtl property forces the browser to reorder them
from right to left.
### The reson to introduce the fix:
By removing this property, it is ensured that numerical warehouse codes are displayed in their natural sequence without being flipped.
opw-5730199
Forward-Port-Of: odoo/enterprise#107920Features or functions removed from Odoo
This update removes unnecessary call buttons from the AI-powered live chat feature. This simplifies the user interface and improves the overall experience for users interacting with the AI agent. The change is a technical fix to streamline the live chat functionality.
Original PR description
This commit will remove call buttons in livechat with ai agent. Task-5932845
1 change
Enhancements to existing features
This update enhances the Spanish tax reporting functionality within Odoo Enterprise by incorporating data from 'page 2 bis' into the 390 boe report. This addition ensures more complete and accurate tax reporting for Spanish businesses, aligning with local regulations. The change supports a key requirement for compliance with Spanish tax requirements.
Original PR description
In this commit: - We are adding representation of page 2 bis to the 390 boe.txt task-5881396 Forward-Port-Of: odoo/enterprise#106861
1 change
Resolved issues and error corrections
This update fixes an issue where salary calculations for employees on attendance-based contracts were incorrect. The system now accurately determines hourly rates for various allowances by using the employee's planned working schedule instead of their recorded attendance hours, ensuring accurate payroll processing for this contract type.
Original PR description
Step to Reproduce: - install UAE Payroll localization and attendance - create employee and running employee contract and give basic salary, housing, transportation and other allowance. - work entry source should be attendance - create a payslip and compute sheet. Issue: - The values for payslip lines are not as expected. - The rate per hour for basic salary , housing, transportation and other allowances was being calculated based on employee's attendance work entries, not the planned working schedule. Reason: - When using attendance-based contracts, the hourly rates for basic salary, housing, transportation, and other allowances should be calculated based on the working schedule's hours per day, if a working schedule is available. Solution: - Instead of sum_worked_hours which takes working hours of employee's work entries, use total_number_of_days multiplied by the hours per day from the working schedule. task-5270185 Forward-Port-Of: odoo/enterprise#103282
15 changes
Enhancements to existing features
This update enhances how the HR payroll system communicates with the server. It now allows for additional information to be passed with requests, ensuring the system can properly handle requests originating from the portal. This prepares the system for a future change in how messages are fetched, improving reliability and security.
Original PR description
This is a preparation change for replacing the portal chatter fetch route with the mail fetch route. Fetch methods can now receive extra fetch params from the caller components if needed, making it possible to inform the server when a request originates from the portal. This allows the server to apply specific limitations required for portal chatter. The change also involves a minor refactoring of the `useMessageScrolling` hook, which makes the thread built-in and removes the need to pass it as a parameter in every call. Extra fetch params could also be passed through another callback in the same way. [Community PR](https://github.com/odoo/odoo/pull/248208)
This update simplifies the kitchen view by merging free and priced lines for combo products when appropriate, reducing clutter and improving usability. The system now intelligently manages similar order lines, splitting them when necessary to ensure accurate updates and a cleaner user experience. Attribute changes are highlighted in red for better visibility.
Original PR description
In this commit:
-------------------
- Merged free and priced lines for the same product in the kitchen view, as separate lines are unnecessary in kitchen.
- Implemented logic to find sibling lines with the same product, notes, and attributes.
- If no difference found between the key values mentioned, search for a suitable sibling to merge with.
- If differences are detected (other than notes), lines are split to act independently.
- If only notes differ, and later both lines become identical again update a line with the same UUID as once they are splitted shouldn't be reflected to the sibling line's change.
- Updated attribute display, attributes are now shown in red for better visibility.
task- 4752080
Related PR: https://github.com/odoo/odoo/pull/208251This update replaces generic placeholder images with new, consistent icon images throughout the Odoo Enterprise platform. This improves the visual appeal and clarity of various modules, enhancing the user experience. The changes address outdated icons and streamline the user interface.
This update enhances payroll warning notifications by allowing administrators to select specific recipients – admins, officers, or assistants – for these alerts. The changes also include a new, user-friendly interface for choosing the recipient type, improving the clarity and control over who receives payroll warning emails.
Original PR description
- In warnings of payroll, I did few adjustments. - The tab's name is changed from Misc to Communication in the form view. - Changing the mechanism for specifying email reicipient: . New field (email_visibility_type) is added to select the email will go to whom (Admin, Officer, Assistant) . In method _cron_payroll_warning_email_alert, according to the email_visibility_type of the warning the suitable payroll group is selected. task - 5473707
This update enhances the performance of account reports by directly accessing data within the line dictionary. Previously, the system had to retrieve this information through a separate browse operation, which was a performance bottleneck. This change streamlines the process, resulting in faster report generation.
Original PR description
This commit will include the code in the line dict to allow the _custom_line_postprocessor function to access it directly and avoid a browse on the line object to retrieve the value. no task id
This update allows users to manage multiple bank statement lines simultaneously, streamlining the reconciliation process. The changes include the ability to apply accounts and partners to multiple lines, improving efficiency and reducing manual effort. This enhancement focuses on usability and expands functionality within the bank reconciliation workflow.
Original PR description
This commit will allow to do the set account, set partner and apply reco models on multiple lines. To select multiple line you need to use alt + click and then you will have button on top to trigger the actions. - The set partner function was modified to work with multiple statement lines and keep all existing functionality (modify line with same partner_name) - The trigger reconcile model function was also modified to work with multiple statement lines - The set account function was not touched because we use the aml_id of the suspense as a parameter but here we will have multiple suspense line to modify. Since we are doing this change in stable, we created a new function set_account_multiple_bank_statement_line. This function will have the same behavior for reco models as the basic set account. task-5253778 Forward-Port-Of: odoo/enterprise#108261 Forward-Port-Of: odoo/enterprise#100316
This update clarifies that commission adjustments can only be created using users who belong to approved sales plans. Previously, adjustments could be linked to any active plan, leading to confusion and incorrect user selections. This change improves the accuracy and usability of commission management.
Original PR description
Before this commit, when defining ajustment, the add_user_id and reduce_user_id could belong to any kind of active plan. It would make difficult to select the correct user when multiple plans were available. This commit ensure only approved plan can be used to create ajustments. Forward-Port-Of: odoo/enterprise#106637
This update enhances the visual clarity and readability of AI responses within the discuss app. Changes include formatting tables and code snippets, improving the overall user experience and making AI interactions more intuitive. The update also optimizes conversation titles for better alignment with popular AI platforms.
Original PR description
* = ai_knowledge, ai_livechat, test_full_discuss_enterprise In this commit, we "overhaul" the way that AI messages are rendered. This effort was motivated not just by aesthetics but also to make the…
* = ai_knowledge, ai_livechat, test_full_discuss_enterprise In this commit, we "overhaul" the way that AI messages are rendered. This effort was motivated not just by aesthetics but also to make the AI responses more readable and understandable for users. The first change was to inject boostrap classes to the tables added by the markdown library. By doing that, we make tables render as tables with borders and highlighting, instead of just text. We also added the prism library in the modules assets. Now, if the AI replies with some code snippet, it will be highlighted depending on the language used. We also added different CSS rules in `chat.scss` to changed some of the front end details like the padding and margin between elements in messages. In said file, we also changed some display and width values, to make tables and code segments horizontally scrollable, so information won't get "smushed" in a chat window. We also limit the width to 75% of the AI response in the discuss app because otherwise the information was too spread out - we added a media query to return the width to 100% in smaller screens. We moved the "Expand in Discuss" button, to be inbetween the close button and the minimise button, because the dropdown was confusing users, who imagined that they can switch between agents directly from the chat window. We additionally, made it so conversation titles change based on the user's first query, similarly to how it is done in the web versions of ChatGPT or Gemini. For that, we initial create channels with the name field empty and then we extend the display_name compute method of the discuss channel to add the agent's name in case the name is empty. After the first message we populate the name field which should by extension change the display_name field. We heavily patched the message template to remove the bubble and apply classes for the css rules. We also made it so user messages remain in the right in the discuss app (like in chat windows), increasing visual clarity. Finally, the test_natural_language_query_tour was modified to check for the new descriptive chat window title feature and the test_create_ai_chat was modified to reflect the new way of creating ai chats - with empty name and populated display_name. Task-5164382 Forward-Port-Of: odoo/enterprise#108080
This update adjusts how end-of-service benefits are calculated in Odoo Enterprise, aligning with recent regulations in Egypt. The calculation now directly uses the number of years worked, providing half a month's benefit for the first five years and a full month for subsequent years. A minimum one-year employment period is required for the benefit to be applied.
Original PR description
Changed how the end of service benefit is calculated, to depend directly on the number of years worked. The first five years grant half a month each to the EoS benefit, and the following years grant a full month each. Task-5018907
Resolved issues and error corrections
This update fixes a critical issue where mandatory fields were incorrectly included in signature validation, forcing users to sign them. Now, automatic completion is enabled for these fields, and a clear placeholder is used when the auto-field is empty, improving the user experience and data accuracy.
Original PR description
Before this commit, constant required sign fields with auto_fieldwere incorrectly included in signature validation, forcing users to sign them. Additionally, when auto_field had no value, these fields remained empty instead of using placeholder text as fallback. After this commit, constant required fields are excluded from signature validation, allowing automatic completion. When auto_field returns no value, the placeholder or item type name is used, providing a more clear and informative fallback content for users. task-5886200
This update resolves an issue where users with limited accounting access (read-only) were encountering errors when viewing invoices or partner details. The change ensures that the 'addenda_ids' field is only displayed to users who have the necessary permissions, improving stability and usability.
Original PR description
User with "read-only" access to accounting will trigger an error if they try to open an invoice or partner due to field addenda_ids. This commit aims to render this field only if the have the right to fetch it. opw-5931178 opw-5954244 Forward-Port-Of: odoo/enterprise#108332
This update ensures that essential products like 'settle due' and 'deposit' are automatically configured for all Point of Sale (POS) settings within the Odoo Enterprise system. Previously, these products were only available in POS sessions without open sessions, causing potential issues. Now, all POS configurations will have these products set, streamlining operations and preventing errors.
Original PR description
Before this commit, when the module pos_settle_due was installed, the special products (settle due, deposit, settle invoice) were only set on the POS configurations that did not have any open session. This could lead to issues when trying to use these products in a POS session of a configuration that did not have them set. Now, the special products are set on all POS configurations when installing the module. Community PR: https://github.com/odoo/odoo/pull/229074 Forward-Port-Of: odoo/enterprise#96788 Forward-Port-Of: odoo/enterprise#95789
This update corrects a restriction preventing HR officers from creating new employees in the Belgian version of the HR Payroll module. The fix utilizes 'sudo' to grant necessary access to a key field, allowing users with standard HR officer permissions to complete the employee creation process without encountering errors. This ensures seamless employee onboarding for our Belgian clients.
Original PR description
Steps to reproduce: - Install l10n_be_hr_payroll - Have a user with only HR officer rights - Try to create a new employee with that user (in BE) - You have an access error on the field l10n_be_resident_situation The field `l10n_be_resident_situation` has the HR Payroll officer group. This field is used on the inverse of the is_non_resident field, which is accessible to HR officers. This commit fixes the issue by using sudo to read the field's value. task-5779779 Forward-Port-Of: odoo/enterprise#108492 Forward-Port-Of: odoo/enterprise#104888
This update ensures payslips accurately reflect an employee's actual start date with the company, regardless of internal job changes. Previously, payslips used the contract start date, which wasn't ideal for employees with multiple periods of employment. This change improves payroll accuracy and reporting, particularly in Switzerland and the UAE.
Original PR description
In the payslip definition, the current contract's start date is used. But if a person changes job or contract internally we don't want this value to change and we want it fixed to when the person joined the company. Notably, if a person worked at the same company in two well distinct periods, we want to consider the beginning of this period and not of the previous one(s). Since Switzerland uses a custom report for the payslip, the same change is applied there. Task: 5909637 Community PR: https://github.com/odoo/odoo/pull/248598 Forward-Port-Of: odoo/enterprise#108145 Forward-Port-Of: odoo/enterprise#106692
Features or functions removed from Odoo
This change simplifies the Frontdesk module by removing a redundant 'Invite teammates via email' option. Recent updates to the system's user interface widgets introduced this option, but it wasn't needed for the Frontdesk workflow. This ensures the user interface is cleaner and more focused on its core functionality.
Original PR description
In responsible_ids, we were using the ***many2many_avatar_user*** widget. After recent changes introduced in https://github.com/odoo/odoo/pull/209886, the widget now shows an ***"Invite teammates via email"*** option when creation is enabled ***(enabled: () => this.activeActions.create).*** Since creating new users from this field is not required in the Frontdesk flow, this commit adds the ***'no_create'*** option to disable record creation. As a result, the ***"Invite teammates via email"*** entry is no longer displayed. This ensures the field only allows selecting existing users and keeps the UI aligned with the intended behavior. Task-5929325
4 changes
Enhancements to existing features
This update enhances the restaurant order display by allowing users to group preparation cards by course (e.g., Appetizer, Main Course, Dessert). This provides a more organized and intuitive view of the order preparation process, making it easier for staff to manage and track items.
Original PR description
Adds the possibility to organize the preparation display by course instead of a flat list of orders. - Preparation Display: Added 'organize_by_course' boolean field to the configuration model and form view. - Frontend Display: Implemented a new layout that groups order cards under labeled course headers (e.g., "Course 1", "Course 2") when the option is active. task-id: 5969167
Resolved issues and error corrections
This update resolves an issue where the payroll data update process would fail when the 'Standard 40 hours/week' working schedule was deleted. The fix ensures the system correctly handles the absence of this schedule, preventing errors and maintaining accurate payroll calculations for supported countries. This ensures consistent payroll processing across multiple regions.
Original PR description
*:ae,au,bd,be,ch,eg,id,jo,ke,lt,lu,ma,my,nl,pk,pl,ro,sk,tr,us When the ``Standard 40 hours/week`` working schedule is deleted and the ``Payroll: Update data`` cron runs, a traceback is raised. For…
*:ae,au,bd,be,ch,eg,id,jo,ke,lt,lu,ma,my,nl,pk,pl,ro,sk,tr,us
When the ``Standard 40 hours/week`` working schedule is deleted
and the ``Payroll: Update data`` cron runs, a traceback is raised.
For ``l10n_us_hr_payroll`` module
Steps to reproduce the error:
- Install ``l10n_us_hr_payroll`` module with demo data
- Go to Employees > Configuration > Settings > Change Company Working Hours
- Go to Working Schedules > Delete ``Standard 40 hours/week`` working schedule
- Run the ``Payroll: Update data`` cron
Traceback:
```py
ValueError: External ID not found in the system: resource.resource_calendar_std
ParseError: while parsing /home/odoo/src/enterprise/l10n_us_hr_payroll/data/hr_payroll_structure_type_data.xml:3, somewhere inside <record id="structure_type_employee_us" model="hr.payroll.structure.type">
<field name="name">United States: Employee</field>
<field name="default_resource_calendar_id" ref="resource.resource_calendar_std"/>
<field name="country_id" ref="base.us"/>
</record>
```
The ``Payroll: Update data`` cron updates payroll data that references
the ``Standard 40 hours/week`` working schedule.
If the user has deleted this working schedule, the external ID no longer exists,
leading to the above traceback.
sentry-7166574553This update resolves an error that occurred when computing payslips with salary rules that used hidden input fields. The issue stemmed from how the system tracked folded input sections, leading to a data type mismatch. This fix ensures that these hidden inputs are correctly ignored during payslip calculations, preventing errors and ensuring accurate payroll processing.
Original PR description
**Steps to reproduce** - Have a salary rule - Condition based on: Salary Input - Input on: Employee - On the employee form, click on "Add inputs" in the Payroll tab - Add an input - Enter a value - Click on "Inputs" to fold the section and hide the input - Try to compute a new payslip for this employee, error: `ValueError: invalid literal for int() with base 10: 'separator_1'` **Cause** By default, the separator doesn't have a `value` key, but after the first interaction to hide its elements, it is added to keep track of the folded state (see `_toggleSeparators` in `web`). **Solution** Ensure separators are ignored. opw-5928247
This update fixes a bug where the planning report generated through the standard print menu produced blank PDFs. The fix ensures users are directed to the correct Print button in the calendar view to generate the report, preventing errors and ensuring accurate report output.
Original PR description
**Problem:** When users in debug mode manually add the planning report action through Settings/Technical/Reports and then print from the list or form view, they receive a blank/invalid PDF report.…
**Problem:** When users in debug mode manually add the planning report action through Settings/Technical/Reports and then print from the list or form view, they receive a blank/invalid PDF report. **Steps to reproduce:** 1. Go to Settings app and enable debug mode 2. Navigate to Technical → Reports 3. Search for "slot_report" 4. Click "Add to print menu" button 5. Refresh the browser 6. Go to Planning app and switch to list view 7. Select a few planning.slot records 8. Click Print → Planning **Current behavior:** A blank or invalid PDF is generated. **Expected behavior:** Users should receive a clear error message directing them to use the correct print method from the calendar view. **Cause of the issue:** The planning report requires a pre-processed data structure (weeks, grouped slots per day/week, and group-by mappings) that is only prepared by the action_print_plannings() method called from the custom Print button in the calendar view. The standard print menu invokes _render_qweb_pdf() directly without this data preparation, and there is no mechanism to pass this complex data structure through the standard print workflow. This results in the template receiving empty data contexts, producing blank reports. **Fix:** Block the planning report from being printed through _render_qweb_pdf() when called without the proper data context. This is done by checking if the report name is 'planning.slot_report' and raising a UserError with a clear message directing users to use the Print button in the calendar view instead. This prevents the generation of invalid reports while guiding users to the correct workflow that properly prepares the required data. opw-5477184
7 changes
Resolved issues and error corrections
This update fixes an issue where custom analytic distributions on sales order lines were being reset to the default model distribution when the order was confirmed. Previously, users couldn't maintain their specific distribution settings. Now, custom distributions will be preserved, ensuring accurate tracking of costs within project sales.
Original PR description
*: project_purchase, sale_project --- Decription of the issue this commit addresses: When confirming a sales order with a product-partner combination that has an Analytic Distribution Model assigned,…
*: project_purchase, sale_project --- Decription of the issue this commit addresses: When confirming a sales order with a product-partner combination that has an Analytic Distribution Model assigned, any custom analytic distribution done on the line of the product will be lost, resetting the analytic distribution to the default value set on the Analytic Distribution Model. --- Steps to reproduce: 1. Install sale_project,project_purchase. 2. Activate "Analytic Accounting" in the settings. 3. Create a new Product "test"; Type: Service, Create on Order: Project. 4. Create a new Analytic Distribution Models; Partner: Acme, Product: test, Analytic Distribution: anything but blank. 5. Create a new Quotation in the Sales apps; Partner: Acme. 6. Assign the Product test to the first order line. This will automatically set the analytic distrib of the Analytic Distribution Model. 7. In the Analytic Distribution cell, add a line with any non null distribution. 8. Confirm the Quotation. 9. The analytic distribution that was anually added has been removed. Only the default analytic distribution of the model remains. --- Desired behavior after this commit is merged: Any custom analytic distribution done on a line is never lost. The Analytic Distribution Model's distribution serves as a template but never overrides the values set by the user. --- opw-4934291 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a minor issue within the employee departure process. Previously, archiving an employee used an outdated method. Now, the system correctly utilizes the 'action_archive' method, ensuring employees are properly removed from records when departing, aligning with enterprise standards.
Original PR description
When archiving an employee from the departure wizard, use the action_archive method instead of toggle_active. Related to odoo/enterprise#100437 task: 5354002 Forward-Port-Of: odoo/odoo#247224
This update fixes a problem where archived employees caused conflicts when managing appraisal plans. The fix ensures that archived employees' appraisal dates are cleared, preventing errors when setting appraisal plans for active employees. This improves the stability and usability of the appraisal management feature.
Original PR description
**Steps to reproduce:** Based on this feedback https://www.odoo.com/odoo/project.task/5270281 companies with archived employees face an issue when they try to toggle Appraisals Plans from Appraisls -> Configuration -> Settings -> Appraisals Plans **Issue:** The propblem is that when employees with next appraisal date are archived, their next appraisal date is not cleared which leads to past date conflicts upon trying to set the next appraisals dates for all the employees (which is done through toggling the Appraisals Plans checkbox) **Solution:** - Unset the next appraisal date upon archiving an employee - exclude archived employees from _compute_next_appraisal_date method Task: 5354002 Forward-Port-Of: odoo/enterprise#100437
This update corrects a bug where invoices created by users in time zones before Saudi Arabia could be incorrectly dated in the future, leading to ZATCA rejection. The change ensures invoice dates are properly aligned with Saudi Arabia's time, preventing future invoicing issues and maintaining compliance.
Original PR description
In odoo/odoo#236865 we decided to allow clients to backdate invoices by letting them use the `invoice_date` field for the invoice date and use the current time as the issue time because we are not supposed to use a dummy value for time. This created an issue where if a user in a timezone before SA tries to invoice a document around midnight using the current date in SA the datetime created will be in the future which will lead to the invoice being rejected by ZATCA. This commit makes sure we normalize the selected date wrt to the current datetime in saudi arabia so that we never accidentally invoice into the future. task-5890423 opw-5373067 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246311
This update resolves an issue where a 100% discount on German Point of Sale (POS) orders would cause an error. The change ensures the system handles 100% discounts correctly, preventing disruptions to the sales process. This improves the reliability of the German POS functionality.
Original PR description
Backport of https://github.com/odoo/enterprise/pull/98869 opw-5240429
This update fixes an issue where VAT amounts were incorrectly displayed as zero in XML exports for manual journal entries. The fix removes a faulty condition in the SQL query, ensuring accurate VAT calculations (MHT, TVA, TTC) are generated for standard journal entry lines. This ensures accurate tax reporting for MA Company users.
Original PR description
## Issue: When creating a manual journal entry with a deductible tax, the entry was included in the XML export, but the VAT amounts were all set to 0 ## Cause: The SQL query used to compute VAT amounts included an extra condition on display_type to be 'tax' However, journal entry lines are standard product lines and should not be excluded by this condition As a result, the amounts (MHT, TVA, TTC) were incorrectly computed as 0 in the XML ## Steps to reproduce: - Install `l10n_ma_reports` and switch to the MA Company - Create a Journal Entry (Any account, Debit: 100, Taxes: 10% 150) - Open the Tax Report for the current month - Export the XML using the gear icon Before the fix, the value for mht, tva and ttc where all 0 opw-5226529
This update fixes a technical error that prevented users from sharing course content hosted externally (like Google Drive). The issue stemmed from a browser security restriction, and the fix ensures smooth sharing functionality without errors. This improves the user experience for sharing content.
Original PR description
Step to reproduce: 1. Install `website_slides` 2. Open any course and add content 3. Select the `Document` type and upload a Google Drive link 4. Save and publish the content 5. Click the "Share" button for this specific content in full screen Issue: - A traceback occurs: `Uncaught Javascript Error > Failed to read a named property 'document' from 'Window': Blocked a frame with origin "http://localhost:3000" from accessing a cross-origin frame.` Cause: - The `_onClickShareSlide` method attempts to calculate the `documentMaxPage` by accessing the internal DOM of the slide's iframe (`iframe.contentWindow.document`). When the content is hosted externally the iframe source is cross-origin. Browsers enforce the Same-Origin Policy. Solution: - Check the origin of the iframe's source URL before attempting to get max page. opw-5422655
6 changes
Resolved issues and error corrections
This update corrects a display issue where the footer text was missing from Argentine invoices. The problem stemmed from a missing field definition in the invoice XML file. Now, the footer text will correctly appear at the bottom of invoices generated for Argentina companies, ensuring accurate and complete documentation.
Original PR description
Steps to reproduce: 1- Install Accounting and 'l10n_ar' modules 2- Switch to Argentina company, go to [Settings -> Configure Document Layout] and make sure there is some text in the footer field 3- Issue an invoice and preview it The issue: The footer text is missing at the bottom of the invoice Expected behavior: The footer text should be displayed at the bottom Why this happens? The xml file was missing the field definition of the footer text opw-5927246
This update resolves a problem where ZATCA invoices were being sent with an incorrect issue date due to timezone differences. The fix ensures the invoice date is accurately formatted for ZATCA submission, preventing a common error and improving invoice processing for Saudi Arabia. This change addresses a technical issue related to ZATCA compliance.
Original PR description
When sending an invoice to ZATCA between 21:00 and 23:59 UTC, the following ZATCA error appears: [400] BR-KSA-04: The document issue date (BT-2) must be less than or equal to the current date. This is caused by the field l10n_sa_confirmation_datetime in _post of l10n_sa/account_move, which combines the date and the time in UTC. In _export_invoice_vals, we reconvert this field to UTC+3 (Asia/Riyadh). Example: Current time UTC+3: 2026-02-19 02:45:00 Stored as UTC: 2026-02-18 23:45:00 (Before the fix) Sent to ZATCA as UTC+3: 2026-02-20 02:45:00 (in the future) (After the fix) Sent to ZATCA as UTC+3: 2026-02-19 02:45:00 opw-5450479 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where users generating leads without credits received a confusing error message. The change now correctly handles cases with no credits, providing a more user-friendly experience. This ensures a smoother process for lead generation within the CRM system.
Original PR description
Before this commit, when the user uses CRM to generate new leads and does not have credits, the error message they would get is "Your request did not return any result (no credits were used). Try removing some filters." This commit fixes this in _perform_request by instead of expecting InsufficientCreditError raised it now expects the credit_error flag to be set. task-5925047
This update fixes a limitation in the General Ledger export by ensuring that branch accounts linked to parent company accounts are now included. Previously, the system excluded these lines, leading to incomplete reporting. This change improves the accuracy of financial reports for branch operations.
Original PR description
The PR #103329 explicitly excludes `account.move.lines` with accounts that do not match their company. However, branches can use the accounts of their parent company, and thus these lines should be reported in a General Ledger export. [opw-5499234](https://www.odoo.com/odoo/unassigned-tasks/5499234)
This update quietly handles errors that occur during tour termination, specifically 'AssetsLoadingError', which represents lazy-loaded assets. Previously, these errors were flagged incorrectly, and this change ensures they are no longer displayed, improving the user experience. This is a minor fix to enhance stability.
Original PR description
Similarly to commit https://github.com/odoo/odoo/commit/493bab4f460dd4069d5cb6805933b8088067ff17 hiding "failed to fetch" errors, this commit adds AssetsLoadingError as those represents "just" another category of failed assets request (i.e. lazy loaded) after tour termination. runbot-233826
This update restores a previously removed method within the HR holiday attendance module. This was done to accommodate customizations that may still rely on the method, with a clear note indicating its future removal in the main Odoo version. This ensures continued functionality for existing users while maintaining a path to eventual removal.
Original PR description
In https://github.com/odoo/odoo/pull/229723, we removed the `_update_leaves_overtime` method as it was moved to another model, however, the method could still be in use in customizations so we restore it here add a comment that states it will be removed in master.