Daily updates from Odoo
Tuesday, May 5, 2026
19 changes · 17.0
Resolved issues and error corrections
This update clarifies the purpose of the invoice_mail_template_id field in the subscription module. The help text has been revised to specifically state that it applies only to recurring renewal invoices, reducing potential confusion. This change ensures users understand when and how the email template is utilized.
Original PR description
The existing help text of the invoice_mail_template_id field was unclear andcould lead to confusion about when the email template is used. After discussion with the Product Owner, the help text has been updated to better clarify that it applies only to recurring renewal invoice emails. **opw-5993315**
This update fixes a bug that prevented users from accessing timesheet data when certain access rights were configured. The change ensures that access controls are correctly applied to analytic lines, avoiding errors related to manufacturing orders. This improves the reliability of timesheet reporting for all users.
Original PR description
Steps to reproduce the bug:
- give only the following access rights to Marc demo:
- Timesheets, mrp, inventory: User
- create a storable product “P1”
- create an analytic distribution model:
- product: P1
- analytic distribution: Administrative
- create a manufacturing order to produce 10 units of P1
- confirm the MO
- set qty producing to 5 units
- save
Problem:
An access error is triggered:
“
Sorry, Marc Demo (id=6) doesn't have 'write' access to:
- Analytic Line (account.analytic.line) “
Solution:
The account analytic line is not linked to a project or timesheet, so we should not check this access right.
opw-4534971This update corrects a bug where public holidays without working schedules weren't appearing in payroll reports. The fix ensures that all public holidays, regardless of their working schedule, are now correctly included in the SD worx generation process. This improves the accuracy of payroll calculations for Belgian businesses.
Original PR description
### Steps to reproduce: - Create a public holiday without working schedule - Generate a SD worx for the month of the public holiday - Notice the public holiday is not shown in the report ### Cause: When searching for the public holiday we don't take into condsideration the holidays without working schedule. ### Fix: Modify the domain to fetch those holidays as well opw-5500070
This update fixes an issue where CodaBox statements were sometimes incorrectly routed to the wrong bank journal due to currency differences. The fix ensures statements are now automatically assigned to the correct journal based on currency, preventing financial misallocations. This improves the accuracy of financial reporting.
Original PR description
When several journals share the same IBAN but use different currencies, a CODA could land on the wrong journal instead of the currency-specific one. Split the lookup in two passes: first a journal with an explicit currency_id matching the CODA, then fall back to the no-currency journal (qualified by the company currency). Steps to reproduce: - Create 2 bank journals sharing the same IBAN; one without currency and one with USD. - Setup CodaBox connection and retrieve USD statements. - Before this fix: may land on the EUR journal. opw-6048931
This update resolves an issue preventing free FSM services with prepaid invoicing from appearing on invoices. The change adjusts a calculation to ensure these services are correctly reflected when creating invoices, aligning with expected functionality. This ensures accurate billing for service-based contracts.
Original PR description
Changed _compute_qty_to_invoice in industry_fsm_sale, SaleOrderLine to no longer set qty_to_invoice to 0 for free services with prepaid invoicing. Previous changes seem intended for goods. Steps to reproduce: - Create service product with 0 price, prepaid invoice policy, creates FSM task - Create/Confirm sales order with created product - Attempt to create invoice, get 0 quantity to invoice error Current Behavior: Free services linked to FSM tasks do not appear on invoices due to compute 0 qty_to_invoice Expected Behavior: Prepaid Invoice Services linked to FSM tasks appear on invoices. Other invoice policies can be invoiced through the generated sales order lines (timesheets, delivered quantity, etc.) opw-6047992
This update corrects a bug in the Discuss feature that prevented partners with matching email prefixes from being correctly prioritized during sorting. The fix ensures that search results are displayed accurately, improving the user experience when searching for partners.
Original PR description
In Discuss, the function used to sort partners prioritizes those whose email addresses start with the search terms. However, due to an error in the programming of the corresponding condition, this check could never be true. This commit adjusts the condition so that it behaves as expected.
This update fixes an issue where HR leave requests with dual approval ('both') didn't send notifications to the designated 'Notified Time Off Officer'. The fix ensures that email notifications are sent as expected when this approval type is selected, improving the reliability of the leave request process.
Original PR description
…cer') no fallback for responsible_ids
Issue:
When ('both','By Employee's Approver and Time Off Officer') is selected on a new HR Leave Type it does not fall back to the responsible_ids or “Notify HR”.
Steps:
1) Setup a neutralized outgoing mail server
2) install hr_holidays
3) make a new hr.leave.Type (Approval) with ('both','By Employee's Approver and Time Off Officer') and select a 'Notified Time Off Officer'(responsible_ids) 4) select an emplyee with a reelated user and remove the coach, manager, and responsible 'Time Off'. 5) save
6) Sign in as the employee, make a time off request under the new Type 7) No email
Fix:
Add a conditional with the lowest priority to fall back to responsible_ids
opw-6101637This pull request resolves an issue where refund balances were incorrectly counted twice in Modelo 390 tax reports for Spain. The update introduces dedicated tax grids for refunds, mirroring Modelo 303, ensuring accurate VAT calculations. This improves the reliability of financial reporting for Spanish businesses.
Original PR description
First part of this is actually a **[FIX]**. With https://github.com/odoo/odoo/pull/180029, refunds balance are now counted twice in the section 2 totals of modelo 390. Prior to that change, refund…
First part of this is actually a **[FIX]**. With https://github.com/odoo/odoo/pull/180029, refunds balance are now counted twice in the section 2 totals of modelo 390. Prior to that change, refund had no tax grid for modelo 390, and the refund amount were pulled cross-report from modelo 303. When that PR added the negative tax grids for refunds, it made the refund balances count twice toward the totals (once with the negative modelo 390 tag, then one more time pulled cross-report from modelo 303). This PR aims to fix the modelo 390 refund by mimicking the behavior of Modelo 303, with tax grids dedicated to refunds for different categories of VAT. To do so, the following changes were made to the tax grids - Refunds with VAT receivable: Replaced `-mod390[X]` tags on lines having -`mod303[41]` with `-mod390[62]` Replaced `-mod390[X]` tags on lines having -`mod303[40]` with `-mod390[639]` - Refund with VAT accrued: Replaced `-mod390[X]` tags on lines having -`mod303[14]` with `-mod390[29]` Replaced `-mod390[X]` tags on lines having -`mod303[15]` with `-mod390[30]` - Refund with reverse charge: Replaced `-mod390[X]` tags on lines having -`mod303[12]` with `-mod390[27]` Replaced `-mod390[X]` tags on lines having -`mod303[13]` with `-mod390[28]` - Refund with surcharge equivalence: Added `-mod390[43]` on lines with `-mod303[25]` Added `-mod390[44]` on lines with `-mod303[26]` And the balance expressions for the lines `mod_390_casilla_62` `mod_390_casilla_639` `mod_390_casilla_29` `mod_390_casilla_30` `mod_390_casilla_27` `mod_390_casilla_28` `mod_390_casilla_43` `mod_390_casilla_44` were adapted to use these new tags instead of pulling the data cross-report from Modelo 303. Then, after discussing with the product owner, we decided it would be good to do an **[IMP]** to split the remaining tax grids for Modelo 303 and 390. Modelo 390 report contains several cross-report reference to report 303. This can cause conflicts as both report receive changes at a different pace. First, add the Modelo 390 tax grids on taxes, next to their corresponding Modelo 303 tax grid equivalent, and then adapts the Modelo 390 report line expressions to use these new tax grids. The changes made all follow the same logic: If a Modelo 390 report line `mod_390_casilla_XX` expression is a cross-report to a certain Modelo 303 `mod_390_casilla_YY` tax grid balance, then add tag `+mod390[XX]` on taxes that use `+mod303[YY]`, then adapt formula of line `mod_390_casilla_XX` expression to be the sum of that new tag. Additionally, some lines missing from the report are added, for the surcharge equivalence section. `[663] Base imponible 0%` `[664] Cuota devengada 0%` `[691] Base imponible 0.26%` `[692] Cuota devengada 0.26%` `[35] Base imponible 0.5%` `[36] Cuota devengada 0.5%` `[665] Base imponible 0.62%` `[666] Cuota devengada 0.62%` `[693] Base imponible 1%` `[694] Cuota devengada 1% ` Then, two errors are fixed in some taxes - Removed `+mod390[26]` from `account_tax_template_p_iva0_ic_bc` invoice base line, as that tag is for 21% tax line of intracom tax. - Removed `+mod303[16]` from `account_tax_template_s_req0` as it is for surcharge equivalence 1%, not 0%. Lastly, some cross-report reference to Modelo 303 are not adapted, as they use an external value (manual input) in the Modelo 303. In that case, a cross-report reference is better suited. Else, the user would have to manually input the data in both reports. These are: `mod390[63]` from `mod303[43]` `mod390[522]` from `mod303[44]` `mod390[654]` from `mod303[62]` `mod390[655]` from `mod303[63]` `mod390[656]` from `mod303[74]` `mod390[657]` from `mod303[75]` `mod390[659]` from `mod303[67]` `mod390[85]` from `mod303[77]` opw-4520183
This update fixes an issue where Peppol/UBL XML files with embedded PDFs weren't being attached to vendor bills. The fix ensures that when receiving these XML files via email, the corresponding PDF is automatically included as an attachment to the generated vendor bill, improving invoice clarity and streamlining the billing process.
Original PR description
When receiving a Peppol/UBL XML file containing an embedded PDF via an email alias, the PDF is not extracted and attached to the resulting vendor bill. Steps to reproduce: - Set up a BE Company - Configure an incoming mail server - Set up an email alias for the Vendor Bill journal - Receive a Peppol XML with embedded PDF via alias - Check the created Bill Issue: PDF has not been extracted from the xml This occurs because the received xml is set as main attachment for the record and in this case we skip extraction opw-6075250
This update resolves an issue that occurred when users attempted to merge mailing lists within Odoo. The fix corrects a misinterpretation of record IDs during the merging process, preventing a warning message and ensuring the feature functions correctly. This improves the user experience for managing mailing lists.
Original PR description
Currently, error occurs when user tries to merge a mailing list. Steps to replicate: - Install `mass_mailing`. - Open Email Marketing > Mailing Lists > Mailing Lists and switch to list view. - Select…
Currently, error occurs when user tries to merge a mailing list.
Steps to replicate:
- Install `mass_mailing`.
- Open Email Marketing > Mailing Lists > Mailing Lists and switch to list view.
- Select a single record, and from cog menu Click merge.
Warning:
```
odoo.http: Record does not exist or has been deleted.
(Record: mailing.list(6,), User: 2)
```
Cause:
- When the user clicks Merge, the `mailing.list.merge` form opens and `default_get()` is executed to populate defaults.
- At this point, `src_list_ids` is added to res in a structured format like `[(6, 0, ids)]` [1].
- Later, `res.get('src_list_ids')` is reused and assigned to `src_list_ids` [2].
- Taking `src_list_ids[0]` [3] returns `(6, 0, ids)`, and its first element `6` is incorrectly treated as a record ID and assigned to `dest_list_id`.
- This leads to an attempt to access a record with ID 6, which does not exist, causing the error.
Solution:
- Instead of reading `src_list_ids` back from `res` after it has been set, we initialize and reuse local variables (src_list_ids, active_ids) at the beginning of the method.
- This avoids relying on transformed values in `res` and ensures that `dest_list_id` is computed using a consistent and valid list record IDs.
[1]: https://github.com/odoo/odoo/blob/21877c09863222a237fe99334787ac46935dcca4/addons/mass_mailing/wizard/mailing_list_merge.py#L20-L22
[2]: https://github.com/odoo/odoo/blob/21877c09863222a237fe99334787ac46935dcca4/addons/mass_mailing/wizard/mailing_list_merge.py#L24
[3]: https://github.com/odoo/odoo/blob/21877c09863222a237fe99334787ac46935dcca4/addons/mass_mailing/wizard/mailing_list_merge.py#L26
sentry-7447326420
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes a bug that prevented users with limited access rights from correctly processing partial manufacturing orders. The issue stemmed from incorrect access permissions related to analytic lines, specifically during the production of goods. This change ensures accurate accounting and reporting for partial production runs.
Original PR description
Steps to reproduce the bug:
- give only the following access rights to Marc demo:
- Timesheets, mrp, inventory: User
- create a storable product “P1”
- create an analytic distribution model:
- product: P1
- analytic distribution: Administrative
- create a manufacturing order to produce 10 units of P1
- confirm the MO
- set qty producing to 5 units
- save
Problem:
An access error is triggered:
“
Sorry, Marc Demo (id=6) doesn't have 'write' access to:
- Analytic Line (account.analytic.line) “
opw-4534971This update resolves an issue where a purchase order was incorrectly created with an extra unit of product when confirming a sale order through the POS. The fix ensures that only the required quantity is ordered when a sale is confirmed, streamlining the inventory process. This prevents unnecessary stock procurement and improves order accuracy.
Original PR description
Steps to reproduce the bug: - Create a storable product “P1”: - Route: MTO + Buy - Vendor: Azure interior - Create a sale order: - customer: Deco addict - product: 1 unit of P1 - Go to POS: -…
Steps to reproduce the bug:
- Create a storable product “P1”:
- Route: MTO + Buy
- Vendor: Azure interior
- Create a sale order:
- customer: Deco addict
- product: 1 unit of P1
- Go to POS:
- Quotation → select the previous SO
- payment
- Ship later → Today → Confirm
- Cash
- Validate
Problem:
A purchase order is created with 2 units of P1 instead of 1. When validating, a “pos.order” is created, which triggers the creation of a picking:
https://github.com/odoo/odoo/blob/5f2693e14fe69cbd870f3d67fe548c6c83fe8993/addons/point_of_sale/models/pos_order.py#L975
https://github.com/odoo/odoo/blob/5f2693e14fe69cbd870f3d67fe548c6c83fe8993/addons/point_of_sale/models/pos_order.py#L184
Since the “shipping_date” is set, stock_rule will be triggered from pos_order_lines:
https://github.com/odoo/odoo/blob/5f2693e14fe69cbd870f3d67fe548c6c83fe8993/addons/point_of_sale/models/pos_order.py#L1013
Because the product follows the MTO + Buy route, a purchase order is created, generating the first unit of P1. However, the “sale.order” is then confirmed:
https://github.com/odoo/odoo/blob/a46c9b0f21e2f8bd42b4f7dff09ac4f8f806f7cc/addons/pos_sale/models/pos_order.py#L60
As a result, _action_launch_stock_rule is triggered, updating the purchase order from 1 unit to 2.
opw-4556044This update resolves an issue where updating the 'done' quantity on a manufacturing order incorrectly increased backorder quantities. The change ensures that the original manufacturing order remains active and the backorder MO is accurately updated to zero when the component quantity is reduced. This prevents overstocking and inaccurate inventory tracking.
Original PR description
Steps to reproduce the bug:
- Create a storable product P1:
- BoM: - Type: Subcontracting - Subcontractor: Azure Interior - Component: - C1: - Route: Resupply Subcontractor on Order
- Create a purchase order:
- Vendor: Azure Interior
- 10 units of P1
- Confirm the PO
- 2 pickings are created:
- Resupply of 10 units of C1
- Receipt of 10 units of P1
- Confirm and validate the resupply of 10 units of C1
- The quantity of components will be reserved in the manufacturing order
- Go to the P1 picking, and record the component:
- 2 units
- 8 units
* Update the quantity done of P1 to 0
Problem:
The original MO is cancelled, and the backorder MO is incorrectly updated to 18 units instead of 0.
opw-4792379This update fixes an issue where the stock forecast incorrectly indicated products were out of stock, even when sufficient inventory was available. The change ensures accurate forecasting calculations, preventing potential overstocking or understocking situations. This improves inventory management accuracy.
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”
- Set the on-hand quantity to 2 units
- Create a delivery with 2 units of P1
Problem:
The forecast field is displayed in red, indicating that the product is out of stock, even though sufficient stock is available.
opw-5159142This update resolves an issue where manufacturing orders were only processing the first 40 components of a Bill of Materials (BoM). The fix ensures that all components, regardless of quantity, are correctly accounted for in the manufacturing order process. This prevents errors and ensures accurate tracking of materials.
Original PR description
~~Bug introduced in: https://github.com/odoo/odoo/pull/256655/changes/c5f0e5685b0d08fb85f723ba13e2795a06bbcfea~~ EDIT: Introduced by https://github.com/odoo/odoo/commit/14d3893c763f6413581e7f36099cee0adb2caa83 Steps to reproduce the bug: - Create a BoM with more than 40 components - Create a manufacturing order with this BoM Problem: Only the first 40 components are taken into account and their moves are created; the remaining ones are not created. opw-6186544
This update resolves a bug where test emails sent through the Email Marketing app would leave a related attachment visible in contact records' chatter. The fix ensures that test messages are properly removed from the chatter, preventing clutter and ensuring accurate record information. This improves the user experience when testing email campaigns.
Original PR description
**Steps to reproduce:** - Go to Email Marketing app - Create a mailing campaign - Set its recipients to Contact - Upload a file in Settings > Attach a file - Click on the test button to send a test mail to any mail - Go to the first contact record - Related attachment appears in the chatter **Issue:** Before 18.2, messages created for testing were ignored by the Chatter as they were empty (and not unlinked). But if an attachment was provided, it was linked to the test message and not deleted afterwards (which means it shows up in the record chatter). **Fix:** Ensure the related messages are unlinked at the same time as the test mail in `send_mail_test` by setting `is_notification` to False to trigger the `unlink` logic and remove the related attachments at the same time. backport of: https://github.com/odoo/odoo/commit/526b3d73886558315f2435714b2ed82fec313e78 opw-6168632
This update resolves an issue where invoices from Peppol suppliers (using a specific XML format) weren't being correctly processed. The fix allows the system to automatically identify and use the supplier's VAT information, ensuring invoices are created and linked to bank accounts properly. This prevents import failures and data inconsistencies.
Original PR description
Some Peppol emitters carry the supplier VAT in cac:PartyIdentification/cbc:ID instead of the BIS3-standard cac:PartyTaxScheme/cbc:CompanyID. The import then extracted no VAT, the partner auto-creation not available (needs name+vat) and invoice.partner_id stayed empty. As a side effect, when the XML also carried a PayeeFinancialAccount, the bank account creation crashed with a NOT NULL violation on partner_id. Fall back on cac:PartyIdentification/cbc:ID when cbc:CompanyID is empty, so the partner is found (or auto-created) and the bank account is properly linked. Steps to reproduce: - Create a XML with the supplier VAT only in cac:PartyIdentification/cbc:ID and a cac:PayeeFinancialAccount/cbc:ID. - Upload on a purchase journal: import fails, the bill stays empty with an error in chatter. - With the fix: partner auto-created, bill filled, bank linked. opw-6148974
This update resolves an issue where incorrect tax exemption data was being generated in UBL invoices, specifically related to PEPPOL validation. The fix ensures that all tax exemption reasons comply with PEPPOL standards, improving data accuracy and facilitating seamless international transactions. This impacts compliance and accurate reporting.
Original PR description
A tax exemption reason code that does not pass the peppol validation was added in the xml generation in this task-id-5905176 task-id-none
This update corrects a flaw in how Odoo retrieves XML IDs from ir.model.data records. Previously, the system didn't properly update its data after changes, leading to outdated information being returned. This fix ensures that all data is refreshed, guaranteeing accurate results for XML ID lookups.
Original PR description
Steps to Reproduce: - write on ir.model.data to modify noupdate. - _lookup_xmlids still returns the old noupdate value. Example: In [1]: imd = self.env['ir.model.data'] In [2]: xml_id =…
Steps to Reproduce:
- write on ir.model.data to modify noupdate.
- _lookup_xmlids still returns the old noupdate value.
Example:
In [1]: imd = self.env['ir.model.data']
In [2]: xml_id = self.env['ir.model.data'].search([], limit=1)
In [3]: imd._lookup_xmlids([xml_id.complete_name], self.env[xml_id.model])
Out[3]: [(18603, 'auth_signup', 'action_send_password_reset_instructions', 'ir.actions.server', 149, False, 149)]
In [4]: xml_id.write({'noupdate': not xml_id.noupdate})
Out[4]: True
In [5]: imd._lookup_xmlids([xml_id.complete_name], self.env[xml_id.model])
Out[5]: [(18603, 'auth_signup', 'action_send_password_reset_instructions', 'ir.actions.server', 149, False, 149)]
In [6]: imd.flush_model()
In [7]: imd._lookup_xmlids([xml_id.complete_name], self.env[xml_id.model])
Out[7]: [(18603, 'auth_signup', 'action_send_password_reset_instructions', 'ir.actions.server', 149, True, 149)]
Issue:
- _lookup_xmlids is returning values from ir.model.data executing an SQL query w/o flushing.
Fix:
- Add flushing in _lookup_xmlids.