Tuesday, October 14, 2025
25 changes · saas-18.4
Enhancements to existing features
The Peru localization now includes the required withholding tax and tax group by default. This helps identify customers who are withholding agents and supports upcoming invoice XML compliance updates.
Original PR description
Withholding taxes are required to indentify if a customer is a withholding agent. This PR introduces the tax and tax group for the enterprise PR that will generate the changes for the Invoice XML. task-4989463
Peruvian invoices can now include the required withholding reference when the customer is a withholding agent. This helps companies meet local electronic invoicing requirements for these customers while keeping the withholding amounts out of invoice totals as required.
Original PR description
Some customers in Peru are considered "agentes de retención", and as such have special considerations that are necessary. We must perform specific actions when working with these customers, when selling to them we must: - recieve a specific document from the customer (A followup task will add this support for companies to generate this document) - Include a retention reference in our XML. This is represented as a specific `AllowanceCharge` node that is the sum of all of the Withholding taxes on the lines with the specific code of 62. We know an invoice is to a withholding customer because all lines must have a tax that is a part of the withholding tax group. This withholding tax is not included in the monetarytotals, tax totals, or invoice line values. And there can be only one AllowanceCharge node per invoice, not one per line. task-4989463
The account merge process now gathers existing account codes in one database query instead of checking each company one by one. This reduces waiting time during account merges, especially in databases with many companies.
Original PR description
The merge wizard needs to collect the account codes of the accounts we are merging in order to write them on the merged account as the final step of the merging process. At the moment, collecting the account codes is done in Python and loops over all the existing root companies, retrieving the code of the account for each company. On a recent l10n [runbot](https://runbot.odoo.com/runbot/build/90542336) (with 146 companies), this was causing the merging step to take ~4.5 seconds per account, most of this time being taken just by collecting the account codes. Instead, we collect the codes in a single SQL query. Flamegraphs: [before.json](https://github.com/user-attachments/files/22726956/before.json) [after.json](https://github.com/user-attachments/files/22726960/after.json) task-none Forward-Port-Of: odoo/odoo#230158
Companies using Austrian POS integration can now automatically invite their configured company email to access the Fiskaly dashboard. If the email changes, a new invitation is sent, and existing Fiskaly organization details are kept up to date.
Original PR description
In this commit: ------------------ - If a company email is set in the company information, we send an invitation to that email, allowing the user to access their company data on the Fiskaly dashboard by logging in using the company email. - If the email is later updated, access invitation will automatically be sent to the new email. - If the fiskaly organization exists, we should update the organization data even if the authentication is remaining to keep the data uptodate. Related PR: https://github.com/odoo/iap-apps/pull/1098 Task: 4881786 Forward-Port-Of: odoo/enterprise#88106
UAE payroll now excludes unpaid sick leave and out-of-contract unpaid leave when calculating end-of-service payments and provisions. End-of-service payslips also show the total unpaid leave days, making the calculation clearer for payroll teams and employees.
Original PR description
This commit excludes the Out Of Contract Unpaid Leaves and Unpaid Sick Leave days from the EoS and EoS Provision Salary Rule Calculations. We also show the total number of unpaid leave days on the EoS payslip. task-4886104 Forward-Port-Of: odoo/enterprise#96965 Forward-Port-Of: odoo/enterprise#95465
Resolved issues and error corrections
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
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
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 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
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
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 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
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