Wednesday, February 26, 2025
8 changes · 18.0
Enhancements to existing features
Call invitations in Odoo Discuss are now automatically removed after 30 seconds if the recipient does not respond. This prevents unanswered calls from ringing indefinitely and reduces interruptions for busy users.
Original PR description
Before this PR, rtc invitations were only canceled when the user clicked on the decline button. Sometimes, users are busy and having this call invitation that keeps ringing forever is cumbersome. This PR removes this invitation after 30s. task-4345479 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
The Luxembourg payroll module has been updated with the official 2025 figures for tax credits and withholding tax rules. This helps ensure payroll calculations remain aligned with the latest government requirements for Luxembourg employees.
Original PR description
Update the official numbers of the Luxembourg payroll rules for 2025. task-4577491
Resolved issues and error corrections
Canceling a signed Mexican payment from the electronic invoice cancellation table now also cancels the related payment record. This prevents payments from incorrectly remaining posted after their accounting entry has been canceled, improving consistency for Mexican electronic invoicing workflows.
Original PR description
Since Odoo 18.0, account.payment no longer inherits from account.move. As a result, canceling a payment with `_l10n_mx_edi_cfdi_move_post_cancel` does not automatically cancel the associated payment record. Steps to reproduce: - Ensure the Mexican localization is installed and properly configured. - Generate an invoice and sign it with the government (CFDI). - Create and sign a payment for the invoice. - Cancel the payment from the CFDI table. Current behavior: - Odoo cancels the move, but the related payment remains posted. Expected behavior: - The payment should also be canceled when the move is canceled. This fix ensures that the associated payment is canceled correctly. opw-4528910
This fixes a crash that could happen when opening a vendor bill using cash rounding by tax after taxes were removed. Users can now continue editing these bills without being blocked by an error.
Original PR description
The Error is reproducible in the runbot here is an attached video with the steps: https://drive.google.com/file/d/1W1ZJG7aYueFa8Y24LSZlsil0caZB9mE5/view?usp=sharing This happens because of : 1- cash rounding is enabled in the settings of accounting 2 - cash rounding by tax is chosen 3 - opening a vendor bill 4 - putting a decimal price and removing taxes 5- then choosing cash rounding by tax The Error : File "/home/odoo/odoo/odoo/addons/account/models/account_move.py", line 1570, in _compute_tax_totals move.tax_totals = self.env['account.tax']._get_tax_totals_summary( File "/home/odoo/odoo/odoo/addons/account/models/account_tax.py", line 2090, in _get_tax_totals_summary max_subtotal, max_tax_group = max( ValueError: max() arg is an empty sequence opw-4558251 (related to ticket)
Invoices now display product serial numbers whenever serialized products are included, regardless of the viewer's user group. This ensures customers and staff can see the required product identification details on invoice documents.
Original PR description
Problem: The Serial Number of a product is not being displayed on an invoice. The Serial number should be displayed on the invoice if there is a product tracked by Serial Number in the invoice. The groups is preventing the display of this Serial Number section: https://github.com/odoo/odoo/blob/d99e44f22634ac589a940d85fab84ca2b2e85332/addons/stock_account/views/report_invoice.xml#L5 Steps to reproduce: -Make a SO of a product with a serial number -Deliver it -Create an invoice -Preview it and the Serial Number of the product won't be displayed Fix: The groups tag was removed so that everyone can see the Serial Number of the product being bought. opw-4489382
This fix ensures quality checks are triggered correctly when warehouse receipts are created and validated through the barcode app. It prevents missed or duplicate checks, helping teams keep inventory validation aligned with required quality controls.
Original PR description
The Error is reproducible in the runbot here is an attached video with the steps: https://drive.google.com/file/d/1W1ZJG7aYueFa8Y24LSZlsil0caZB9mE5/view?usp=sharing
This happens because of :
1- cash rounding is enabled in the settings of accounting 2 - cash rounding by tax is chosen
3 - opening a vendor bill
4 - putting a decimal price and removing taxes
5- then choosing cash rounding by tax
The Error :
File "/home/odoo/odoo/odoo/addons/account/models/account_move.py", line 1570, in _compute_tax_totals
move.tax_totals = self.env['account.tax']._get_tax_totals_summary(
File "/home/odoo/odoo/odoo/addons/account/models/account_tax.py", line 2090, in _get_tax_totals_summary
max_subtotal, max_tax_group = max(
ValueError: max() arg is an empty sequence
opw-4558251 (related to ticket)The Belgian payroll individual account report now separates account lines by payroll structure. This helps businesses review employee payroll details more accurately when multiple structures apply.
This fix improves the Manufacturing Planning Schedule so quantities stay accurate when users switch between days, weeks, months, or years. It reduces misleading totals caused by period changes, helping planners make better replenishment decisions, though very large planning ranges may take longer to calculate.
Original PR description
Context: the MPS only creates records when numbers have been manually input. If the number input is superior to the `max_to_replenish_qty`, the leftover is reported to the next period via…
Context: the MPS only creates records when numbers have been manually input. If the number input is superior to the `max_to_replenish_qty`, the leftover is reported to the next period via computation, meaning no record is created. This means that every time the MPS is opened or refreshed, the computation happens. Issue: with the inclusion of the period switcher, some issues have been revealed concerning quantity computation and period switching. Solution: to be sure that numbers are accurate, the MPS will compute in 2 steps using 2 date ranges: - the `shown_date_range`: it's the one the user sees, the number of period shown is defined in the settings - the `default_date_range`: it's the one selected in the settings it uses the start and end of the `shown_date_range` to build itself E.g. 1: if your `shown_date_range` is month with 6 periods to show and your `default_date_range` is days, the MPS will calculate everything day per day before doing sums for each month. Meaning it will do ~180 computations, one for each day. E.g. 2: if your `shown_date_range` is 12 weeks and your `default_date_range` is in years, the MPS will calculate everything on 2 years (the current year and the next) in case the `shown_date_range` is straddling 2 years. Once the computation is done, it will insert the yearly `forecast_ids` (date == 01/01/2025) and place it in week 1 of 2025 (30/12/2024 to 05/01/2025), all other weeks should show zero. Pros: - it's precise Cons: - it's potentially very slow in extreme cases: if you want to show 4 years and your default period is in days, this means the MPS will calculate quantities for 1461 days before summing them in 4 years. This should be alleviated with task 4370071 where the default period type is not a general setting anymore but defined separately on each MPS product record. - manual input, when not in the default period type, can be displaced to a previous shown period or absorbed in the sum of the previous default period. This is most often because weeks are one of the 2 period types and how they never fit neatly because the Gregorian Calendar is the drunk way of keeping time with some month having 30 days, some having 31 and then there's February who changes its mind once every 4 years. task 4381366