Daily updates from Odoo
Thursday, July 3, 2025
25 changes · master
Resolved issues and error corrections
This fixes an error that could appear when adding a rental product with variants to a renewed subscription before rental dates were set. The product configurator now only uses rental dates when they are actually available, preventing interruptions in the renewal flow.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Create a rental product with multiple variants; 2. create a subscription order via the Rental app; 3. add the rental product; 4. confirm & invoice the subscription; 5. renew the subscription; 6. add the rental product to the renewal. Issue ----- > `Uncaught Promise > value.setZone is not a function` Cause ----- Commit 76526bdb3835 implemented the `_getAdditionalDialogProps` method for using OWL in the product configurator. In our flow, it simply checks whether the order is a rental order, and if so, it attempts to serialize its rental dates. Issue is that rental dates are not a required field as long as the order hasn't been confirmed yet, causing the traceback. Solution -------- Instead of checking whether it is a rental order, verify that the order has rental dates before attempting to serialize them. opw-4898437 Forward-Port-Of: odoo/enterprise#89016 Forward-Port-Of: odoo/enterprise#88629
The point of sale preparation display no longer shows an error when an order is marked done quickly in debug mode. This improves reliability for teams using preparation screens by avoiding a disruptive crash in a specific timing case.
Original PR description
Steps to reproduce: - Open a preparation display in debug mode - Make an order that will appear on the preparation display - Click on the done button before 5 seconds - Traceback will appear 5 seconds after the order was received Issue: When receiving an order useDelayedValueChange is called in the setup of the Orderline component. This method will try to access the props after a timeout. When the preparation orders are deleted in debug mode, the states are deleted from the front end. Since the props of orderline are the preparation state linked to it a traceback arises. Fix: A check is added to check if the state record exists. Forward-Port-Of: odoo/enterprise#88136
This fixes an issue where the journal entry shortcut could disappear when creating a draft entry for one payslip inside a batch. Payroll users can now reliably access related journal entries even when other payslips in the batch are not yet completed.
Original PR description
**Steps:** - Install the hr_payroll_account module - Navigate to the payroll menu and open a batch payslip. - Select a batch containing two or more payslips and create a draft entry for any single…
**Steps:** - Install the hr_payroll_account module - Navigate to the payroll menu and open a batch payslip. - Select a batch containing two or more payslips and create a draft entry for any single payslip in the batch. --- **Description of the issue/feature this PR addresses:** When a draft entry is created for a single payslip within a batch, the journal smart button becomes invisible. --- **Cause:** The issue occurs during the account move creation process. When generating an account move for a batch payslip, the process checks the status of all payslips in the batch. If any payslip is not in the done state, the account move is not created, resulting in the journal smart button not appearing. --- **Fix:** This PR adjusts the account move creation logic to allow account moves to be created for batch payslips, ensuring the journal smart button remains visible even if some payslips are not in the done state. task-4440533 Forward-Port-Of: odoo/enterprise#76681
The scheduled payroll data update has been adjusted to run once per week instead of more frequently. This reduces unnecessary background processing while keeping payroll-related data refreshed on a regular cadence.
Original PR description
Forward-Port-Of: odoo/enterprise#88564 Forward-Port-Of: odoo/enterprise#88492
The salary configurator will now show Belgium-specific minimum wage warnings only for employees in Belgian companies. This prevents irrelevant wage alerts from appearing for employees in other countries when the Belgian localization is installed.
Original PR description
The warning for a basic wage below minimum level appears for non Belgian employees, such as L10N_US, because the L10N_BE was installed. The logic for the warning has been limited to be applied only on Belgian companies. Task #4907771 Forward-Port-Of: odoo/enterprise#88939
The Kenyan payroll SHIF/NHIF report now selects payslips for the exact month chosen, preventing payslips from one month appearing in another month's report. The wizard text was also simplified by removing a confusing line about the selection period.
Original PR description
- load payslip according to the Month value, currently, may payslip appears on june selection - remove the line 'the selection will cover ...' task-4775801 Forward-Port-Of: odoo/enterprise#89128 Forward-Port-Of: odoo/enterprise#85609
This fix updates the Mexican payroll salary rule conditions so employee subsidy calculations apply only when appropriate. It helps payroll teams produce more accurate payslips and reduces the risk of incorrect subsidy amounts.
Original PR description
task-4690544 Forward-Port-Of: odoo/enterprise#89067 Forward-Port-Of: odoo/enterprise#84780
This fixes an error that could block payslip generation for Mexican employees whose pay is entirely variable, such as commissions or bonuses without a fixed base salary. Payroll teams can now generate these payslips more reliably, avoiding manual workarounds and processing delays.
Original PR description
BUG An error is raised when trying to generate a payslip for an employee with only variable income (e.g., commissions/bonuses, no fixed base salary) FIX The rule's find_index function needs to return 0 instead of None in case the daily_wage does not fall within any of the measure ranges Task: 4723413 Forward-Port-Of: odoo/enterprise#89212 Forward-Port-Of: odoo/enterprise#85756
EasyPost delivery labels now include the Odoo delivery reference, making it easier to match carrier shipments with the correct Odoo delivery. This helps users identify and reconcile shipments more quickly in both Odoo and the carrier dashboard.
Original PR description
Issue ----- When using the Easypost delivery service, we don't pass the move reference to the carrier. This makes it hard for the user to match the deliveries found on the carrier dashboard with the…
Issue ----- When using the Easypost delivery service, we don't pass the move reference to the carrier. This makes it hard for the user to match the deliveries found on the carrier dashboard with the corresponding Odoo move. Steps to reproduce ----- - Set an Easypost delivery method up - Create a sale - Add delivery product & get a rate - Confirm the sale - Go to the linked delivery & confirm it --> The printed label has no reference field Discussion ----- As per EasyPost: > The reference field within the shipment body is used for transmissions of electronic data between the shipper and EasyPost, and typically does not get expressed anywhere on the physical label. To get data to the label, you need to leverage the "print_custom" fields outlined in the options section of the shipment. See also https://docs.easypost.com/docs/shipments/options Visual comparison ----- DPD UK labels, before and after the change:  USPS labels, before and after the change:  ----- Ticket: opw-4681615 Forward-Port-Of: odoo/enterprise#88941
This fix prevents payroll batch processing from failing when an employee has multiple version records returned during grouped payroll calculations. It helps payroll users complete payslip runs more reliably without encountering an unexpected error.
Original PR description
As we are using a read_group, that return an agregate of records, version may contain multiple version. If you get multiple records, you get a singleton error when trying to read date_version of version. So we append all version records into the all_employee_versions dictionnary Forward-Port-Of: odoo/enterprise#89143
OCR invoice processing now better handles multiple documents from the same supplier being processed at the same time. This prevents duplicate supplier contact records, improving data quality and reducing manual cleanup.
Original PR description
When the OCR parses documents from the same supplier concurrently, it can happen that it creates duplicated `res.partner` entry for it. This typically happen when the update of the documents is done…
When the OCR parses documents from the same supplier concurrently, it can happen that it creates duplicated `res.partner` entry for it.
This typically happen when the update of the documents is done through the webhook.
In that case, the different SQL transactions overlap each other and can't "see" the partner created by another request.
There are two kind of SQL transactions overlap that need to be handled:
- The partner creation is overlapping:
```
------------------------------------------------------------------> time
BEGIN INSERT COMMIT
T1: [ |-----------]
BEGIN INSERT COMMIT
T2: [ |----------]
```
This case can be handled by using an advisory lock on the VAT number of the partner to create. If the lock isn't available, it means the partner is being created concurrently and the transaction should be retried.
- The partner creation isn't overlapping:
```
------------------------------------------------------------------> time
BEGIN INSERT COMMIT
T1: [ |-----------]
BEGIN INSERT COMMIT
T2: [ |----------]
```
In that case, `T2` would be able to acquire the lock fine, but it can't see the partner created by `T1` in its main SQL transaction.
To fix this, we re-check the presence of a partner in a **new** SQL transaction.
The combination of those two mechanisms should ensure that no duplicated partners can be created.
task-[4904333](https://www.odoo.com/odoo/project/2068/tasks/4904333)Helpdesk email conversations now handle external recipients more reliably in automated checks. This helps ensure customer and external-contact replies include the right people while avoiding unnecessary alias recipients.
Original PR description
See community PR for more details. Task- Forward-Port-Of: odoo/enterprise#88900
A small typo in the Avalara tax integration was corrected so the system no longer calls a non-existent shared process during tax commitment. This is an internal reliability fix with no expected change to normal user workflows, but it helps avoid future errors in tax handling logic.
Original PR description
This is a typo from the most recent refactor [1]. The commit hook is specific to US avatax, there is no corresponding super().commit_external_taxes so this can be removed all together. This didn't break any tests because (at least with the standard code), super()._uncommit_external_taxes is an empty method that does nothing. [1] https://github.com/odoo/enterprise/pull/82623 Forward-Port-Of: odoo/enterprise#89216
Corrects how UK Bacs direct debit instruction data is returned so the system receives the expected values. This helps prevent processing errors introduced by a previous change and keeps direct debit workflows reliable.
Original PR description
Fix for b0083240ed6e0688f3ab2fe46916d71a6e08c06a where we returned a list of dicts instead of a dict of values.
Point of Sale users connected to UrbanPiper will no longer see the same online or offline status notification again after reloading the POS. This removes a duplicate alert and makes the checkout session experience smoother for staff.
Original PR description
Steps: ==== - Configured UrbanPiper credentials in `pos.config` and selected platform providers (e.g., Ubereats, Justeat). - On session start, a pop-up confirms the store is online on enabled platforms. - Reload the pos Issue : ==== - The same pop-up appeared again on POS reload, leading to a poor user experience. Fix: ==== - Removed duplicate call from `pos.store` that triggered provider status notifications unnecessarily. - Enhances user experience by preventing repeated popups on session reload. task-4879125 Forward-Port-Of: odoo/enterprise#88027
Fixed Chilean electronic factoring documents so the assigned amount is always reported in Chilean pesos, even when the invoice uses another currency. This prevents incorrect AEC XML values and helps ensure documents sent to the tax authority match local requirements.
Original PR description
In this bug, when a currency other than CLP is selected in invoicing, the generated aec has MontoCesion tag with the rate of selected currency, while it must always be in CLP. To reproduce the bug: 1- Create a database with invoice app and a Chilean company 2- Create an invoice with document type of 34 3- Choose a different currency than CLP 3- Click on `Send Now to SII` and Create AEC 4- Click on Yield Entry smart button 5- Download generated AEC xml file 6- You can see the value of MontoCesion is in selected currency which is wrong opw-4830957 Forward-Port-Of: odoo/enterprise#88175
Bookkeeper users can now process automatic follow-ups and manual reminders even when a customer is missing required contact details such as an email or address. This prevents access errors and helps accounting teams continue debt collection workflows without unnecessary interruptions.
Original PR description
Before this commit, a Bookkeeper user wasn't able to create a followup for a user with missing information (email or address) That error append using the manual_reminder and the Process Automatic…
Before this commit, a Bookkeeper user wasn't able to create a followup for a user with missing information (email or address) That error append using the manual_reminder and the Process Automatic Follow-ups For the Automatic Follow-ups action, the user wasn't able to access the 'missing information view' For the Followup Button (manual_reminder), that's in the follow-up report view, the user wasn't able to access either the 'manual_reminder view' or the 'missing information view' ## Steps in runbot 17.0: - Create an invoice with a past due date and a new customer (leave email empty) - Go in Accounting > Customers > Follow-up Reports - Select the In need of action report for your new customer - In Actions, click on Process Automatic Follow-ups - An AccessError should be displayed ## To test the manual reminder: - Create the invoice as before and go to Follow-up Reports - Open the report linked to your new customer - Click on the Follow up Button - An AccessError should be displayed opw-4848745 Forward-Port-Of: odoo/enterprise#88168
This fixes an internal reference so payroll expense records are handled as expenses rather than payslips. It helps avoid incorrect payroll-expense processing and supports more reliable payslip calculations.
Original PR description
this commit fixes wrong reference to `hr.payslip`. `payslip_expenses` should be a recordset of `hr.expense` and not `hr.payslip`. Forward-Port-Of: odoo/enterprise#89068 Forward-Port-Of: odoo/enterprise#88994
The Swedish SIE4 import now ignores extra object details that are not needed when importing transactions. This prevents those details from being mistaken for transaction balances, reducing the risk of incorrect accounting data during import.
Original PR description
The aim of this commit is ignoring the whole object list when we import transactions. The object list is represented by the elements between `{}` [[1]]. As we don't need these elements, we do ignore them to avoid a potential issue where we identify an element from this object list as the transaction's balance.
opw-4868415
[1]: https://sie.se/wp-content/uploads/2020/05/SIE_filformat_ver_4B_ENGLISH.pdf
Forward-Port-Of: odoo/enterprise#88892
Forward-Port-Of: odoo/enterprise#88784This update removes an outdated internal access-rule mechanism and adjusts several reports and workflows to use the newer approach. It helps ensure users see the right information consistently, especially in appraisal workflows where access could depend on cached data.
Original PR description
task-4067945 odoo/odoo#191775
CSV bank statement imports now continue more reliably by moving automatic reconciliation to a background process. The fix also prevents two imported lines from being matched to the same reconciliation candidate, reducing import failures and incorrect matches.
Original PR description
When doing an import of a csv in the bank rec widget, it could happens that the try_auto_reconcile throw an error which will lead in the rollback of the import. By triggering the schedule action auto_reconcile_bank_statement_line we will do the try_auto_reconcile in the back ground which will speed up the import process When importing, we pass a batch of statement lines to the try_auto_reconcile function, which identifies possible reconciliation candidates for each line. The issue arises because we iterate through each statement line and assign its potential candidate without checking for conflicts: if two statement lines map to the same candidate, we don’t verify whether that candidate has already been reconciled with a different line. opw-4888045,4890008 Forward-Port-Of: odoo/enterprise#88529
The Help menu now shows only the helpdesk teams assigned to the website a visitor is using. This prevents teams from other websites appearing in the wrong place, reducing confusion for visitors and staff managing support requests.
Original PR description
**Steps to Reproduce:** 1. Install the website_helpdesk module. 2. Create a Helpdesk Team A with 'Website Form' enabled, and set the website to 'My website' 3. Create another Helpdesk Team B with 'Website Form' enabled, and Set website to 'My website2' 4. Navigate to Website → Help menu on "My Website". **Observation:** - Both Helpdesk teams appear on "My Website", even though Team B is linked to "My Website 2". **Issue:** - The current domain filter only checks if the Website Form is enabled. - It doesn't restrict teams to the current website, so all teams are visible. https://github.com/odoo/enterprise/blob/b191f16abb5913893a228ccc4eedb8a2242a0298/website_helpdesk/controllers/main.py#L22 **Solution:** - Update the domain to filter on the website ID, to ensure only helpdesk teams related to the current website are shown. OPW-4673939 Forward-Port-Of: odoo/enterprise#88169
This fixes a mobile VoIP keypad issue where typing the first digit could place it at the end instead of the cursor position. Users entering phone numbers on mobile should now see more predictable and accurate input behavior.
Original PR description
This commit fixes a bug that caused the cursor in the keypad input to be displaced when typing on mobile. So, the first entered number was always to the end. This happens because the `on-touchend` event was calling another event (click) which may involve some changes in the UI that caused this. Steps to produce the bug: 1. Open VoIP wizard from mobile. 2. try to add numbers to the keypad. 3. You will see that the first number is always at the end. Forward-Port-Of: odoo/enterprise#89151
Adds test coverage to ensure employee records are created using the correct company context. This helps prevent payroll-related employee data, such as US social security number validation, from being checked against the wrong company setup.
Original PR description
This commit contains the test for commit f36104c17e0ac3cde788d195aab9394a35545d43 The test is in l10n_us_hr_payroll and not in hr as we need the ssnid constraint task-4897733 Forward-Port-Of: odoo/enterprise#88733
Fixed an issue where customized employee contract signing links could fail to open after generating an offer. The signing process now uses the correct signer-specific access token, helping applicants and employees complete contract signatures without interruption.
Original PR description
Steps to Reproduce: - Create a new contract template. - Define signatories to it(pref: employee) - create a offer linked to an applicant and try generating a offer and signing Fix: - Since the sign creating new role every time when we add new signer, we can't use the existing employee role id anymore. - Hence we will get the access token from signatory linked with the signer in the contract template and use that. task-4894597 Forward-Port-Of: odoo/enterprise#88953 Forward-Port-Of: odoo/enterprise#87420