Tuesday, October 14, 2025
39 changes · saas-18.4
Resolved issues and error corrections
This update improves Odoo's internal Hoot testing tools so automated tests better match real browser behavior and produce clearer failure reports. It also simplifies how developers use test helpers, reducing confusion while keeping the changes limited to the testing ecosystem and lowering risk for business features.
Original PR description
## Pull Request HOOT 37 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Enterprise: https://github.com/odoo/enterprise/pull/96647 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231060 Forward-Port-Of: odoo/odoo#230556
This update adjusts an internal test workaround in the Gantt planning area so automated checks continue to run correctly after recent testing changes. It is limited to the unit test environment and should not affect day-to-day product behavior.
Original PR description
## Pull Request HOOT 37 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Community: https://github.com/odoo/odoo/pull/230556 Forward-Port-Of: odoo/enterprise#96886 Forward-Port-Of: odoo/enterprise#96647
This fixes an internal Peppol test so it no longer depends on Belgian localization logic that may not be present in all build configurations. The change helps keep Odoo's automated checks stable and reduces false failures during releases.
Original PR description
This commits fixes test we previously added [1]. In Belgium, the Company Registry (0208) and the VAT number (9925) can be computed from each other (`0208:0400000000` <-> `9925:BE0400000000`). [This compute](https://github.com/odoo/odoo/blob/0d8aadb2db7f10d439e10f222ec0ab6dcfab3672/addons/l10n_be/models/res_partner.py#L13) is actually only available in l10n_be, while the test rely on it to deduce the expected EAS, and therefore fails on single Apps builds. [1]: https://github.com/odoo/odoo/pull/230880 [runbot-error-233343](https://runbot.odoo.com/odoo/runbot.build.error/233343) Forward-Port-Of: odoo/odoo#231314
This fix prevents the Invoicing dashboard from crashing when users customize its default grouping in Studio and the selected group has no records. The dashboard now handles empty groups gracefully, so users can continue configuring views without interruption.
Original PR description
Currently an error occurs when a user tries to group account dashboard with a group not having any records. **Steps to replicate:** * Install `account` and `web_studio` * Invoicing > studio > Default…
Currently an error occurs when a user tries to group account dashboard with a group not having any records. **Steps to replicate:** * Install `account` and `web_studio` * Invoicing > studio > Default Group by > Account Online Link **Error:** `SyntaxError: syntax error at or near ')' LINE 19: WHERE j.id in () ^` **Root cause:** * The compute function [1] contains an SQL query that assumes journal IDs are always present. When the account dashboard is grouped by a category with no records (e.g., 'Online Account' when none are connected), no journals are returned, resulting in no journal IDs for the SQL query at [2]. * This issue appeared after PR [3], where the compute method is called even when the record isn’t saved, leading to NewId being passed to self and triggering this error. Similar fixes were applied in commit [4]. **Solution:** * Only run the SQL query if journal IDs exist. If none do,assign false to the computed entry fields. This works because [5] creates a fake group, allowing the dashboard to work normally. [1]: https://github.com/odoo/odoo/blob/a9a058aa063a05755ac3c6a78f99af5373d19fbd/addons/account/models/account_journal_dashboard.py#L205 [2]: https://github.com/odoo/odoo/blob/a9a058aa063a05755ac3c6a78f99af5373d19fbd/addons/account/models/account_journal_dashboard.py#L227 [3]: https://github.com/odoo/odoo/pull/195203 [4]: https://github.com/odoo/odoo/commit/7ba64a8c51f2888b301ee6feae140b02ca4b1b95 [5]: https://github.com/odoo/enterprise/blob/110c23ae23a1c37c15e7913bdcb74f2a26a67858/web_studio/static/src/client_action/view_editor/editors/kanban/kanban_editor.js#L51-L64 sentry-6674695712 Forward-Port-Of: odoo/odoo#230919
Users who open a product forecast in a newly created company without any warehouse will now see a clear warning instead of an error. This prevents a confusing crash and helps users understand what setup is missing before viewing stock forecasts.
Original PR description
Step to reproduce: - install stock - create a new company and switch to that company - open a storable product - click on forecasted smart button Cause: - StockForecasted component needs at least 1 warehouse, but when we create a new company, it does not have any warehouse https://github.com/odoo/odoo/blob/7747c5810eabe798a1631c3e3b26b81a5c89b4b4/addons/stock/static/src/stock_forecasted/stock_forecasted.js#L49-L52 - clicking on the smart button, raises traceback Fix: - we show a warning when the smart button is clicked and no warehouse is found **Note**: not adding a test case, as issue is not reproducible in test mode due to this https://github.com/odoo/odoo/blob/de264d99c22283390d18beb7c7c62c29824f72b3/addons/stock/models/res_company.py#L197-L198 opw-5059799 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225698
Fixes issues on blog pages where dates could appear misaligned and selected tag filters could be lost when changing archive date filters. This helps visitors keep their chosen blog filters intact and improves the visual consistency of blog listings.
Original PR description
This PR addresses the following issues: **Issue 1: Date Misalignment** **Steps to Reproduce:** 1. Navigate to website → Blog Page → Edit. 2. Change the layout from Grid to List. 3. Toggle the Cards…
This PR addresses the following issues:
**Issue 1: Date Misalignment**
**Steps to Reproduce:**
1. Navigate to website → Blog Page → Edit.
2. Change the layout from Grid to List.
3. Toggle the Cards button on.
4. The date and tags will appear slightly misaligned.
**Solution:**
Adding `#{` code in the `t-attf-class` attribute will align the date with the blog post content and tags.
**Expected Behavior:**
The date should align with the blog post content and tags preview.
**Issue 2: Some Tag Filters Getting Removed**
**Steps to Reproduce:**
1. Add a date filter from the sidebar of the blog.
2. Remove this filter by clicking the X button.
3. If multiple tags are present in the filter section, only the first tag remains while the rest are removed when the date filter is added or removed.
**Solution:**
Sending a POST request whenever the date filter is selected or removed. To achieve this, we introduced the `post_link` class to the `<select>` and `<a>` elements. When a date option is chosen, the click event triggers the `_onClickPost` handler
function, which extracts the URL from the `value` attribute of the `<option>` tag.
**Expected Behavior:**
All previously added tags should remain after adding or removing the date filter.
**Issue 3: All Tag Filters Getting Removed**
**Steps to Reproduce:**
1. Navigate to website → Blog Page → Turn On the Sidebar.
2. Select any tag from the tags section in the sidebar.
3. Ensure no blog is selected.
4. Select a date from the archives in the sidebar.
5. Change the date to '-- All Dates' in the archives dropdown.
6. All tags in the filter are removed along with the date.
**Solution:**
Removing the condition for navigation based on whether a blog is present or not will ensure tags remain in the filter section after selecting the '-- All Dates' option.
**Expected Behavior:**
Tags present in the filter section should remain after selecting the '-- All Dates' option.
task-3937884
Forward-Port-Of: odoo/odoo#230592
Forward-Port-Of: odoo/odoo#225845Point of Sale payments made through a payment terminal now complete automatically when cash rounding is applied. This prevents staff from needing to manually validate fully paid orders, reducing checkout delays and the risk of missed validations.
Original PR description
Ensure that when a payment is made via a payment terminal and cash rounding is applied, the payment is automatically validated once the response is received. Previously, validation did not always occur because we relied on `get_due` is not exactly what is left to pay, as it does not account for cash rounding rounded amounts. The condition for auto-validation was simplified, since `is_paid` already checks whether there is nothing left to pay. Thus, using `get_due` is redundant. Steps to reproduce: 1. Create a cash rounding and set it on the POS. 2. Sell a product priced at e.g. 1.99 EUR, paid via a terminal (e.g. Worldline). 3. Notice the payment is not auto-validated and requires manual validation, which can lead to mistakes or missed manual validations. opw-4862684 Forward-Port-Of: odoo/odoo#231153 Forward-Port-Of: odoo/odoo#228608
The Subscriptions MRR Breakdown report now ignores archived companies when preparing its data. This prevents access errors in multi-company setups where the original company has been archived and another company with a different currency is active.
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
Invoices that qualify for an early payment discount are no longer incorrectly marked as fully paid when only a partial payment is received. This prevents the unpaid balance from being moved to a suspense account, giving accounting teams a more accurate payment status and cleaner reconciliation.
Original PR description
Problem: If partial payment is done for Invoice which is eligible for early payment discount, Invoice is marked as paid and remaining amount is debited in suspense account. Cause: While preparing credit entry for receivable account, only eligibility of Invoice for early payment discount was checked and whole residual amount of Invoice is credited instead of amount which is paid, and this is done for partial payments also(which shouldn't be done). After this commit: If partial payment is done for Invoice which is eligible for early payment discount, Invoice is marked as partially paid and only amount which is paid is credited from receivable account and nothing in suspense account. task-5128802 Forward-Port-Of: odoo/enterprise#95994
UrbanPiper POS orders now apply the correct product taxes when the POS is set up under a company branch. This prevents undercharged orders in multi-branch setups and also handles split taxes such as GST more reliably.
Original PR description
Steps to reproduce: --- - Install `pos_urban_piper`. - Create a branch under *Main Company*. - Switch to the new branch. - Create a POS config in this branch and set up UrbanPiper. - Sync "Apple Pie". - Place an order with "Apple Pie". Issue: --- - The 15% tax defined on Apple Pie is not applied on the orderline. Cause: --- - While creating the order line, the tax company was compared directly with the POS config’s company. In this case, the tax belongs to the parent company, while the POS config belongs to a child company. Fix: --- - Compare the `root_id` of both companies instead of the direct company ID to ensure taxes are applied correctly in multi-branch setups. - Additionally, handled the case where a main tax has sub-taxes (e.g., 5% GST split into 2.5% SGST and 2.5% CGST). In such cases, we now fetch the tax type from the sub-taxes instead of the main tax. Task-5050682 Forward-Port-Of: odoo/enterprise#96672 Forward-Port-Of: odoo/enterprise#93467
This fixes an issue where time off spanning two allocation periods could incorrectly count a public holiday as extra leave. Employees and HR teams will see more accurate leave balances when vacations overlap public holidays at the start of a new allocation period.
Original PR description
### Steps to reproduce: - Install Time off apps - Create two consecutive allocations (e.g. one for 2025 and one for 2026) - Create a leave that overlap with the two allocation (e.g. from 8th Dec to…
### Steps to reproduce: - Install Time off apps - Create two consecutive allocations (e.g. one for 2025 and one for 2026) - Create a leave that overlap with the two allocation (e.g. from 8th Dec to 3rd Jan) - Create a public holiday at the beginning of the second allocation (e.g. on 1st Jan 2026) ### Cause: When we are checking the leave duration after having a public holiday the will return the attendance without the public holidays duration so when subtracting the attendance duration from the leave duration we will have a remaining amout equals to the public holiday duration and it will be considered as excess days. https://github.com/odoo/odoo/blob/06e47d8601ba56b1650eeaeef71ebd7a4af39b8b/addons/hr_holidays/models/hr_employee_base.py#L228-L230 https://github.com/odoo/odoo/blob/06e47d8601ba56b1650eeaeef71ebd7a4af39b8b/addons/hr_holidays/models/hr_employee_base.py#L246-L254 ### Fix: We check for public holidays in the interval we are fetching its attendance to avoid assuming it is an excess days in the leave opw-5006119 Forward-Port-Of: odoo/odoo#230861 Forward-Port-Of: odoo/odoo#225433
This fix prevents an invoice delivery preference message from showing when customers cannot actually choose a delivery method. It reduces confusion on the customer portal by only displaying the guidance when the related option is visible.
Original PR description
Currently, there is no validation in place to determine when the labe related to invoice_sending_methods should be added to the portal_my_details_fields template in the inheritance made in [1].
This results in the following:
For invoice_sending_methods, the label/message: 'You can choose how yo want us to send your invoices, and with which electronic format.' is always displayed, even if the <select> to define the method is not visible.
Now, a validation has been added to display this label only when necessary, in order to avoid user confusion.
[1]: https://github.com/odoo/odoo/commit/de567b6
Before:
After:
Forward-Port-Of: odoo/odoo#229962
Forward-Port-Of: odoo/odoo#200261Printing Kanban views with many records now handles page breaks more reliably. This prevents cards from being cut off at the top of later pages, making printed views easier to read and use.
Original PR description
This commit fixes the kanban view print to better handle the page break. The issue was caused by the flex layout: when printing, heights often misbehave on the last row or at page breaks. task-4630646 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230927 Forward-Port-Of: odoo/odoo#229259
Payroll processes now identify a company's country through its linked partner record instead of a field that cannot be searched reliably. This helps payroll exports and Swiss payroll transmissions select the correct companies without search errors.
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 Dutch accounting setup now uses the correct default deferred accounts. This helps Dutch companies start with more accurate accounting configuration, including classifying deferred expenses under current assets.
Original PR description
The default deferred accounts in the Dutch localization were incorrect. This commit sets the proper accounts and adjusts the `account_type` of the default deferred expense account from "Prepayments" to "Current Assets". task-5152529 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230902 Forward-Port-Of: odoo/odoo#230499
Fixes an error that could block Romanian E-Factura submission when a bank is linked to an invoice payment reference. The change ensures bank address details are read correctly, improving reliability for electronic invoicing workflows.
Original PR description
Issue: When setting up a payment reference and linking a bank to an invoice, sending an E-Factura (SPV) triggers an exception: state_id not defined for rev.bank. Cause: The state field is defined differently for rev.bank and rev.partner. rev.partner uses state_id, while rev.bank uses state. The code that retrieves addresses assumes the same field for both, leading to an exception when accessing state for rev.bank. Fix: The fix checks the type of the input and selects the appropriate field (state or state_id) accordingly. Test: Linked the bank in the test suite. The test fails without this fix, confirming the issue is resolved. opw-5099816 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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
The duplicate-transaction warning in bank synchronization now opens the correct tool again. This helps accounting users quickly review possible duplicate bank transactions instead of hitting a broken action.
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
Users returning to kanban, pivot, or mobile list views now land back at the same scroll position they left, instead of being reset. This makes navigation smoother when using breadcrumbs or switching views, especially on longer records and grouped kanban boards.
Original PR description
When coming back to a view using the breadcrumb or with the view switcher, we want to restore the local state of the view as it was when we left it, in particular the scroll position. This is handled…
When coming back to a view using the breadcrumb or with the view switcher, we want to restore the local state of the view as it was when we left it, in particular the scroll position. This is handled by the `useSetupAction` hook, for all views (except for the list as the scrolling container is custom, because of the fixed table header). However, since [1], it was no longer working in kanban, pivot and list (mobile only). This was due to the fact that those views are now "lazy", i.e. they are rendered directly, without the data, such that the control panel is available asap. As a consequence, when `onMounted` is called (i.e. when the hook attempts to restore the scroll position), there's no scrollable content yet. This commit fixes the issue by allowing the controllers to restore the scroll position themselves, when their content is ready. In addition, a custom treatment was necessary for the kanban view, in mobile *and* if grouped, as each column has its own vertical scrollbar. [1] https://github.com/odoo/odoo/pull/205129 task~5086324 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#230968
The QR Menu for Belgian blackbox point-of-sale setups now loads even when the point-of-sale session has not been opened. This prevents customers from seeing a blank menu page and helps businesses keep digital menus available before opening a register session.
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 the value used when neutralizing Nemhandel-related users so it matches the expected Nemhandel proxy type. It helps ensure account EDI proxy cleanup or anonymization handles Danish Nemhandel records correctly.
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 popups, side panels, and notifications now automatically use the website's selected color palette. This improves visual consistency and helps these interface elements remain clear and readable across customized site 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 inside website card snippets now follow the same rounded corners as the card itself. This fixes a small visual inconsistency so website content looks cleaner and more polished.
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