Daily updates from Odoo
Tuesday, October 14, 2025
213 changes
17 changes
Resolved issues and error corrections
Fixed an issue where creating or assigning a future vehicle driver could incorrectly mark the wrong vehicles as planned for change. This helps fleet managers keep vehicle handover statuses accurate and avoid confusion about which cars are due to be changed.
Original PR description
WHen a new vehicle is created for someone in a non waiting column, we are settign his other cars in plan_to_change. When we set a future driver on a car, we set the others as plan to change, but not the one on which we are setting the future_driver --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230952
The attendance auto-checkout process now correctly handles open check-ins from previous days, such as after a long server shutdown. This helps keep employee attendance records accurate without manual correction.
Original PR description
Problem: the auto-checkout feature was basing the computation on the fact that the unclosed attendance was starting today. However, it might not always be the case, for example if the server is shutdown for more than 24 hours after checking in. Steps to reproduce: - Activate the auto-checkout feature - Create an open-ended attendance for two days ago - Run the cron - Result: the attendance is not closed. This commit solves the issue by taking into account the days delta between today and the check-in date. task-5082359 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#227981
This fix corrects how the Belgian reports partner form is linked so updates no longer fail when the citizen identification field is required. It helps ensure module upgrades run smoothly without server errors related to this form view.
Original PR description
The citizen_identification field was added to the partner view in l10n_be_reports, but the form 281.50 view for this required field was incorrectly inheriting from the base partner view. That led to…
The citizen_identification field was added to the partner view in l10n_be_reports, but the form 281.50 view for this required field was incorrectly inheriting from the base partner view.
That led to a traceback when updating account_reports/l10n_be_reports modules in 19.0+ versions:
This fix PR is a backport requested from upgrade: https://github.com/odoo/enterprise/pull/92104#pullrequestreview-3144302023.
```py
Odoo Server Error
Occured on 86642809-master-all.runbot135.odoo.com on model ir.module.module on 2025-08-11 14:04:32 GMT
Traceback (most recent call last):
------- A lot of calls ------
convert_xml_import(env, module, fp, idref, mode, noupdate)
File "/data/build/odoo/odoo/tools/convert.py", line 745, in convert_xml_import
obj.parse(doc.getroot())
File "/data/build/odoo/odoo/tools/convert.py", line 616, in parse
self._tag_root(de)
File "/data/build/odoo/odoo/tools/convert.py", line 559, in _tag_root
f(rec)
File "/data/build/odoo/odoo/tools/convert.py", line 570, in _tag_root
raise ParseError(msg) from None # Restart with "--log-handler odoo.tools.convert:DEBUG" for complete traceback
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
odoo.tools.convert.ParseError: while parsing /data/build/enterprise/account_followup/views/partner_view.xml:4
Error while parsing or validating view:
Element '<xpath expr="//field[@name='citizen_identification']">' cannot be located in parent view
View error context:
{'file': '/data/build/enterprise/account_followup/views/partner_view.xml',
'line': 1,
'name': 'res.partner.view.form',
'view': ir.ui.view(5824,),
'view.model': 'res.partner',
'view.parent': ir.ui.view(127,),
'xmlid': 'res_partner_view_form'}
```
Forward-Port-Of: odoo/enterprise#96855This fixes an issue where returning a regular product from a rental order could leave the sale order showing the wrong delivered quantity. Businesses using rental workflows will now see more accurate delivery status and quantities after returns are processed.
Original PR description
**Issue**: Returning a non-rental product in a rental order does not correctly update the delivered quantity. **Steps to reproduce**: - Enable rental transfers via Settings > Rental. - Create a…
**Issue**: Returning a non-rental product in a rental order does not correctly update the delivered quantity. **Steps to reproduce**: - Enable rental transfers via Settings > Rental. - Create a rental order with (in that order!): - A rental product - A non-rental product - Confirm the rental order. - Open the related sale order. - Go to the delivery and validate it. - Return the delivery and validate the return. - Observe that the delivered quantity in the sale order is incorrect. **Cause**: The [_get_outgoing_incoming_moves](https://github.com/odoo/odoo/blob/ea6776f095d556e3429d2b847a66f78f2e866380/addons/sale_stock/models/sale_order_line.py#L200C17-L200C85) method fails to detect incoming moves when the destination location has `usage='internal'` (as in rental flows), instead of `customer` (see [_is_outgoing()](https://github.com/odoo/odoo/blob/ea6776f095d556e3429d2b847a66f78f2e866380/addons/stock/models/stock_location.py#L464)). This causes the delivery quantity not to be decremented on return. **Solution**: Relax `_is_incoming()` logic to consider moves as incoming if they come from a rental and go to an internal location. opw-4894358 Forward-Port-Of: odoo/odoo#224714 Forward-Port-Of: odoo/odoo#222093
This fixes delivered quantity calculations when non-rental items are returned from a rental order. It helps sales and operations teams keep order status and invoicing information accurate after returns, including mixed rental and non-rental orders.
Original PR description
**Issue**: Returning a non-rental product in a rental order does not correctly update the delivered quantity. **Steps to reproduce**: - Enable rental transfers via Settings > Rental. - Create a…
**Issue**: Returning a non-rental product in a rental order does not correctly update the delivered quantity. **Steps to reproduce**: - Enable rental transfers via Settings > Rental. - Create a rental order with (in that order!): - A rental product - A non-rental product - Confirm the rental order. - Open the related sale order. - Go to the delivery and validate it. - Return the delivery and validate the return. - Observe that the delivered quantity in the sale order is incorrect. **Cause**: The [_get_outgoing_incoming_moves](https://github.com/odoo/odoo/blob/ea6776f095d556e3429d2b847a66f78f2e866380/addons/sale_stock/models/sale_order_line.py#L200C17-L200C85) method fails to detect incoming moves when the destination location has `usage='internal'` (as in rental flows), instead of `customer` (see [_is_outgoing()](https://github.com/odoo/odoo/blob/ea6776f095d556e3429d2b847a66f78f2e866380/addons/stock/models/stock_location.py#L464)). This causes the delivery quantity not to be decremented on return. **Solution**: Relax `_is_incoming()` logic to consider moves as incoming if they come from a rental and go to an internal location. opw-4894358 Forward-Port-Of: odoo/enterprise#93442 Forward-Port-Of: odoo/enterprise#91825
Warehouse teams can now choose which IoT printer is used for shipping labels instead of relying on the system to pick the first available compatible printer. This helps different operation types use the right default printer, reducing misprints and manual work.
Original PR description
Printing shipping labels is performed from the backend, once the shipping info are received in the chatter. The printing command is sent to the frontend via the user bus, then though longpolling to the iot box. This commit adds the possibility to select a printer instead of choosing automatically the first (with the right report associated) on the list. As the change is made on a stable version, we are using system parameters to store the selected printer without adding a new field. We associate a printer with the picking type, in order for to be able to have different printers by default on different picking types. Task: 4792491 Forward-Port-Of: odoo/enterprise#95664 Forward-Port-Of: odoo/enterprise#86818
This fixes access rights on Swiss payroll version fields so payroll users, rather than general HR users, can view the right employee information. It helps HR officers access employee records correctly and prevents related automated checks from failing.
Original PR description
Some fields on the version were still with the hr_user group where they should be payroll_user. This was causing some tour to fail when an HR officer tries to access an employee. Build error: https://runbot.odoo.com/odoo/runbot.build.error/233204
Manufacturing orders without finished product moves can now be validated without causing an error when labor costs are posted. The system uses a fallback account in these cases, improving reliability for manufacturing accounting workflows.
Original PR description
In some cases, a Manufacturing Order may not have any finished move lines. When posting labor costs from work orders, it tries to access the first finished move in order to retrieve its account. If no finished move exists, this leads to a traceback at MO validation. This commit ensures a proper fallback account is used when no finished moves are linked to the MO, avoiding unexpected crashes. opw-4858696 opw-5066266
This fixes how employee expense records decide whether users can edit, reset, or approve them. The change ensures these actions reflect the user's real permissions instead of being evaluated with elevated access, reducing the risk of incorrect options being shown.
Original PR description
The field is_editable which used the compute method _compute_is_editable and the field can_reset which used the compute method _compute_can_reset, where called with the argument compute_sudo=True. Those 2 method then used the self.env.su which was always True. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Time Off Overview now loads correctly when users apply the My Department filter, even if they do not have access to the Employee app. This prevents an access error and lets managers or employees view relevant time off information without interruption.
Original PR description
Before this commit, the filter `My Department` filter displayed in the `Overview` of Time off app returns an Access Error when the current user has no access to employee app. This commit adds a related field to do the compute and search on that field in sudo to know if the employees in the Overview are part of the department of the current user. Steps to reproduce the issue: ============================ 1. Install Time off app with demo data 2. Log in as Marc Demo 3. Go to Time Off app > Overview 4. Enable `My Department` filter Expected Behavior: ----------------- The gantt view of Time Off Overview should be loaded without any errors. Current Behavior: ---------------- An Access Error is occurred because the user has not accessed to `hr.version` model. runbot-error-233311
Swiss payroll salary rules now show all relevant backend configuration options in the user interface. This helps payroll administrators review and adjust wage type settings without relying on hidden technical configuration, reducing setup mistakes.
Original PR description
task-4954650 Forward-Port-Of: odoo/enterprise#96824
The Belgian payroll salary configurator now checks the active company before applying Belgium-specific salary calculations. This prevents the gross salary from being hidden when configuring contracts, helping users see the expected compensation details accurately.
Original PR description
Gross Salary did not appear previously as the extending function _get_compute_results in 10n_be_hr_contract_salary was returning the l10n_be_wage_with_mobility_budget right away without checking which company we are in. This change made sure before proceeding that we are in the correct active company, Belgian one in our case. task-4987491 Forward-Port-Of: odoo/enterprise#94905
Live chat operators marked as busy are now still considered available to receive chats, matching the intended purpose of the busy status. Agents marked as away remain unavailable, preserving expected behavior when someone is inactive or deliberately away.
Original PR description
Before this commit, when a human agent had the IM status "busy", the agent was not considered available for live chat. The "busy" feature is intended only to not receive notification and to show to others we are busy, but is not meant to disable availabily as a live chat operator. The issue happens because availability of the operator required the "online" IM status, which ignored "busy" that was added recently. Note that "away" is considered as not available for operator: the "away" IM status can be set manually by user but also can be triggered automatically when agent is away for a long time, and in these cases users already expect to not be considered as available live chat agents. This behavior is kept in this commit. opw-5150332
This fix prevents Odoo Discuss from showing misleading connection warnings in browser tabs that are not actually managing the call connection. Users in cross-tab call scenarios will see more accurate call status information, reducing confusion during conversations.
Original PR description
Before this commit, the forward port[1] of a call indicator fix[2] did not account for the cross-tab call feature[3], introduced in saas 18.2 which makes it possible to be considered inside a call without having connection state information (as the remote tab does not manage connections), thus incorrectly showing the connection state indicator. [1]: https://github.com/odoo/odoo/pull/229166 [2]: https://github.com/odoo/odoo/pull/228601 [3]: https://github.com/odoo/odoo/pull/198109 Forward-Port-Of: odoo/odoo#231170
The working schedule calendar now keeps the hours-per-week text on one line. This improves readability for employee scheduling without changing any business rules or workflows.
Original PR description
Changed the style of hours/week in working schedule calendar so it doesn't appear on 2 lines task-id: 5003432 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231237
This fixes a formatting issue in the website editor where colored or gradient text inside lists could lose its color, become invisible, or create incorrect nested formatting after changing heading styles. It helps users keep list content visually consistent, including checklist strike-through behavior, when editing pages or documents.
Original PR description
Steps to Reproduce: - Create a list in the editor. - Apply a text color to an item. - Change the font type of the text inside the list (e.g., to H1–H6). - Apply a gradient color to text inside a list…
Steps to Reproduce: - Create a list in the editor. - Apply a text color to an item. - Change the font type of the text inside the list (e.g., to H1–H6). - Apply a gradient color to text inside a list item. - Move the cursor outside the list by pressing Enter twice and start typing in the new container. Current behavior before PR: - When changing the font type (H1–H6) after applying a color, the text color turns to default color. also when applying a gradient color and then changing the font type, the text becomes transparent. - This happens because the gradient style was incorrectly applied both on the `<li>` and its child `<font>` element. As a result, Checklist items lose their line-through when checked. Also new base container outside the list ends up with a `<font>` wrapping another `<font>`. Desired behavior after PR is merged: - All child elements inside the list item inherit the color and Gradient styles are applied only to the `<font>` element. - Checklist items correctly show the line-through when checked and No invalid nested `<font class="text-gradient">` tags are created when writing outside the list after pressing Enter twice. task-5039499 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231308 Forward-Port-Of: odoo/odoo#224262
Fixed an issue in Point of Sale where forcing a payment to finish could leave terminal-linked payment methods unavailable. Cashiers can now continue taking future terminal payments without being blocked after this action.
Original PR description
Before this commit, the function sendForceDone was not setting paymentTerminalInProgress to false, which blocked the user from doing another terminal payment as the payment methods linked to a terminal are not clickable. After this commit, sendForceDone can be used without blocking future terminal payments. opw-4978772 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231098 Forward-Port-Of: odoo/odoo#230969
25 changes
Resolved issues and error corrections
This update corrects how the Belgian reports partner form extension is linked, preventing module updates from failing when the citizen identification field is involved. It helps ensure smoother upgrades and maintenance for Belgian reporting features without changing day-to-day user workflows.
Original PR description
The citizen_identification field was added to the partner view in l10n_be_reports, but the form 281.50 view for this required field was incorrectly inheriting from the base partner view. That led to…
The citizen_identification field was added to the partner view in l10n_be_reports, but the form 281.50 view for this required field was incorrectly inheriting from the base partner view.
That led to a traceback when updating account_reports/l10n_be_reports modules in 19.0+ versions:
This fix PR is a backport requested from upgrade: https://github.com/odoo/enterprise/pull/92104#pullrequestreview-3144302023.
```py
Odoo Server Error
Occured on 86642809-master-all.runbot135.odoo.com on model ir.module.module on 2025-08-11 14:04:32 GMT
Traceback (most recent call last):
------- A lot of calls ------
convert_xml_import(env, module, fp, idref, mode, noupdate)
File "/data/build/odoo/odoo/tools/convert.py", line 745, in convert_xml_import
obj.parse(doc.getroot())
File "/data/build/odoo/odoo/tools/convert.py", line 616, in parse
self._tag_root(de)
File "/data/build/odoo/odoo/tools/convert.py", line 559, in _tag_root
f(rec)
File "/data/build/odoo/odoo/tools/convert.py", line 570, in _tag_root
raise ParseError(msg) from None # Restart with "--log-handler odoo.tools.convert:DEBUG" for complete traceback
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
odoo.tools.convert.ParseError: while parsing /data/build/enterprise/account_followup/views/partner_view.xml:4
Error while parsing or validating view:
Element '<xpath expr="//field[@name='citizen_identification']">' cannot be located in parent view
View error context:
{'file': '/data/build/enterprise/account_followup/views/partner_view.xml',
'line': 1,
'name': 'res.partner.view.form',
'view': ir.ui.view(5824,),
'view.model': 'res.partner',
'view.parent': ir.ui.view(127,),
'xmlid': 'res_partner_view_form'}
```
Forward-Port-Of: odoo/enterprise#96855The attendance auto-checkout process now correctly closes open attendance entries even when the employee checked in on a previous day. This prevents missed checkout records after downtime or delayed scheduled processing, improving accuracy of attendance tracking.
Original PR description
Problem: the auto-checkout feature was basing the computation on the fact that the unclosed attendance was starting today. However, it might not always be the case, for example if the server is shutdown for more than 24 hours after checking in. Steps to reproduce: - Activate the auto-checkout feature - Create an open-ended attendance for two days ago - Run the cron - Result: the attendance is not closed. This commit solves the issue by taking into account the days delta between today and the check-in date. task-5082359 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#227981
This fixes an issue in Discuss calls where a connection warning could appear in browser tabs that were not actually managing the call connection. Users will now see the warning only in the relevant host tab, reducing confusion during calls.
Original PR description
Before this commit, the forward port[1] of a call indicator fix[2] did not account for the cross-tab call feature[3], introduced in saas 18.2 which makes it possible to be considered inside a call without having connection state information (as the remote tab does not manage connections), thus incorrectly showing the connection state indicator. [1]: https://github.com/odoo/odoo/pull/229166 [2]: https://github.com/odoo/odoo/pull/228601 [3]: https://github.com/odoo/odoo/pull/198109 Forward-Port-Of: odoo/odoo#231170
The call participant volume slider is now shown only when the user is actually in the call. This avoids confusing controls appearing when they cannot be used and makes the call interface clearer.
Original PR description
Before this PR, the volume slider for call participants was visible even when the user was not part of the call. This PR fixes the behavior by ensuring the volume slider is only available when the user is in the call. task-[5092826](https://www.odoo.com/odoo/project/1519/tasks/5092826) Forward-Port-Of: odoo/odoo#231067 Forward-Port-Of: odoo/odoo#227803
Website pages translated into another language now keep document icons visible when an image block is changed to a document. This prevents missing visual cues for editors and visitors on translated website pages.
Original PR description
This commit permits to keep document icon visible during the translation of a website page. Steps to reproduce the issue: - Have a website in English (main) and French - Edit the website in the main lang (English) - Drop Image text block - Change the image to a document - Save - Edit the translation in French => The document logo becomes invisible. This commit fixes this issue. task-3626918 Forward-Port-Of: odoo/odoo#165109
Changing a user's locale can alter which day is treated as the start of the week, which affects spreadsheet pivot data grouped by day of week. This fix reloads affected pivots after a locale change so users see accurate values instead of stale or incorrectly grouped results.
Original PR description
Chaning the locale can change the first day of the week. But the normalization of the server value depends on this `locale.weekStart`, se we need to reload the pivot when the locale changes, otherwise we might display wrong values for a "day_of_week" grouping. Task: [5149508](https://www.odoo.com/web#id=5149508&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) 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#230949
Combo products in Point of Sale preparation tickets are now routed correctly when different printers handle different product categories. Each printer shows the combo title and only the relevant child items, reducing kitchen or preparation mistakes.
Original PR description
Before this commit: =================== - When using separate printers for product categories, combo products were not printed correctly. - All child products of a combo were sent to every printer, regardless of their category. After this commit: ================== - Combo products are now handled properly in preparation tickets. - Each printer will print the combo product title along with only the child products that belong to its assigned category. Task: 5056115 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225658
The Swiss payroll ELM salary rule screen now includes all relevant configuration options that were previously only available in the backend. This helps payroll teams review and adjust wage type settings more reliably without needing technical access or hidden configuration steps.
Original PR description
task-4954650 Forward-Port-Of: odoo/enterprise#96824
The working schedule calendar now keeps the hours-per-week label on one line. This improves readability for users viewing employee schedules and avoids awkward text wrapping.
Original PR description
Changed the style of hours/week in working schedule calendar so it doesn't appear on 2 lines task-id: 5003432 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231237
This fix makes reconciliation models available when using invoicing features, preventing accounting workflows from getting stuck. It also cleans up confusing screens related to creating reconciliation model lines, making the invoicing experience smoother for users.
Original PR description
Currently flows are stuck if you don't have the models. And some views are really weird (create a reconciliation model line). 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 fix keeps accounting reports restricted to the accounting area as intended. It helps prevent these reports from appearing in unrelated journal dashboard contexts, reducing confusion for users.
Contacts without a regular name or email now display a fallback name in chatter recipients, follower lists, and subscription dialogs. This prevents blank labels or confusing “false” values, making recipient selection clearer for users.
Original PR description
Steps to reproduce =============== 1. Create a contact of type invoice address without name and email. 2. Go to any app with chatter. 3. Add this user to the recipient ----> Only the blue tick will be visible (recipient name will be empty) After this commit, we will use the display_name as a fallback to show in the chatter. Forward-Port-Of: odoo/odoo#222523 Forward-Port-Of: odoo/odoo#213545
The change updates automated checks in Helpdesk, Salary Contracts, and Studio so they match a recent change in how suggested email recipients include display names. This helps keep quality checks accurate and prevents false test failures without changing day-to-day user workflows.
Original PR description
From the related community commit, the _message_add_suggested_recipient method is modified to also return display name under certain condition. This commit adapts the test inside web_studio to align with the method's change. Task-4812554 Forward-Port-Of: odoo/enterprise#92126 Forward-Port-Of: odoo/enterprise#91003
The date picker now clearly shows when certain dates cannot be selected. This reduces confusion for users by making unavailable dates visually distinct and aligned with their actual behavior.
Original PR description
In this commit fa3bfb0a696c20ae51cd0f37f737fcf211007c4a, the o_date_item_cell was changed from a button to a div. This made the style of disabled cells not show that its not unclickable, making it confusing for users. Solution is to add specific style for the disbaled o_date_item_cell component. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Point of Sale now handles cases where a customer previously loaded in the system has since been deleted. This prevents reload errors and helps staff continue checkout or settlement workflows without interruption.
Original PR description
Before this commit, if a previously loaded partner was deleted from the database, reloading the PoS would trigger an error because the partner record could no longer be found. opw-5137871
The Point of Sale product information popup now shows the stock level for the exact product variant selected, rather than the broader product template. This helps cashiers make more accurate sales decisions when products have multiple variants with different inventory levels.
Original PR description
Before this commit, when a product template had several variants, opening the product info while a specific variant was selected would not display the inventory information of the selected variant. opw-5161698 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures the point-of-sale payment screen updates correctly after a customer completes an online QR code payment. It prevents staff or customers from seeing an outdated QR payment prompt and avoids errors when finalizing the order.
Original PR description
*: pos_online_payment_self_order Before this commit: =============== - When paying with a QR code, the screen kept showing the QR code even after the payment was completed. - Closing the QR popup…
*: pos_online_payment_self_order Before this commit: =============== - When paying with a QR code, the screen kept showing the QR code even after the payment was completed. - Closing the QR popup manually and performing another action resulted in a `Finalize order` error. - This happened because the WebSocket handler flow were not updating the order state properly. After this commit: =============== - Ensure the frontend refreshes payment status directly from the server when the current order is updated. - Remove unnecessary synchronization calls to prevent stale state. - The order is now correctly marked as paid, and no finalize error occurs after closing the QR popup. Issue: =============== - The frontend WebSocket handler for `ONLINE_PAYMENTS_NOTIFICATION` was fetching the full `pos.order` unnecessarily, because the order state is already updated by another WebSocket flow. - `notify_synchronisation` in the self order flow was redundant, as updates are already handled in the `pos_self_order` module’s `pos.order` file. Task - 5107009 Forward-Port-Of: odoo/odoo#229847
A Point of Sale issue was fixed where forcing a payment to finish could leave terminal payments marked as still in progress. This prevented cashiers from selecting terminal-linked payment methods for the next transaction, so the fix helps checkout continue smoothly.
Original PR description
Before this commit, the function sendForceDone was not setting paymentTerminalInProgress to false, which blocked the user from doing another terminal payment as the payment methods linked to a terminal are not clickable. After this commit, sendForceDone can be used without blocking future terminal payments. opw-4978772 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231098 Forward-Port-Of: odoo/odoo#230969
Fixes a blank QR Menu page for Belgian blackbox point-of-sale setups when customers open the menu before the PoS session has started. This ensures the online menu remains accessible as expected and avoids a disruptive customer-facing failure.
Original PR description
When you open the QR Menu of a PoS that uses the blackbox, the menu will not appear if the session is not opened. Steps to reproduce: ------------------- * Setup a PoS to use the blackbox * Setup the same PoS to use the QR Menu * Try to open the menu without opening the PoS > Observation: The QR Menu never show anything, the page stays blank. Why the fix: ------------ Here (https://github.com/odoo/enterprise/blob/0635388bdc9f115d527e0d2da43dfcd0d4a00d1f/pos_blackbox_be/static/src/self_order/overrides/services/self_order_service.js#L61-L62) if the session is not opened, we try to read `_product_product_work_in` on session that is undefined. opw-4829700 Forward-Port-Of: odoo/enterprise#93196
This fixes a website layout issue where hiding a sidebar-style header still left the page content shifted to the right. Business users get a cleaner page preview and published layout when the header is turned off.
Original PR description
Steps to reproduce the issue: - In edit mode, change the header template to use the "Sidebar" header (=> since it is a sidebar, the page content is shifted to the right) - Go to the theme tab and toggle the "Show Header" option so the header is removed => Bug: the page content is still shifted as if the sidebar were still present. This happens because the page still has padding-left for the header, although there's no header. task-5131064 Forward-Port-Of: odoo/odoo#229860
The website editor no longer shows duplicate eCommerce mega menu options when no product categories exist. This prevents users from selecting an empty menu option that would trigger an error, making website editing smoother and less confusing.
Original PR description
When `website_sale` is installed but there are no eCommerce categories, all mega menu options will be shown twice in the web editor. When you use the duplicated one it's empty and you'll also get an error. Forward-Port-Of: odoo/odoo#230825
This fix allows product imports to correctly include uploaded files, such as PDFs, in custom Studio file fields. Businesses can now update product records from spreadsheets without errors or missing attachments when non-image files are included.
Original PR description
## Versions 18.0 > 18.3 Solved from 18.4 thanks to e0e46b5c15d53d7aab69a9c4bf39d9b2a412efc6 ## Issue Importing products (with file fields) from XLSX file triggers an error or does not update when…
## Versions
18.0 > 18.3
Solved from 18.4 thanks to e0e46b5c15d53d7aab69a9c4bf39d9b2a412efc6
## Issue
Importing products (with file fields) from XLSX file triggers an error or does not update when uploading related PDF files.
## Steps to reproduce
https://github.com/user-attachments/assets/7f4c1faf-de8c-4923-a50e-cce77071679d
*Requires Studio app*
- Go to any product's backend page and open Studio customization:
- Add a "File" field to the product page and link it to a "PDF Viewer" widget;
- Keep the field name ("New File");
- Save and close.
- Go to the products' list view in debug mode and select a product (e.g. Acoustic Bloc Screens) to export (via "Actions"):
- Check the "import-compatible" checkbox;
- Remove all fields to export;
- Look for "file" in available fields:
- Add the "New File (x_studio_binary_field_xxx_xxxxxxxxx)" field;
- Add its related "Filename for x_studio_binary_field_xxx_xxxxxxxxx (x_studio_binary_field_xxx_xxxxxxxxx_filename)".
- Export in XLSX format.
- In your computer's file explorer:
- Download or create a PDF file and copy its name;
- Open the XLSX file and paste the PDF filename in the 2 empty columns;
- Save and close the file.
- In the products' main view click "Import records" action button:
- Click "Upload Data File" and select the XLSX product file.
- Click "Upload your files" in the "Files to import" section on the left and select the PDF file.
- Click "Test" or "Import"
## Cause
This upload feature has been described in task 4077715. This specific lines seems to be based on another one a bit further in the code: https://github.com/odoo/odoo/blob/e42f5bee59daa0e270ae4803cc827009974da232/addons/base_import/models/base_import.py#L1289
## Fix
Allow all files base 64 conversion by removing a restriction on images only.
opw-4931579
Forward-Port-Of: odoo/odoo#229648This fixes the value used when neutralizing Nemhandel-related users so it matches the expected Nemhandel proxy type. It helps ensure the cleanup or anonymization process targets the right records and avoids leaving incorrect configuration behind.
Original PR description
The value to neutralize a user should be nemhandel and not l10n_dk_nemhandel --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231264
Close buttons in website popups, side panels, and notifications now adapt to the site's selected color palette. This improves visual consistency and helps these interface elements remain clear and readable across different website themes.
Original PR description
This commit makes `.btn-close` color dynamic based on the color palette of the website. Impacted components that are using `.btn-close`: `.modal` (e.g.: `.o_sale_product_configurator_dialog` `.offcanvas` (e.g.: `#o_wsale_offcanvas`) `.o_notification` task-4630175 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221047
Images in website card snippets now correctly use the same rounded corners as the card itself. This fixes a visual inconsistency so website content appears more polished and consistent.
Original PR description
Specification: - Border radius on the image in the card snippet was not being applied correctly. - Border radius should be consistent with the card's border radius. After this commit: - The image inside the card snippet will now correctly inherit the border radius from the card. - This change ensures that the image appears rounded in the same way as the card itself. task-4848288 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213632
1 change
Resolved issues and error corrections
The Swiss ELM payroll wage type form now includes all relevant backend configuration fields in the user interface. This helps payroll teams review and adjust salary rule settings more reliably without missing hidden configuration details.
Original PR description
task-4954650 Forward-Port-Of: odoo/enterprise#96824
31 changes
Resolved issues and error corrections
Payroll processes now identify a company's country through its linked partner record instead of relying on a company field that cannot be searched. This prevents payroll and Swiss payroll exports or transmissions from failing or missing companies because of that lookup issue.
Original PR description
As the country_id field on the company is computed and not searcheable, this commit adapts the domain to search for the country of the associated partner. task-5096037 Forward-Port-Of: odoo/enterprise#95255
The Invoices dashboard has been corrected so the Top Invoices list updates when users apply a time filter. This keeps dashboard figures consistent and helps teams make decisions from the right reporting period.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When assigning a future driver to a vehicle, the system now marks only the driver's other vehicles as planned for change. This avoids incorrectly flagging the vehicle being assigned, helping fleet managers keep vehicle transition plans accurate.
Original PR description
WHen a new vehicle is created for someone in a non waiting column, we are settign his other cars in plan_to_change. When we set a future driver on a car, we set the others as plan to change, but not the one on which we are setting the future_driver --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230952
The Point of Sale flow now stops order validation when a cashier cancels the required customer popup for Customer Account payments. This prevents incomplete orders from causing an error and keeps the checkout experience stable.
Original PR description
Steps to reproduce: =================== - Open POS and add a product to the cart - Go to the Payment screen - Select `Customer Account` as the payment method and Validate Order - The `Customer Required` popup appears - Click `Cancel` on the popup Issue: ====== - POS still continues with the order validation process - This leads to a traceback since the order data is incomplete Cause: ====== - The `_askForCustomerIfRequired()` always returned a value that allowed validation to continue - As a result, validation continued even after clicking Cancel Fix: ==== - `validateOrder()` now checks the return value and aborts validation if the user cancels the popup Task: 5094722
Opening a manufacturing Bill of Materials overview could fail when Odoo tried to plan a very large producible quantity beyond work center capacity. The system now falls back to the actually requested quantity, allowing users to view the overview and continue replenishment planning.
Original PR description
### Steps to reproduce: 1. Install mrp + purchase 2. Create a new product (A) 1. Add the Buy route on the product 2. Add a vendor line on the Purchase tab 3. Set the quantity on hands to 2000 3.…
### Steps to reproduce: 1. Install mrp + purchase 2. Create a new product (A) 1. Add the Buy route on the product 2. Add a vendor line on the Purchase tab 3. Set the quantity on hands to 2000 3. Create a second product (B) with manufacturing route 4. Create a BoM for this product (B) 1. Add the product (A) as the component with 1 quantity 2. Create a new operation with a duration of 600:00 5. On the product B's page, click Replenish 1. Put 10 quantities to replenish 2. Select the manufacturing route and confirm 6. Go to the BoM and open the BoM overview 7. 'Impossible to plan. Please check the workcenter availabilities.' https://github.com/user-attachments/assets/58697fd9-4e3e-4df6-98e1-5de7e8759715 ### Before this commit: When opening the BoM overview, if the producible quantity for this BoM exceed the quantity we can plan in the 700 following days, an error is displayed. ### After this commit: If the quantity producible cannot be planned, we retry automatically with the requested quantity. opw-5031724 Forward-Port-Of: odoo/odoo#229745 Forward-Port-Of: odoo/odoo#227433
The Point of Sale scan button now reliably opens the camera to scan a QR code even when an order is selected on the ticket screen. This helps cashiers continue scanning without switching screens or clearing their selection, reducing checkout friction.
Original PR description
Before this commit: = - The scan button did not function when an order was selected. After this commit: = - The scan button now opens the camera to scan a QR code even when an order is selected. Task: 4778136 Forward-Port-Of: odoo/odoo#230868 Forward-Port-Of: odoo/odoo#211875
Employee attendances left open from previous days will now be closed correctly by the automatic checkout process. This prevents stale attendance records when the server was offline or the scheduled job did not run for more than a day.
Original PR description
Problem: the auto-checkout feature was basing the computation on the fact that the unclosed attendance was starting today. However, it might not always be the case, for example if the server is shutdown for more than 24 hours after checking in. Steps to reproduce: - Activate the auto-checkout feature - Create an open-ended attendance for two days ago - Run the cron - Result: the attendance is not closed. This commit solves the issue by taking into account the days delta between today and the check-in date. task-5082359 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#227981
The working schedule calendar now shows the hours-per-week value on a single line. This small visual fix makes employee schedule information easier to read and avoids awkward wrapping in the interface.
Original PR description
Changed the style of hours/week in working schedule calendar so it doesn't appear on 2 lines task-id: 5003432 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231237
The Attendance kiosk barcode scanner now opens correctly when debug mode is enabled. This prevents an error screen caused by sending unsupported data to the scanner dialog, helping administrators and testers use kiosk mode reliably.
Original PR description
**Step to reproduce:** - install Attendances app - turn on debug mode - go to Attendance -> kiosk mode - open the scanner **Observation:** - We get a traceback **Cause:** - we pass a extra prop `token` to BarcodeDialog component, which is not accepted by it https://github.com/odoo/odoo/blob/178dff30131a93680dfd994fd22b29a766ee9354/addons/web/static/src/core/barcode/barcode_dialog.js#L12 - this raises issue from OWL when we have debug-mode on **Fix:** - reuse the actual `scanBarcode` method and remove the faulty one. https://github.com/odoo/odoo/blob/178dff30131a93680dfd994fd22b29a766ee9354/addons/web/static/src/core/barcode/barcode_dialog.js#L47-L60 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227715 Forward-Port-Of: odoo/odoo#225738
Saving an overtime ruleset without a required quantity period no longer causes an unexpected system error. Users now receive the intended validation message, making the attendance setup flow clearer and preventing confusion during configuration.
Original PR description
Currently, an error occurs when user saves an overtime ruleset.
Steps to reproduce:
- Install the `hr_attendance` module.
- Go to `Overtime Rulesets` and create a rule.
- Add an `overtime rule` in this `ruleset` with:
- `Rule is based on: Quantity`
- and `clear the 'If the worked hours on' field`.
- Save the `rule` and `ruleset`.
`TypeError: UserError.__init__() got an unexpected keyword argument 'name'`
This error occurs when a user saves the ruleset without setting the rule's quantity period, and due to two arguments being wrongly placed in the ValidationError[1], the error is raised.
This commit ensures that the validation error works correctly by passing a single argument.
[1]: https://github.com/odoo/odoo/blob/34409128de0bb84cdee309b031b307c46d8b07c7/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L147
sentry-6932048427
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe QR Menu for Belgian blackbox-enabled Point of Sale setups no longer shows a blank page when the register session has not been opened. This ensures customers can still view the digital menu as expected, avoiding lost service availability before the PoS session starts.
Original PR description
When you open the QR Menu of a PoS that uses the blackbox, the menu will not appear if the session is not opened. Steps to reproduce: ------------------- * Setup a PoS to use the blackbox * Setup the same PoS to use the QR Menu * Try to open the menu without opening the PoS > Observation: The QR Menu never show anything, the page stays blank. Why the fix: ------------ Here (https://github.com/odoo/enterprise/blob/0635388bdc9f115d527e0d2da43dfcd0d4a00d1f/pos_blackbox_be/static/src/self_order/overrides/services/self_order_service.js#L61-L62) if the session is not opened, we try to read `_product_product_work_in` on session that is undefined. opw-4829700 Forward-Port-Of: odoo/enterprise#93196
Swiss payroll salary rule screens now include the same configuration options that were already available in the backend. This helps payroll administrators review and manage wage type settings more reliably without switching to technical views.
Original PR description
task-4954650 Forward-Port-Of: odoo/enterprise#96824
Fixed an issue where point of sale quick-add payment buttons such as +10 or +50 could calculate wildly incorrect amounts for users in languages that use a comma as the decimal separator. This ensures cashiers can rely on the buttons to add the intended payment amount, reducing checkout errors.
Original PR description
**Steps to reproduce:** - Set your database in a language with a "," as a decimal separator, such as French - Make a purchase, chose a payment method - Before paying, click any +10/20/50 button - The…
**Steps to reproduce:** - Set your database in a language with a "," as a decimal separator, such as French - Make a purchase, chose a payment method - Before paying, click any +10/20/50 button - The price will be multiplied by 100, then add the desired amount **Why the fix:** There were two places where the decimal separator was causing issues. First when we try to get the current price, *currentBufferValue*, we try to get it when it's in float state, but as we have a language with a decimal separator set as "," the "." in this float will be ignored, and we will take the decimal as units as well, explaining the *100 amount, because the decimals become whole numbers. Secondly, when we try to make the addition of the two and convert it to string again, the *toString* method will convert it with a default "." not taking the current decimal separator into account. Once again, the "." will be ignored later on, leading to an even more over the top number. We now convert the numbers and the strings using the correct decimal separator. opw-5126224 Forward-Port-Of: odoo/odoo#229735
Fixes an issue where users could see a misleading connection warning when joining or following a Discuss call from another browser tab. The warning now appears only where connection details are actually available, reducing confusion during calls.
Original PR description
Before this commit, the forward port[1] of a call indicator fix[2] did not account for the cross-tab call feature[3], introduced in saas 18.2 which makes it possible to be considered inside a call without having connection state information (as the remote tab does not manage connections), thus incorrectly showing the connection state indicator. [1]: https://github.com/odoo/odoo/pull/229166 [2]: https://github.com/odoo/odoo/pull/228601 [3]: https://github.com/odoo/odoo/pull/198109 Forward-Port-Of: odoo/odoo#231170
This fixes a crash that could happen when a user hid an HTML field while newly added images were still being processed. The editor now preserves the content safely during that delay, helping users avoid interruptions and potential lost edits.
Original PR description
**PROBLEM** When hiding a HtmlField field from a view with pending images in it, there is a traceback. **STEP TO REPRODUCE** 1. Using studio, create a HtmlField on the view of your choice. 2. Add a…
**PROBLEM** When hiding a HtmlField field from a view with pending images in it, there is a traceback. **STEP TO REPRODUCE** 1. Using studio, create a HtmlField on the view of your choice. 2. Add a checkbox next to it, and link the HtmlField visibility to the button. 3. Add a image to the HtmlField (don't save the record !) 4. Hide the HtmlField using the checkbox, there should be a traceback. (if not, try with a bigger image). **CAUSE** commitChanges() will try to retrieve the field value to commit by looking at the related element in the DOM. Before retrieving this value, we call savePendingImages() to save the new images added to the HtmlField. https://github.com/odoo/odoo/blob/1416aad902a97ce56aaecc2aadc4dd9f7814ee53/addons/html_editor/static/src/fields/html_field.js#L159-L162 This introduces a delay, during which the DOM element could be destroyed. **FIX** We don't call commitChanges() in OnBlur(). Instead, we cache the new value in a property of HtmlField called `newValue` when `OnChanges()` is called. Inside OnBlur(), we save the pending images by directly calling `savePendingImages()` and we commit the new value by calling `updateValue(this.newValue)` opw-5061820 Forward-Port-Of: odoo/odoo#230980 Forward-Port-Of: odoo/odoo#227482
This fix prevents an error when a user clears the period date while creating or editing a payslip. It helps payroll users continue their work without an unexpected crash when required date information is missing.
Original PR description
This error occurs when the user removes the period date from the payslip. Steps to reproduce: --- - Install `hr_payroll` module - Create a New Payslip - Add `Employee` and remove `Period` date Traceback: --- `TypeError: '<=' not supported between instances of 'datetime.date' and 'bool'` This error occurs because at [1], the `date_to` field is received as `False` after the date is removed from the payslip. [1]: https://github.com/odoo/odoo/blob/4cd1ad3aa46ad4645fc7b5e530b79d53382de6d5/addons/hr/models/hr_version.py#L388 sentry-6925445279 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an error when a payroll user removes the period date from a payslip. It keeps payslip editing stable and avoids an unexpected interruption during payroll preparation.
Original PR description
This error occurs when the user removes the period date from the payslip. Steps to reproduce: --- - Install `hr_payroll` module - Create a New Payslip - Add `Employee` and remove `Period` date Traceback: --- `TypeError: '<=' not supported between instances of 'datetime.date' and 'bool'` This error occurs because at [1], the `date_to` field is received as `False` after the date is removed from the payslip. [1]: https://github.com/odoo/odoo/blob/4cd1ad3aa46ad4645fc7b5e530b79d53382de6d5/addons/hr/models/hr_version.py#L388 sentry-6925445279
This fixes an issue where refund requests for payment providers other than Adyen could lose their expected result. It helps keep refund processing reliable across all supported payment providers.
Original PR description
Commit [efc2788](https://github.com/odoo/odoo/commit/efc2788) introduced bug. Ensure _send_refund_request returns the value from super() when the provider is not Adyen.
Corrected a misspelled database table name used during payroll data neutralization. This prevents the cleanup process from failing, helping ensure test or sanitized databases are prepared correctly.
Original PR description
There is a `s` in the table name of `ir_config_parameter`
```py
2025-10-14 12:30:43,043 278 ERROR ? odoo.sql_db: bad query: b"DELETE FROM ir_config_parameters WHERE key = 'l10n_au_payroll_iap.endpoint';\nUPDATE res_company SET l10n_au_payroll_mode = 'test';"
ERROR: relation "ir_config_parameters" does not exist
LINE 1: DELETE FROM ir_config_parameters WHERE key = 'l10n_au_payrol...
^
2025-10-14 12:30:43,043 278 CRITICAL ? odoo.cli.neutralize: An error occurred during the neutralization. THE DATABASE IS NOT NEUTRALIZED!
```Edited messages now place the “edited” label at the end of the final paragraph instead of adding it after the full message content. This prevents unwanted extra line breaks and keeps edited messages visually clean for users.
Original PR description
When a message is edited, the "edited" label should be added at the end of the last paragraph/div. In this case, there is no extra line break added. This is due to the fact that the body now is sent as a full HTML fragment and not plain text. So we should create the "edited" node and append it to the last paragraph/div rather than directly appending the HTML string. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Product descriptions in accounting documents now display as regular text when users are not editing them. This prevents layout height issues and makes product lines appear more reliably in forms and sales-related views.
Original PR description
The product_label_section_and_note_field product description used a textarea even outside edition. This caused height miscalculations due to a conflict between the autoresize and magicColumnWidth hooks. To fix this, the description is now rendered as plain text when not in edit mode, ensuring autoresize only applies once the field enters edition. task-5040151
Discuss now handles encrypted or unreadable PDF attachments without showing an error. Users can continue uploading files normally, while invalid previews are handled gracefully instead of interrupting their workflow.
Original PR description
Currently, an error occurs when trying to preview the first page of a PDF attachment in Discuss if the PDF is `encrypted` or contains `invalid encoding`. **Steps to produce:** - Install the `mail`…
Currently, an error occurs when trying to preview the first page of a PDF attachment in Discuss if the PDF is `encrypted` or contains `invalid encoding`. **Steps to produce:** - Install the `mail` module. - Open `Discuss` and attach the encrypted file [1], or the invalid PDF file [2]. (`Note`: Ensure Python version 3.12+ is used.) **Error:** `PyPDF2.errors.DependencyError: PyCryptodome is required for AES algorithm` `UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa4 in position 0: invalid start byte` **Root cause:** At [3], `extract_page` directly calls `PdfFileReader`, when it fails to read or decrypt the file, Python raises an error. **Fix:** This commit prevents errors when a user attaches a PDF file that is unreadable or encrypted. [1]: https://drive.google.com/file/d/1moSlwXHkqcV6_7zHBNhLMLi-9Ye_xDGJ/view?usp=sharing [2]: https://drive.google.com/file/d/16O4LLH8dL0RWmbOx4HrcooFUyesWaVi-/view?usp=sharing [3]: https://github.com/odoo/odoo/blob/11cbbb85b1ee2a620d752b79e86fc51a8e3b33e4/odoo/tools/pdf/__init__.py#L227 sentry-6912765819
The duplicate transaction warning in bank reconciliation was not taking users to the tool for finding duplicates. This fix restores that link, helping accounting users quickly review and resolve possible duplicate bank transactions.
Original PR description
Before this commit, the action "Some transactions may be duplicates." was broken because 2 elements from the old bank reconciliation widget were removed. The commit [[1]] of the new bank reconciliation widget forgot to add the action service and a link to the journal. These 2 elements were used to redirect the customer to the Find duplicates tool. This commit adds, in the extension of the bank reconciliation kanban controller, the call to the action service and adapt the old code to match the new one. no task id [1]: https://github.com/odoo/enterprise/commit/2335c953723dce66af8811fdfbfd5b811d42b109 Forward-Port-Of: odoo/enterprise#96849
Opening an individual contact from a sales order no longer shows the address of the contact's parent company in the company field. This prevents confusing or misleading address information from appearing where it should not be displayed.
Original PR description
Be on a sale order, set as customer a contact that isn't company, but which has a parent_id with an address. From the sale order, open the customer (with the right arrow icon). In the partner form view, the address of the contact's company (the parent_id field) is displayed, it shouldn't. This commit fixes the issue by forcing `show_address: False` on that field, as we never want to see the address there. This overrides the context that is propagated from the many2one field of the sale order form view. opw~5026032 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 fixes a barcode inventory test so it behaves consistently when demo data is installed. The test now matches its intended setup by preventing new lot creation on outgoing transfers, reducing false failures in automated validation.
Original PR description
When running this test with demo data, it will always fail because the option to create new lots on outgoing picking is activated, even though the docstring says it shouldn't be. This fix disable `use_create_lots` on outgoing pickings in accordance with the docstring.
This change prevents upgrade failures when databases with Saudi localization and demo data are updated. It removes an automatic demo setup step that depended on data not yet available during the upgrade, improving reliability without affecting normal business features.
Original PR description
The post_init_hook breaks the upgrade of databases with demo data with l10n_sa installed. The reason is that the upgrade installs it, being in the dependencies. And l10n_account_withholding_tax is installed before l10n_sa is updated. The post init hook then breaks because it gets tags that don't exist yet, appearing in the update of l10n_sa. We remove this post_init_hook as it just tries to create a demo tax to show users how it works. runbot-error-233167 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Peppol advanced fields module is being marked as deprecated because it was released before it was ready and still lacks important functionality. This helps prevent businesses from installing an incomplete feature while a better solution is prepared.
Original PR description
This module was merged prematurly, it's not fully working and still lacks important features. We'll come up with a better solution, in the meantime we try to avoid that people install it. task-none
Fixes an issue where creating a new email marketing message could crash if the company logo had been removed. Users can now select mail templates normally, and the system only displays a logo when one is available.
Original PR description
Currently, an error occurs when a user selects a mail template after removing their company logo. **Steps to replicate** * Install `mass_mailing` * Companies > YourCompany > Remove company logo *…
Currently, an error occurs when a user selects a mail template after removing their company logo.
**Steps to replicate**
* Install `mass_mailing`
* Companies > YourCompany > Remove company logo
* Email Marketing > New > Start From Scratch
**Error:**
```
`QwebError:
Error while rendering the template:
KeyError: 'user'
Template: mass_mailing.s_mail_block_header_social
Reference: 805
Path: /t/section/div/div/div[1]/div/a/img
Element: <img class='o_b64_image_to_save o_editable_media' t-att-src='image_data_uri(company_id.logo if company_id.logo else user.company_id.logo)'...`
```
**Root cause:**
* This error occurs because [1] tries to access `user` after the company logo is removed. As shown in [2], `user` isn’t in values but exists in `env` or as `user_id` ,causing a key error and a qweb exception.
* The template change that introduced this behavior was made after commit [3].
**Solution:**
* Show the logo only if at least one is available, similar to the approach in `18.4` [4]. Without this condition, the template fails when both the selected company and the user's default company are the same and have no logo. This leads to a type error at [5] because accessing the logo through the user returns `False`, and a boolean is not subscriptable.
[1]:
https://github.com/odoo/odoo/blob/d484516bcae1beb767d90d20e1ab294f1e9ae8a9/addons/mass_mailing/views/snippets/mass_mailing_headers_snippets.xml#L9-L10
[2]:
https://drive.google.com/file/d/1XwASk3CGcfkVk7sifuqZE7t_QtCZpuRU/view?usp=sharing
[3]:
https://github.com/odoo/odoo/commit/b6e51609807bdb771f305ba289aafe3e2b9b26b6#diff-8f450b28258a6e33b353e751dcb8c71e5ac6c93743efe6eea35a8744d9f7d6b5
[4]:
https://github.com/odoo/odoo/blob/3a712861be1e3536e593a94e741457840da46907/addons/mass_mailing/views/snippets_themes.xml#L90
[5]:
https://github.com/odoo/odoo/blob/d484516bcae1beb767d90d20e1ab294f1e9ae8a9/odoo/tools/image.py#L562
sentry-6923986938Fixed the display of Time Off alerts so Indian sandwich leave warnings no longer appear collapsed when creating a new request. Alert spacing is now consistent, making important leave information easier for employees and HR teams to notice.
Original PR description
Issue: The sandwich leave alert for l10n India was incorrectly shown folded when creating a new time off entry for Indian companies. Additionally, the leave_type_increases_duration alert lacked proper top margin, causing inconsistent spacing. Steps to Reproduce: - For the sandwich alert: When shown, it appears folded automatically when creating a new time off entry (only for Indian companies). - For leave_type_increases_duration: When displayed, it lacks top margin. Fixes: - Moved the sandwich leave alert to the header alongside other alerts for consistency. - Adapted margins for all alerts. Task ID: 5071899 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226229
This fix ensures that when a point of sale payment is force-completed, the system correctly clears the in-progress terminal payment state. Cashiers can then start another card terminal payment without payment options becoming unavailable.
Original PR description
Before this commit, the function sendForceDone was not setting paymentTerminalInProgress to false, which blocked the user from doing another terminal payment as the payment methods linked to a terminal are not clickable. After this commit, sendForceDone can be used without blocking future terminal payments. opw-4978772 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231098 Forward-Port-Of: odoo/odoo#230969
The Belgian reporting module now uses clearer descriptions and updated translations for audit checks. This helps users understand compliance checks more easily across supported languages without changing business processes.
16 changes
Resolved issues and error corrections
This update fixes an intermittent automated test failure in the Mail app related to discarding a message edit with the Escape key. It improves test reliability by ensuring the message editor is ready before the discard action is checked, helping avoid false failures in validation pipelines.
Original PR description
Before this commit, test "discard on pressing escape" failed non-deterministically with the following error: ``` Failed to find 0 of ".o-mail-Composer" (Timeout of 3 seconds). Found 1 instead. ``` This happens at the very last step of the test: we click on composer of message to have the focus, so that we can then press ESCAPE and discard the editing of message and thus remove the composer. The issue happens because while we click on composer, we don't await the composer being logically focused, which is necessary for the good working of the ESCAPE feature to discard the message editing. This commit fixes the issue by awaiting the composer is logically focused after click on composer, so that pressing ESCAPE is properly expected to cancel the editing and thus remove the composer. Fix runbot-error-233394
Gift Card and E-Wallet products will now appear in the Point of Sale screen even when the store is limited to selected product categories. This ensures staff can reliably sell these payment products without needing extra category setup.
Original PR description
Before this commit: =================== If the PoS configuration is restricted to specific categories, but the Gift Card and E-Wallet products do not have any category assigned, these products will not be visible in the PoS UI. After this commit: ==================== Gift Card and E-Wallet products are now always visible in the PoS UI, regardless of whether a PoS category is assigned or not. Purpose: ============ Gift Card and E-Wallet products should always be available for sale in the PoS. This ensures they can be sold physically from the PoS UI without requiring category assignment. Task-5103770
This fixes an issue in the HTML editor where typing next to a link inside formatted text could lose the intended styling. Users can now add links within styled text without unexpected formatting changes at the link boundaries.
Original PR description
Problem: If we add a link on a slice of formatted text we end up being able to type unformatted content at the link edges. Cause: After https://github.com/odoo/odoo/commit/3bcbd6f34facb9c88290dbd6496cc5103665a0a2 the `span` can be split and `feff`s are placed around the link, precisely between the link and the `span`. This allows writing unformatted content at the caret when placed between them. Solution: Ensure that the link is created inside the `span`. Also prevent the formatting applied by `.btn` when the link is inside a `span`. Steps to reproduce: 1. Add "abc". 2. Format all the text: set font size 48 (or whatever). 3. Select "b". 4. Create a link on "b" only. 5. Put caret before "a". 6. Press Arrow left. 7. Type any character. → The character is not formatted as the link content. task-5092298 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change ensures the payment method information needed by SEPA direct debit is available from the core accounting module. It prevents installation or update failures when SEPA direct debit is used without the optional account payment module installed.
Original PR description
Odoo 18 have an error, the view `account_sepa_direct_debit.account_payment_register_form_inherit_account_sepa_direct_debit` (Enterprise) references the field `payment_method_code` from…
Odoo 18 have an error, the view `account_sepa_direct_debit.account_payment_register_form_inherit_account_sepa_direct_debit` (Enterprise) references the field `payment_method_code` from `account.payment.register`. This field is added to the model in the `account_payment` module, which is not among the dependencies of `account_sepa_direct_debit`. This means that if the `account_payment` module is not installed, the installation/update of `account_sepa_direct_debit` will also fail. To avoid this error, the field `payment_method_code` in the `account_payment` module needs to be defined instead in the `account` module. I open this PR on the recommendation of @hupo-odoo ([comment](https://github.com/odoo/enterprise/pull/96254#pullrequestreview-3310607477)). Here’s a screenshot of the error (runbot) <img width="1498" height="857" alt="runbot_account_sepa_direct_debit" src="https://github.com/user-attachments/assets/e8d66a96-59a3-4cf3-857b-e07a3337338c" /> Here’s the screenshot after changing to this commit <img width="1594" height="725" alt="image" src="https://github.com/user-attachments/assets/ea2fbe2c-31b8-4d61-8cf2-00e003ec3587" /> [OPW](https://www.odoo.com/es_ES/my/tasks/5139827) [PR enterprise](https://github.com/odoo/enterprise/pull/96254#pullrequestreview-3310607477) @moduon MT-12067 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The subscription MRR Breakdown report now only uses active companies when preparing its data. This prevents an access error that could occur after archiving an old company and changing currency settings, allowing users to open report details reliably.
Original PR description
Step to reproduce: - Start database without demo data and install Subscriptions - Create a new Company and archive the first Company in the Database - Set a currency rate on a currency (i.e. Euro),…
Step to reproduce: - Start database without demo data and install Subscriptions - Create a new Company and archive the first Company in the Database - Set a currency rate on a currency (i.e. Euro), then set that currency as the Main Currency of the new Company. - Then, set a currency rate on the previous Main Currency i.e USD. - Create a Subscription Sales Order and confirm it. - Open the MRR Breakdown report. - Click into the data of the report. Observation: An error message will occur appear (Access Error) Issue: - when building the query, it also fetches the archived company, due to `active_test` context applied from [fetch()](https://github.com/odoo/odoo/blob/754599a7720ee179fc5304b9613df9c177e4b231/odoo/models.py#L3858), and hence wrong query is build which fetches no data, leading to sort of access error as this [condition](https://github.com/odoo/odoo/blob/754599a7720ee179fc5304b9613df9c177e4b231/odoo/models.py#L3876) matches. Fix: - we explicitly search for active companies opw-5090463 Forward-Port-Of: odoo/enterprise#95989
The website editor no longer shows the Countries Filter option on the partners page, where it does not apply. This prevents confusion for editors by keeping customer-page settings visible only where they actually work.
Original PR description
Scenario: - install website_customer and website_crm_partner_assign - go to /partners - in edit mode, disable the option "Countries Filter" Result: nothing happen Cause: there is no filter options on /partners page, but the options of /customers page are targetting class o_wcrm_filters_top that is common to both page, so they are shown on /partners incorrectly. Fix in stable: change the selector to only show options on /customers. Fix in master: in website_customer, change the o_wcrm_filters_top class to o_wc_filters_top class. opw-5102381 Forward-Port-Of: odoo/odoo#228575
This fixes an issue where Odoo Studio could create custom views based on the wrong inherited view. Customizations will now attach to the closest main view, helping avoid incorrect or fragile Studio changes.
Original PR description
…ry view Accidentally pass an inheriting view id to edit view. Before this commit, the studio view thus created inherited from the extension view After this commit, it inherits from the closest primary view. opw-4930800 Forward-Port-Of: odoo/enterprise#94747
Clearing text from the website search bar no longer reloads the search results page. This keeps existing results visible until the visitor chooses to run a new search, creating a smoother browsing experience.
Original PR description
Before this commit, clicking on the "x" button on the searchbar would refresh the page and remove the result immediatly. The user might want to keep the result if he does not do another search. This commit avoids refreshing the page when removing the input content. Steps to reproduce the bug: - Click on the search button in the navbar - Search "tree" - Press enter (You are redirected to /website/search) - Click on the "x" button to delete the input content (The page refresh) task-3570756 Forward-Port-Of: odoo/odoo#181506
This fixes an issue in Belgian reporting where a partner form field was linked to the wrong underlying view. It prevents update failures when accounting report modules are upgraded, improving reliability for Belgian reporting installations.
Original PR description
The citizen_identification field was added to the partner view in l10n_be_reports, but the form 281.50 view for this required field was incorrectly inheriting from the base partner view. That led to…
The citizen_identification field was added to the partner view in l10n_be_reports, but the form 281.50 view for this required field was incorrectly inheriting from the base partner view.
That led to a traceback when updating account_reports/l10n_be_reports modules in 19.0+ versions:
This fix PR is a backport requested from upgrade: https://github.com/odoo/enterprise/pull/92104#pullrequestreview-3144302023.
```py
Odoo Server Error
Occured on 86642809-master-all.runbot135.odoo.com on model ir.module.module on 2025-08-11 14:04:32 GMT
Traceback (most recent call last):
------- A lot of calls ------
convert_xml_import(env, module, fp, idref, mode, noupdate)
File "/data/build/odoo/odoo/tools/convert.py", line 745, in convert_xml_import
obj.parse(doc.getroot())
File "/data/build/odoo/odoo/tools/convert.py", line 616, in parse
self._tag_root(de)
File "/data/build/odoo/odoo/tools/convert.py", line 559, in _tag_root
f(rec)
File "/data/build/odoo/odoo/tools/convert.py", line 570, in _tag_root
raise ParseError(msg) from None # Restart with "--log-handler odoo.tools.convert:DEBUG" for complete traceback
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
odoo.tools.convert.ParseError: while parsing /data/build/enterprise/account_followup/views/partner_view.xml:4
Error while parsing or validating view:
Element '<xpath expr="//field[@name='citizen_identification']">' cannot be located in parent view
View error context:
{'file': '/data/build/enterprise/account_followup/views/partner_view.xml',
'line': 1,
'name': 'res.partner.view.form',
'view': ir.ui.view(5824,),
'view.model': 'res.partner',
'view.parent': ir.ui.view(127,),
'xmlid': 'res_partner_view_form'}
```
Forward-Port-Of: odoo/enterprise#96855Mobile users can now tap spreadsheet dashboard charts to open the related Odoo menu, matching the desktop experience. This makes dashboards easier to use on phones and tablets and reduces confusion when interacting with chart links.
Original PR description
Current behavior before PR: - Clicking on a chart in mobile did nothing, unlike on desktop where it redirects to the linked Odoo menu. Desired behavior after PR is merged: - Clicking on a chart in mobile also redirects to the corresponding Odoo menu. - The test has been refactored to remove duplication and improve readability. Task: [4884509](https://www.odoo.com/odoo/2328/tasks/4884509) Forward-Port-Of: odoo/odoo#225372
Fixed an issue where document icons on website pages could disappear when editing a translated version of the page. This keeps file links visually clear for visitors and editors across languages.
Original PR description
This commit permits to keep document icon visible during the translation of a website page. Steps to reproduce the issue: - Have a website in English (main) and French - Edit the website in the main lang (English) - Drop Image text block - Change the image to a document - Save - Edit the translation in French => The document logo becomes invisible. This commit fixes this issue. task-3626918 Forward-Port-Of: odoo/odoo#165109
The Swiss payroll wage type setup now exposes all backend configuration fields directly in the salary rule interface. This helps payroll administrators review and maintain ELM transmission settings more reliably without needing technical access or hidden configuration steps.
Original PR description
task-4954650 Forward-Port-Of: odoo/enterprise#96824
This fixes an issue where a Point of Sale session could not be closed after processing a negative order paid with a bank method requiring customer identification. The change helps avoid blocked cashier workflows and ensures session closing works even when payment setup is incomplete.
Original PR description
When using a bank payment method that needs to identify the customer, if you made a pos order with negative amount, the session would get stuck when trying to close it. Steps to reproduce: ------------------- * Create a bank payment method and check the option "Identify Customer" * Open a POS session * Make a pos order with a negative amount * Pay the order with the bank payment method * Close the session > Observation: There is an error and you cannot close the session. Why the fix: ------------ If the payment method has no oustanding account set, it will violate an sql constraint when trying to close the session. sql constraint: account_move_line_check_accountable_required_fields opw-4939806
The attendance system now correctly calculates when an employee has been checked in for more than 24 hours. This ensures old open attendances are automatically checked out as intended, improving accuracy in attendance and overtime records.
Original PR description
`.seconds` returns the seconds component of the timedelta, after extracting the days. For attendances checked in more than 24 hours ago (processed by the cron, see `previous_attendances` search domain), `total_seconds()` will correctly return the number of elapsed seconds. no-task
This fix ensures the SEPA Direct Debit app automatically includes the payment component it needs. It prevents installation or update failures when that required payment functionality was not already installed.
Original PR description
In Odoo 18, the view `account_sepa_direct_debit.account_payment_register_form_inherit_account_sepa_direct_debit references ` the field `payment_method_code` from `account.payment.register`. This field is added to the model in the `account_payment` module, which is not among the dependencies of `account_sepa_direct_debit`. This means that if the `account_payment` module is not installed, the installation/update of `account_sepa_direct_debit` will also fail. Here’s a screenshot of the error (runbot) <img width="1498" height="857" alt="image" src="https://github.com/user-attachments/assets/c878b2d2-fcea-467f-bfaf-ff1d48481eb4" /> [OPW 5139827](https://www.odoo.com/es_ES/my/tasks/5139827) @moduon MT-11953
Spreadsheet list side panels now keep working even if a field was removed during a migration or after deleting a custom field. This prevents users from being blocked when editing affected lists and makes migrated or customized spreadsheets more resilient.
Original PR description
If a field disappeared from a list following a migration or a deleted custom field, the list could no longer be edited in the sidepanel because we tried to access the missing field info (name & string) Task-4915281
10 changes
Resolved issues and error corrections
This fixes an issue that blocked users from creating related one-to-many fields when no inverse relation field was available. It improves model customization reliability for configurations that depend on related records.
Original PR description
…n_field Before this commit, it was not possible to create a related one2many without a relation_field (inverse) However, the relation_field of a relation cannot be the one of the original field (because it doesn't exist on the current model) After this commit, this flow works. opw-5155440 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 fix prevents Odoo Studio from saving an invalid field link when users create a related field to a customer's child contacts. It avoids crashes during later form updates, improving reliability for sales order customizations.
Original PR description
On sale order, create a related field to res_partner.child_ids Before this commit, the related field is not stored but has a relation_field to parent_id (res.partner) During an onchange (outside of studio), this will crash. After this commit, we unset relation_field in this case as it doesn't make sense (the relation_field should reference a res.partner field, not a field presetn in the current model) opw-5155440
Corrected how a Belgian reporting partner form is linked so it can find the required citizen identification field during module updates. This prevents update failures for Belgian reporting features and helps keep accounting-related upgrades running smoothly.
Original PR description
The citizen_identification field was added to the partner view in l10n_be_reports, but the form 281.50 view for this required field was incorrectly inheriting from the base partner view. That led to…
The citizen_identification field was added to the partner view in l10n_be_reports, but the form 281.50 view for this required field was incorrectly inheriting from the base partner view.
That led to a traceback when updating account_reports/l10n_be_reports modules in 19.0+ versions:
This fix PR is a backport requested from upgrade: https://github.com/odoo/enterprise/pull/92104#pullrequestreview-3144302023.
```py
Odoo Server Error
Occured on 86642809-master-all.runbot135.odoo.com on model ir.module.module on 2025-08-11 14:04:32 GMT
Traceback (most recent call last):
------- A lot of calls ------
convert_xml_import(env, module, fp, idref, mode, noupdate)
File "/data/build/odoo/odoo/tools/convert.py", line 745, in convert_xml_import
obj.parse(doc.getroot())
File "/data/build/odoo/odoo/tools/convert.py", line 616, in parse
self._tag_root(de)
File "/data/build/odoo/odoo/tools/convert.py", line 559, in _tag_root
f(rec)
File "/data/build/odoo/odoo/tools/convert.py", line 570, in _tag_root
raise ParseError(msg) from None # Restart with "--log-handler odoo.tools.convert:DEBUG" for complete traceback
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
odoo.tools.convert.ParseError: while parsing /data/build/enterprise/account_followup/views/partner_view.xml:4
Error while parsing or validating view:
Element '<xpath expr="//field[@name='citizen_identification']">' cannot be located in parent view
View error context:
{'file': '/data/build/enterprise/account_followup/views/partner_view.xml',
'line': 1,
'name': 'res.partner.view.form',
'view': ir.ui.view(5824,),
'view.model': 'res.partner',
'view.parent': ir.ui.view(127,),
'xmlid': 'res_partner_view_form'}
```
Forward-Port-Of: odoo/enterprise#96855Journal item reconciliation now reliably treats write-offs as standard journal entries, even when custom defaults are configured differently. This prevents avoidable errors about missing customer/vendor details or account type restrictions, helping accounting users complete reconciliations without interruption.
Original PR description
Behavior before commit: On certain configurations, attempting to reconcile a Journal Item through the wizard caused an exception to be thrown due to either a missing `partner_id` or incorrect account type. Root cause: The wizard used the default `move_type`. While this is usually `entry`, a customisation can change it. Since types other than `entry` have more robust requirements in terms of necessary fields (ie. `partner_id`) and account type limitations, this results in an exception being raised. Fix: Added a line in `write_off_vals` that explicitly assigns `move_type` as `entry`. Steps to reproduce: 1. Have unreconciled Journal Items. 2. Define a new User-defined default for the Journal Entry model, setting its default type to a value other than "Journal Entry". 3. Select an unreconciled Journal Item in the list view and attempt to reconcile it through the wizard. 4. Observe the exception pointing to a missing `partner_id` or incorrect account type. opw-5107155
The Barcode app now respects the Manufacturing operation type setting that blocks full order validation when no quantities have been scanned or entered. This prevents manufacturing orders from being completed accidentally and keeps barcode behavior consistent with other warehouse operations.
Original PR description
17.0+ In the Barcode app, users can fully validate a Manufacturing Order (MO) without scanning or adding quantities, even when the `Allow full order validation` option is disabled in the…
17.0+
In the Barcode app, users can fully validate a Manufacturing
Order (MO) without scanning or adding quantities, even when the
`Allow full order validation` option is disabled in the
Manufacturing operation type. This behavior is inconsistent with
other operations like pickings, where the setting is correctly
enforced.
- In Inventory / Configuration / Warehouse Management / Operations Types:
- Open `Manufacturing` operation type:
- Under `Barcode App` tab, uncheck `Allow full order validation`;
- In Manufacturing / Operations / Manufacturing Orders:
- Create a new MO wit any BoM and confirm it;
- Make it available for production (add stock on products if needed);
- In Barcode App:
- Move to `Manufacturing` and find your MO then click on it;
- Without adding quantities, click on `Produce`:
- The final product is considered as created.
**CAUSE**
When a picking type is scanned from the barcode main menu, the
picking type's config is not loaded. This results in (among
other options) the full validation option is not properly set
once inside the barcode component.
**FIX**
Use the picking type record of the scanned mrp operation to get
the config and any required default records in the barcode cache
upon the intial load.
opw-4461309Fixed an issue where using the keyboard in the Helpdesk website knowledge base search suggestions could trigger an error page. This makes the customer self-service search experience more reliable and prevents disruption while browsing help content.
Original PR description
Steps to Reproduce: 1. Navigate to '/helpdesk/customer-care-1/knowledgebase'. 2. Enter any text in the search bar to trigger suggestions. 3. Press the down arrow key twice. 4. A traceback error occurs, indicating an Odoo Client Error. Before this commit, we had a crash when a user types something in a searchbar in the website helpdesk and do keydowns: "Cannot read properties of undefined (reading 'nextElementSibling')" To fix this, we need to add the 'data-bs-toggle' attribute to let BS find it to set '_element' (which must be the previous sibling of the dropdown-menu). This data attribute was probably not set before because in this case the BS dropdown is not used on a button or a link as documented; we use it as an autocomplete functionnality. task-4752497
Project revenue now remains visible even when the related prepaid service product has been archived. This keeps project financial status accurate for sales and project teams reviewing past or ongoing work.
Original PR description
**Steps to reproduce:** 1. Install the Sale, Project, and Timesheet modules. 2. Create a service-based product with `invoicing policy > Prepaid`, linked to `Create on Order > Project and Task`. Add a project template. 3. Create a sale order with that product. 4. Go to the created project and check the project status. **Observed behavior:** * Revenue is visible in project status while the product is active. * Once the product is archived, its revenue disappears. **Root cause:** Archived products were not considered when calculating revenue. **Solution:** Backport the fix from v18 to include archived products in revenue calculations. v18 pr : https://github.com/odoo/odoo/pull/129089 added test for product archive case. opw-5070289
This fixes an issue where the import screen could crash when a model offered more than one sample import template. Users can now see and choose from multiple templates reliably, with button spacing adjusted for a cleaner display.
Original PR description
Import templates are defined on models to allow developpers to provide
sample import files to users. These templates are fetched by the client
as an array of objects of the form {label: string, template: string},
where label is the label to display and template the URL of the file.
The iteration on `importTemplates` goes through this list, and if more
than one element is present in it, the t-key for both elements will be
the same (`[[object Object]]`), leading to a crash of the client
action's template.
This commit uses the 'template' url as the key, as it should be unique
(the label is less trustworthy, as it is translatable).
It also slightly changes the styling, as having an mb32 between multiple
buttons looked rather bad.Reverse charge taxes are now reported with the correct payable tax amount instead of zero in SAF-T exports. This helps businesses submit Romanian SAF-T reports that better match tax authority requirements and reduces the risk of incorrect filings.
Original PR description
When a reverse charge tax is used, we export a `TaxInformation` with a zero amount instead of the real amount of the tax. The tax authority requires to show the tax to pay and doesn't care about the tax to receive... In order to fix this, we only sum the tax details of lines having positive repartition lines. opw-5125678
Tooltip text in Live Chat, Discuss/Mail, and Point of Sale is now included in the normal translation process. This helps users working in different languages see clearer, localized guidance in those parts of Odoo.
Original PR description
Unless you tell Owl to do so, custom attributes like data-tooltip aren't translated. This commit adds the data-tooltip attribute to the list of translated attributes when missing. *: im_livechat, mail, point_of_sale