Daily updates from Odoo
Tuesday, April 29, 2025
9 changes
2 changes
Resolved issues and error corrections
Bank reconciliation now handles statement groups that do not include a balance, preventing an error that could interrupt users reviewing bank statement lines. Invalid statement groups are also clearly highlighted so users can identify records that need attention.
Original PR description
The aim of this commit is fixing a traceback when we have a statement group with no balance passed as props. It could happen when we have statement lines without any statement between 2 groups of statement lines with statement. This commit changes the component to set this props as optional (as before) and adds a new props "isValid" to put the label of the statement group in text-danger when the statement is not valid. no task id
EC Sales List return checks now apply consistently across all relevant countries, not only Belgium. Warning messages are clearer, and a bug was fixed so failed checks are correctly recognized before submission.
Original PR description
[IMP] account_reports: EC Sales List return: checks improvement - Make the checks generic for all returns made for any EC Sales List, not just for Belgium - Improve the phrasing of the check messages [FIX] account_reports: EC Sales List generic check: wrong warning keys The account_reports prefix was missing ; so the check was never considered a failure.
2 changes
Resolved issues and error corrections
This fixes the order in which certain hardware device drivers are selected so that the correct driver runs first. It prevents Adam equipment handling from interfering with Blackbox devices, improving reliability for connected IoT hardware.
Original PR description
Enterprise PR: https://github.com/odoo/enterprise/pull/84122 Since commit ae16d9d, the Adam driver priority has been incorrectly set higher than it should be. The issue was a side-effect of removing…
Enterprise PR: https://github.com/odoo/enterprise/pull/84122 Since commit ae16d9d, the Adam driver priority has been incorrectly set higher than it should be. The issue was a side-effect of removing the meta-class, since it no longer registered the `Driver` base class as a driver. The fix was just to simplify the priority system to not be affected by inheritance. Then we manually set the Adam priority to -1, and the Blackbox priority to 1. Everything else will have priority 0. For a detailed breakdown of the old behaviour and the cause of the bug, keep reading: The priority system was influenced by inheritance - the more levels of inheritance, the higher the priority. For example, in saas-18.1, you get these priorities: - `SerialBaseDriver`: 1 - `BlackBoxDriver`: 2 - `ScaleDriver`: 2 - `Toledo8217Driver`: 3 The Adam driver sets its priority to zero, but it still gets +1 from the meta class. So the final priorities are as follows in saas-18.1: - `SerialBaseDriver`: 1 - `AdamEquipmentDriver`: 1 - `BlackBoxDriver`: 2 - `ScaleDriver`: 2 - `Toledo8217Driver`: 3 This results in the Adam driver runs last. In saas-18.2, the priorities are shifted by 1 due to the `Driver` base class not being registered, but the Adam driver still ends up with the same value. So the priorities now look like this: - `SerialBaseDriver`: 0 - `AdamEquipmentDriver`: 1 - `BlackBoxDriver`: 1 - `ScaleDriver`: 1 - `Toledo8217Driver`: 2 The Adam driver and blackbox driver have the same priority, so the Adam driver could end up running first and breaking the blackbox. task-4750364 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Automation rules that run custom Python code now handle individual record errors more safely. This prevents one failed rule execution from repeatedly disrupting scheduled automation runs, improving reliability for administrators using automated actions.
Original PR description
SQL traceback occurs when user creates their own automation rule involving python code. **Steps to reproduce:** Install base_automation,discuss if not already installed * `Setting>…
SQL traceback occurs when user creates their own automation rule involving python code.
**Steps to reproduce:**
Install base_automation,discuss if not already installed
* `Setting> Technical>Automation rules`
* name it as `Whatsapp add admin`
* model as `discuss channel` and trigger `after creation` any amount of time
* `Add an action>Execute code`
* Add the following code:
```python
try:
env['discuss.channel.member'].create({ 'partner_id': 1, # Likely invalid 'channel_id': 1, })
except Exception:
pass
env['res.partner'].search([], limit=1)
```
* Go to `techinical>automation>scheduled actions>Automation rules:check and execute` run it manually.
`ValueError:InFailedSqlTransaction('current transaction is aborted, commands ignored until end of transaction block\n') while evaluating
'model._cron_process_time_based_actions()'`
**Solution:**
* Place try and except inside the loop to handle errors per record and allow the loop to continue and handle the transaction error better.
* This will only one occurence of the error instead of repeating occurrence each time the cron runs.
**Sentry-6562754804**
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr5 changes
Resolved issues and error corrections
Withholding calculations now use the correct company or branch records when determining taxable amounts and prior withholdings. This prevents payments or vendor bills made in a branch from being incorrectly affected by the parent company's accounting entries.
Original PR description
When calculating earnings-based withholdings in company-branch setups, the logic incorrectly referenced accounting entries from the mother company if the user belonged to a branch. This led to incorrect accumulation of taxable base amounts and previously withheld amounts, especially when vendor bills or payments were made in a branch. This fix ensures that: - The accumulation logic in `_tax_compute_all_helper` correctly scopes move line searches using the user's company. As a result, withholding retention now behaves correctly in company-branch environments. opw-4581579 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Multi-page PDF quotes using the Bubble or Boxed document layouts now display the totals table correctly on the final page. This prevents totals from being cut off at the bottom of the previous page, improving the readability and professionalism of customer-facing quotes.
Original PR description
## Version: 18.0+ ## Issue: PDF quotes on multiple pages having only the total table on the last page encounter a display issue. The total table is cut and partially displayed at the bottom of the…
## Version:
18.0+
## Issue:
PDF quotes on multiple pages having only the total table on the last page encounter a display issue. The total table is cut and partially displayed at the bottom of the penultimate page.
## Steps to reproduce:
- Install Sales app;
- Navigate to the Settings app:
- Under the `Companies` section, configure the document layout: - Ensure the `Bubble` (or `Boxed`) layout is selected;
- Navigate to the Sales app:
- Create a new quote with 8x `Chair floor protection`;
- Via the `Actions` gear button, print the `PDF Quote`.
## Cause:
Complete code refactoring for documents layouts styles introduced by https://github.com/odoo/odoo/pull/169512 has probably not been tested on that use case.
## Fix:
<img width="1105" alt="Capture d’écran 2025-04-03 à 10 25 58" src="https://github.com/user-attachments/assets/67bce15e-c5e9-40f8-9fbf-7721afc98ae5" />
opw-4624623
opw-4627809
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prBelgian payroll declarations now support the updated Dimona V2 requirements. This helps companies remain compliant when submitting employee contract information to the Belgian authorities.
Salary attachments, such as garnishments or deductions, are now applied only when the employee's payslip uses the appropriate input-based salary structure. This prevents incorrect payroll calculations in cases where a different salary structure is used, helping ensure employees are paid accurately.
Original PR description
task-4751862
Customer statement PDFs sent for multiple partners now use the correct company information when generated in the background. This prevents wrong addresses, footers, and other company details from appearing on statements in multi-company setups.
Original PR description
### Steps to reproduce: - Accounting > Reporting > Partner Ledger - Select multiple partners - Select "Customer Statements" as report - Click "Send" - Go to the one of the partner in question and open the generated PDF - The address is not the one of the company, the footer doesn't show the right company, etc ### Cause: When sending to multiple partners, the action is dispatched with cron so a new `env` is created. This `env` has all companies active and the first one as main company. So in the end the wrong company is used to generate the report. ### Solution: In the cron when calling `_process_send_and_print` we give `report.with_company(company)` to make sure that the value the report will us are the one from the correct company. Also revert the small [fix](https://github.com/odoo/enterprise/pull/82320/files) that was made before, which is no longer needed. opw-4635283