Daily updates from Odoo
Saturday, April 4, 2026
9 changes · master
Resolved issues and error corrections
This update fixes an issue where amounts with thousand separators (like 1,334.00) were incorrectly interpreted, leading to potential errors in reconciliation reports. The change introduces a new function to intelligently parse these amounts, ensuring accurate calculations and reporting. This improves the reliability of financial data.
Original PR description
When extracting amounts using a regex with a single capturing group, values containing thousand separators such as 1.334,00 or 1,334.00 were not correctly converted to floats. This could lead to…
When extracting amounts using a regex with a single capturing group, values containing thousand separators such as 1.334,00 or 1,334.00 were not correctly converted to floats. This could lead to incorrect amounts being interpreted in reconciliation models.
Added a new function `split_amount_str`in utils which will give
integer and decimal part for different number formats.
This is a heuristic approach, meaning it aims to provide the best
possible result for valid inputs. Invalid or ambiguous formats are
not guaranteed to be parsed correctly and may result in ('0', '0').
For the two capturing groups case, the first group is treated as the
integer part and the second as the decimal part, allowing users to
Explicitly split amounts like 9065 into 90.65 by using two groups
in their regex.
Examples:
EU format: 1.334,15 → 1334.15
US format: 1,334.15 → 1334.15
Implicit decimals: uid 01870912 0000009065 → 90.65 (using two groups)
Additional tests were added to ensure amounts with thousand separators
are correctly parsed.
Task [link](https://www.odoo.com/odoo/project/967/tasks/6026748)
task-6026748
Forward-Port-Of: odoo/enterprise#110410This fix resolves a problem where copying and pasting text in the website builder was incorrectly creating paragraph elements inside buttons and other inline-only containers. The fix allows the editor to properly handle inline elements at the root level when the container shouldn't contain block-level elements like paragraphs or divs.
Original PR description
Since [website builder refactor], the editor wraps inline elements at the root of an editable boundary. This is causing issues in website builder when the root element is not supposed to contain `p`…
Since [website builder refactor], the editor wraps inline elements at the root of an editable boundary. This is causing issues in website builder when the root element is not supposed to contain `p` or `div` elements (added to wrap the inline elements). This behavior can be configured globally with `allowInlineAtRoot`. And since 6bc5946796a364634cb5eb217e61a5b882a1b6b2, it can be configured per-element with a "predicate" resource. This commit adds a predicate to allow inline at root of editable when the root is (according to its tag) not supposed to contain `p` or `div` elements. Steps to reproduce: - Open website builder on a product page - Select text in "Add to cart" button - Copy - Paste - Bug: a `p` element is created (on master) - Open website builder - Select "Company" below footer - Copy - Paste - Bug: a `p` element is created [website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-5868460 Forward-Port-Of: odoo/odoo#257512 Forward-Port-Of: odoo/odoo#247231
This fix resolves a problem where POS orders created in Jordan before installing the EDI module could not be submitted to JoFotara due to missing unique identifiers. The system now automatically generates these identifiers when needed, ensuring all orders can be successfully submitted regardless of when they were created.
Original PR description
Currently, POS orders in Jordan do not have a UUID if they were created before installing the module. This causes submission failures to JoFotara. Steps to reproduce: - Create a POS order in Jordan without the module l10n_jo_edi_pos installed - Install l10n_jo_edi_pos - Try to submit the order to JoFotara, it fails due to missing UUID with the error "Invoice UUID is required" This fix force a computation of the order UUID when we add the header node, to ensure that this will not cause submission failures to JoFotara. opw-6041688 Forward-Port-Of: odoo/odoo#255996
This fix resolves an issue where projects created from CRM leads using templates were assigned to the wrong company. Previously, the system would incorrectly use the template's company instead of the lead's company, causing data mismatches. Now the company is properly preserved when creating projects from leads.
Original PR description
When creating a project from a CRM lead using a template, the `default_company_id` set by `_get_project_create_from_lead_context` is ignored because `company_id` is not in the template default…
When creating a project from a CRM lead using a template, the `default_company_id` set by `_get_project_create_from_lead_context` is ignored because `company_id` is not in the template default context whitelist. This causes the new project to inherit the template's company instead of the lead's company, resulting in a company mismatch with the partner and a UserError. https://github.com/odoo/odoo/blob/2b89db4af2265e5cec8feb11853364e293de203e/addons/crm_sale_project/models/crm_lead.py#L37-L45 https://github.com/odoo/odoo/blob/2b89db4af2265e5cec8feb11853364e293de203e/addons/project/models/project_project.py#L1413-L1419 Steps To Reproduce: 1. Go to CRM, create or open a lead. 2. Clear the contact field and save. 3. Click the gear icon → Create Project. 4. Select any project template (not empty) and submit. Ticket [link](https://www.odoo.com/odoo/project.task/5933253) opw-5933253 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250087
This fix ensures that when users send multiple Request for Quotations (RFQs) using the bulk "Send by mail" action, the RFQ status is automatically updated to "Sent" - just like it does when sending from the individual form view. Previously, RFQs would remain marked as draft even after being emailed, causing confusion and requiring users to manually resend them to update the status.
Original PR description
Issue Before This Commit: ======================= When RFQs are sent using the `Send by mail` action from the list view, their state remains draft instead of being updated to sent, so users see them…
Issue Before This Commit: ======================= When RFQs are sent using the `Send by mail` action from the list view, their state remains draft instead of being updated to sent, so users see them as not sent even though they were already emailed and have to send them again using the `Send RFQ` button from the form view to mark rfq as sent, which is inconsistent with the form view behavior and confusing for users. Steps to Reproduce: ======================= - Install the `Purchase` app. - Go to Purchase and select multiple RFQs in the list view. - Click `Send by mail` from the actions menu. - Select the RFQ email template and send the email. - Observe that the RFQs remain in state RFQ instead of being set to RFQ Sent, unlike when using the `Send RFQ` button in the form view. Cause of the issue: ======================= The `Send by mail` action in the list view does not apply the same state update logic as the `Send RFQ` button from the form view, where the RFQ state is updated when the email is posted on the purchase order. As a result, when emails are sent from the list view (mass mailing flow), the RFQ state is not updated After This Commit: ======================= When emails are sent using Send by mail, purchase orders in state draft are updated to sent in `_message_mail_after_hook` after the email is sent. This keeps the list view flow consistent with the form view behavior and prevents users from having to resend RFQs just to update the state. TaskID-5443248 Forward-Port-Of: odoo/odoo#243050
This fix resolves an error that occurred when users submitted the Create a Task form with an email address that doesn't correspond to an existing contact. The system was trying to add an outdated email field that no longer exists in the task system, causing the submission to fail. The fix prevents this invalid field from being added, allowing the form to submit successfully.
Original PR description
Currently, an error occurs when a user submits the Create a Task form. **Steps to Reproduce:** - Install the `website_project` module. - Go to `website` > `Click on Edit` > `Drag and drop` form. -…
Currently, an error occurs when a user submits the Create a Task form. **Steps to Reproduce:** - Install the `website_project` module. - Go to `website` > `Click on Edit` > `Drag and drop` form. - Click on the form and, set the action to `Create a Task`, then save. - Fill in the required data in the form. - In the `Email Address` field, enter an email that does not correspond to any existing partner. - `Submit` the form, and the `error appears in the logs`. `ValueError: Invalid field 'email_cc' in 'project.task'` With this [recent commit], the email_cc field has been removed from project.task, along with the mail.thread.cc inheritance, because threads are now able to find CC recipients. so, when user submits the form with an email address that does not correspond to any existing partner, the system adds email_cc to the record [1], and when it attempts to create the record [2], it raises an error. This commit ensures that email_cc is no longer added to the record. [recent commit]: https://github.com/odoo/odoo/commit/3c26c0553754a75d9440097ad473be3cc8bcb320#diff-93ba226020add6481cfeab916e69980a59163e2925a5c2c9a3bc0aaceb484cdf [1]- https://github.com/odoo/odoo/blob/21aa7e7eca0bf78978e0667cee43129985833166/addons/website_project/controllers/main.py#L61 [2]: https://github.com/odoo/odoo/blob/21aa7e7eca0bf78978e0667cee43129985833166/addons/project/models/project_task.py#L1167 sentry-7374084515 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256964
This update improves the reliability of automated tests across multiple Odoo modules by restoring email tracking features that were previously disabled. The changes help catch real-world issues with access controls and data tracking that were being masked by overly simplified test conditions. Additionally, a bug in the sales module tests was fixed where a record object was incorrectly used instead of its ID.
This fix resolves an issue where multi-line product descriptions were appearing in reverse order when displayed in the shopping cart. The problem was caused by a previous change that attempted to prioritize rental dates and variant information, but inadvertently reversed all description text. The fix removes the reversal logic to ensure product descriptions display correctly, though variant details and rental dates may no longer always appear first.
Original PR description
Issue: --- Due to this issue, the description following lines are inversed. Steps to reproduce: --- 1- In product page in backend, add a multiline "Short Description" to a product. 2- Navigate to website and add the product to the cart. 3- Open the cart. Outcome: The description after lines are shown inversed. Cause: --- This is introduced by https://github.com/odoo/odoo/pull/223433. It was done to ensure some information such as rental date and variant description are shown at the beginning. However, it didn't consider that the product description itself might have multilines. Fix: --- There is no clean way to reliably extract structured information from the computed name. To avoid reversing the product description lines, we no longer reverse the description. As a limitation, variant descriptions and rental dates may no longer always appear first. opw-5976614 Forward-Port-Of: odoo/odoo#252259
This fix corrects how Odoo calculates taxes on invoices that use price-included tax mode but have zero price-excluded taxes. Previously, the system would incorrectly switch to excluded tax mode in this scenario. Now it properly handles mixed tax configurations without unnecessary mode switching, ensuring accurate tax calculations on invoices.
Original PR description
…xes_data Suppose an invoice with price-included taxes but with a zero price excluded one. We don't want to fallback on the excluded mode just for that. opw-6060486 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257495