Monday, April 27, 2026
11 changes · 18.0
Resolved issues and error corrections
This update streamlines the process of linking vendor bills to purchase orders. Previously, the search and linking were combined within a single method, leading to inefficiencies. Now, the search for purchase orders is separated, improving performance and reliability when importing vendor bills.
Original PR description
[FIX] account, *: split find and set purchase order modules: account, account_edi_ubl_cii, purchase When importing a vendor bill, we try to link it with a potential purchase order. The current logic tries to find and link a purhase order in the same method, this commit split the 'finding PO' logic and 'line matching/linking' in two separate methods. The finding PO is now @api.model. no-task
This update addresses a technical issue related to how Odoo processes incoming emails. The fix ensures more reliable parsing and extraction of data from email payloads, preventing potential disruptions in email-based workflows. This improves the overall stability and performance of Odoo's email functionality.
Original PR description
(not to do in 18.0 obviously) linked to https://github.com/odoo/odoo/pull/258425
This update addresses a minor issue with how Odoo processes incoming emails. The fix ensures more consistent and reliable parsing of email payloads, preventing potential disruptions in email-related workflows. This improves the overall stability and performance of Odoo's email functionality.
Original PR description
(not to do in 18.0 obviously)
This update fixes an issue where date-based sorting in financial reports was inconsistent, particularly when using the 'From the very start' period. The change ensures that string-type external values are now correctly ordered by date, improving the accuracy and reliability of report data.
Original PR description
Ensure string-type external values are correctly sorted by date when using the "most_recent" formula. This resolves an issue where values appeared unordered, especially for expressions using the "From the very start" period. task-5951888 Forward-Port-Of: odoo/enterprise#113837
This update fixes a bug that prevented users from correctly scraping component information from manufacturing orders created by others. The issue stemmed from incorrect access rights, specifically related to analytic account lines. This ensures accurate reporting and data retrieval for timesheet-related tasks.
Original PR description
When scraping the component of a MO created by another user you could get an access error saying you don't have write access on account analytic lines. Steps to reproduce: ------------------- * Install timesheet_grid and project_mrp_account * Create product A, storable * Create product B with a cost of 20 and also storable * Update the available quantity of product B * Create a BoM for product A, it should only require one product B * Update Marc Demo access right and make sure he doesn't have access to any accounting stuff and he has atleast timesheet approver * Create a first MO for 1 product A and produce it * Create a second MO for 1 prodcuct A but just confirm it * Login as Marc Demo and try to scrap the component of the second MO > Observation: You get an access error here https://github.com/odoo/odoo/blob/d98afdc08b46bf458eaa287ea882cc7663286a59/addons/stock_account/models/analytic_account.py#L95 opw-5954989
This update fixes an issue where closed Helpdesk tickets were sending out emails with the database ticket ID instead of the customer-facing ticket reference. The change ensures all email communications consistently use the correct ticket reference, improving clarity and accuracy for customers. This was a simple fix to a configuration error.
Original PR description
Steps to reproduce: ------------------------ 1. Install the Helpdesk. 2. Go to Settings → Technical → Sequences and set the next number to 100. 3. Create a ticket and send a message using the…
Steps to reproduce: ------------------------ 1. Install the Helpdesk. 2. Go to Settings → Technical → Sequences and set the next number to 100. 3. Create a ticket and send a message using the "Helpdesk: Ticket Received" mail template; Observe that the correct reference (100) is used. (Open the full composer to use "Load template") 4. Now send a message using the "Helpdesk: Ticket Closed" mail template and Observe that it displays the database ID (e.g., 1) instead of the reference. Cause: ------ `new_ticket_request_email_template` uses the ticket reference(`object.ticket_ref`) correctly. https://github.com/odoo/enterprise/blob/d39e291ba89ad018ba6f5f9591d280a834822f27/helpdesk/data/mail_template_data.xml#L18-L19 However, the `solved_ticket_request_email_template` uses the database ID (`object.id`) instead of the actual ticket reference (`object.ticket_ref`), leading to inconsistent references in customer communications. related commit: 3ed5273 Solution: --------- Update `solved_ticket_request_email_template` to use `object.ticket_ref` instead of `object.id` opw-6087466 Forward-Port-Of: odoo/enterprise#113932
This update ensures the o_spreadsheet component within Odoo is running the most recent version. This resolves a bug related to data validation, specifically preserving spaces in spreadsheet values, and improves the overall stability of the spreadsheet functionality. This change impacts users who utilize the spreadsheet module.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/1cc3da19f3 [REL] 18.0.65 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/4359debd7e [FIX] data_validation: preserve spaces in dv values [Task: 5418098](https://www.odoo.com/odoo/2328/tasks/5418098) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update fixes a bug that prevented users from correctly accessing and scraping component information from purchase orders created by other users. The issue stemmed from incorrect access rights, specifically related to analytic account lines. This ensures accurate data retrieval and reporting for project management workflows.
Original PR description
When scraping the component of a MO created by another user you could get an access error saying you don't have write access on account analytic lines. Steps to reproduce: ------------------- * Install timesheet_grid and project_mrp_account * Create product A, storable * Create product B with a cost of 20 and also storable * Update the available quantity of product B * Create a BoM for product A, it should only require one product B * Update Marc Demo access right and make sure he doesn't have access to any accounting stuff and he has atleast timesheet approver * Create a first MO for 1 product A and produce it * Create a second MO for 1 prodcuct A but just confirm it * Login as Marc Demo and try to scrap the component of the second MO > Observation: You get an access error here https://github.com/odoo/odoo/blob/d98afdc08b46bf458eaa287ea882cc7663286a59/addons/stock_account/models/analytic_account.py#L95 opw-5954989
This update resolves a technical issue preventing the posting of vendor bills in LATAM purchase journals. The system's hashing logic requires sequential document numbers, which conflicts with vendor-assigned numbers. By hiding the 'Secure Posted Entries with Hash' option for these journals, we ensure data integrity and avoid misleading security indicators.
Original PR description
Steps to reproduce 1. Install l10n_ar (or any LATAM localization). 2. Go to Accounting > Configuration > Journals and open a Purchase journal that has "Use Documents?" enabled. 3. Enable "Secure…
Steps to reproduce 1. Install l10n_ar (or any LATAM localization). 2. Go to Accounting > Configuration > Journals and open a Purchase journal that has "Use Documents?" enabled. 3. Enable "Secure Posted Entries with Hash". 4. Create and post a vendor bill with a high document number (e.g. 00001-00009999). 5. Create another vendor bill with a lower document number (e.g. 00001-00000100) and try to post it. Issue Posting the second vendor bill fails with: "This move could not be locked either because some move with the same sequence prefix has a higher number. You may need to resequence it." The hashing logic in account_journal.py enforces a strict continuous sequential chain per journal: https://github.com/odoo/odoo/blob/89993885823f7309b921145eacc7bbe2c3c1e427/addons/account/models/account_journal.py#L671-L678 In LATAM countries, vendor bill document numbers are assigned by the vendor, not by Odoo. A bill with a lower number can legitimately be entered after one with a higher number, which breaks the sequential assumption the hash chain relies on. Allowing it would produce a hash that no longer represents a proper chain, giving users a false sense of security. Sales journals are unaffected because Odoo controls their sequence. Solution Hide the "Secure Posted Entries with Hash" field on purchase journals that have "Use Documents?" enabled, preventing users from enabling an option that cannot work correctly for vendor-assigned document numbers. Sales journals keep the option available since Odoo controls their sequence. opw-6076673
This update fixes an issue where incorrect test tags were being used in Odoo 18, potentially causing the entire Hoost suite to fail. It backports a fix from a previous release to ensure the correct tag is applied, guaranteeing consistent test results across supported versions. This improves stability and reliability of the testing process.
Original PR description
When an error is parsed during the nightly, the default test tag is not correct in 18 and 19, what could lead to disabling the complete hoot suite if not taking enough care when disabling a test. This backports part of #234937 to ensure with have the correct tag in all version supporting hoot tests.
This update prevents the state of tasks from being reset when their project is changed, specifically when the task is in a 'done' or 'canceled' state. This ensures that tasks are not unnecessarily re-evaluated after completion or cancellation, improving efficiency and reducing potential processing delays. It corrects a previous behavior where project changes would reset task states, even when the task was already marked as finished.
Original PR description
Before this commit, when the project of a task is changed, even if the state of that task is done or cancelled, the state is reset (except if the task is blocked by another one). This behavior is not expected for a task done/cancelled, we should not reconsider that task since it has been done/cancelled and so there is no reason to re-consider it once the project changed. This commit makes sure the state of the task is not reset when the project changed only if the state is a closed state or Waiting state. task-5361864