Daily updates from Odoo
Friday, April 10, 2026
218 changes
8 changes
Resolved issues and error corrections
This update fixes an issue where GCC invoices were incorrectly displaying 'Invoice' instead of the required 'Tax Invoice' or 'Simplified Tax Invoice' title. The change reorders the title evaluation process to ensure the correct title is used in the invoice report, aligning with GCC tax regulations. This ensures accurate and compliant invoice generation.
Original PR description
Steps to reproduce: ------------------- 1. Insatll l10n_ae 2. Go to any invoice from the demo data and print it -> The title says "Invoice" instead of "Tax Invoice" (or "Simplified Tax Invoice"). Reason: ------- After e19efd2f5401, we evaluate "invoice_gcc_title" in "l10n_gcc_invoice.xml" after evaluating the "layout_document_title" variable of the main "report_invoice.xml". However, "invoice_gcc_title" decides what fields are rendered by "layout_document_title" !! Fix: ---- We hence move the evaluation of "invoice_gcc_title" (the whole "l10n_gcc_settings") block before the "layout_document_title". opw-6096038
This PR optimizes the inventory valuation report by batching calculations, reducing unnecessary data retrieval, and correcting a misconfigured company context. This results in a significantly faster report generation, improving user experience and reducing system load.
Original PR description
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 Forward-Port-Of: odoo/odoo#247625
This update resolves a bug preventing administrators from accessing the Studio feature within the project form view when ‘Project Stage’ is disabled. The change ensures that administrators can always utilize Studio, regardless of this setting, improving overall project management functionality. This fix was made as part of a larger task to improve system stability.
Original PR description
## Steps to Reproduce: 1. Ensure the “Project Stage” option is disabled. 2. Open the form view of any project. 3. Click the Studio button. 4. An access error appears, indicating that the current user does not have permission to access stage_id, preventing the project form view from being edited. ## Expected Behavior After the PR: The admin user should have access to stage_id even when the “Project Stage” option is disabled. This ensures that Studio can be opened without triggering an access rights error. ## Task : task-[5892227](https://www.odoo.com/odoo/project/4105/tasks/5892227) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250343
This update resolves a problem where the proforma invoice wasn't correctly generated when using the 'Send PRO FORMA Invoice' button. The fix ensures the proforma data is properly included in the report context, improving the functionality of the invoice generation process. This prevents errors and ensures accurate proforma invoice creation.
Original PR description
Issue: --- f23b7e6b70babc7d3c027963e0ac6f3e562f44c3 partially fixed the proforma issue. If you use `Send PRO FORMA Invoice` button, the `proforma` will be present in the context:…
Issue: --- f23b7e6b70babc7d3c027963e0ac6f3e562f44c3 partially fixed the proforma issue. If you use `Send PRO FORMA Invoice` button, the `proforma` will be present in the context: https://github.com/odoo/odoo/blob/06205b59f56a87d6bb41b202b95c9716775c67b7/addons/sale/views/sale_order_views.xml#L328-L335 leading to correct beahviour as `is_proforma` will be set as context: https://github.com/odoo/odoo/blob/4ef6f93da818789fd63bd8d37c5526d9a85bef53/addons/sale/report/ir_actions_report_templates.xml#L12 However, if it is printed using the action button `print/PRO Forma Invoice`, the proforma will not be present in the record.context itself (it is present in the docs.context): https://github.com/odoo/odoo/blob/4ef6f93da818789fd63bd8d37c5526d9a85bef53/addons/sale/report/ir_actions_report_templates.xml#L379-L386 The commit bba2fc505f5d0b4770eacc6877155b1aeda6d772 has broke `report_saleorder_pro_forma`, by moving `<t t-set="is_pro_forma">` to attributes of the template call, while `is_pro_forma` is not meant for `html_container` template, and we actually need it to be defined inside the contents. related: #257817 opw-6043669
This update corrects a bug where delivery and invoice addresses weren't appearing on sales order documents. The issue stemmed from a configuration error in how a template parameter was being used. The fix ensures that all customer addresses are correctly displayed when generating sales order reports, improving sales reporting accuracy.
Original PR description
Issue: --- Delivery and Invoice addresses are not shown SO documents. Steps to reproduce: 1- Enable customer addresses. 2- Create a contact with a delivery and an invoicing address. 3- Create an SO and print it. Cause: --- This issue is introduced after bba2fc505f5d0b4770eacc6877155b1aeda6d772. Based on d30bc84e277e00a933883bd6562b14e7aad4d118, `information_block` which is a parameter meant for called template, is instead defined as a content inside the call. Fix: --- `information_block` can be defined before calling the `external_layout` template, and be used as a parameter. opw-6113087
This update resolves an issue preventing bookkeepers from registering payments through payment methods. A recent change in how payment providers are accessed triggered an access error. This fix ensures bookkeepers can accurately record payments, improving the accounting process.
Original PR description
Issue: --- Bookkeeper user cannot register payment using a payment method due to access issues. Steps to reproduce: 1- Setup a payment provider. e.g. Demo 2- Set Demo user accounting access as bookkeeper. 3- Login using Demo user. 4- Create an invoice and register a payment. 5- Choose Demo payment method. An access error is raised. Cause: --- Before cb7fba0782d8af365e29832ac7dd166590d80b16, `provider.capture_manually` was checked inside the search filter. As the search was `sudo`, there was no access issue. After that commit, the `capture_manually` is checked with no sudo, causing this access issue if the user doesn't have read access on the payment provider. opw-6001170 Forward-Port-Of: odoo/odoo#258636
This update resolves a technical issue causing problems with the formatting of test reports. Previously, the system automatically corrected errors in XML, but this has been discontinued. This fix ensures test reports are generated correctly.
Original PR description
This commit fixes a malformed HTML/XML tag in TestReports. Note: before libxml2 v2.14.0, this issue was automagically cleaned up, but not anymore. Forward-Port-Of: odoo/odoo#258569
This update fixes a visual issue where the 'seen' indicator wasn't displayed correctly when the last message in a channel was a notification. Now, the indicator accurately reflects when a user has read the last message, regardless of whether it was a standard message or a notification, improving channel organization.
Original PR description
Before this PR: In channels with seen indicators, the indicator is hidden if the user's last message is a notification. Since indicators are not displayed on notifications and the logic does not fall back to the previous message, the user is left with no visible 'seen' status. After this PR: The seen indicator now skips notification-type messages and is correctly displayed on the last message sent by the user. task-5921911 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258587 Forward-Port-Of: odoo/odoo#248390
6 changes
Resolved issues and error corrections
This update resolves a bug that prevented demo users from receiving inbox messages when linked to HR employee records. The previous code caused access errors when retrieving message counts, leading to a blank inbox. This change ensures all inbox messages are correctly fetched for users, improving notification functionality.
Original PR description
Since PR #252611, the value of the `message_needaction_counter` field has been added to the store data when fetching inbox messages. The `hr` module adds a specific group to this field, that could cause fetching inbox messages to crash if the needaction message is related to an `hr.employee` record and the user is not involved in that group. This change adds sudo when accessing to this field to get the store data for inbox messages. Steps to reproduce: - Set the notification preference to `inbox` for the demo user. - Log in as admin and mention the demo user in an employee record. - Go to inbox as demo. The messages will not be fetched, with an access error to `message_needaction_counter` field.
This update resolves an issue where a task could fail to save due to a requirement being incorrectly added to widget fields. The fix ensures that widget dependencies are copied correctly, preventing unintended changes to field requirements and maintaining data integrity. This resolves a bug related to how widget dependencies are handled in complex form views.
Original PR description
Example of steps: - Install todo module - Create a todo task (it will be created without project_id) - Go to project -> my task - You can see your previously created todo task (with project set as) -…
Example of steps:
- Install todo module
- Create a todo task (it will be created without project_id)
- Go to project -> my task
- You can see your previously created todo task (with project set as)
- This todo task is marked as Private (since no project)
- Refresh page
- There is now an error because project is now required and you cannot save the current task
This problem is caused by `addFieldDependencies` from `relational_model/utils` Let's simplify the case with this view for example:
```xml
<form>
<field name="foo" widget="my_widget"/>
<field name="name" />
<field name="child_ids">
<list editable="top">
<field name="foo" widget="my_widget"/>
<field name="name" required="1"/>
</list>
</field>
</form>
```
my_widget is defined with these fieldDependencies:
```js
[
{
name: "name",
type: "char",
}
]
```
We have twice the same group of fields (name + foo with my_widget), one in the form view and the other one in the subview list (child_ids).
Currently, we firstly process subviews in `addFieldDependencies`. As "name" field is used in dependencies of `my_widget` and name is already use in the same view (subview list) with required="1" we will change `my_widget` dependencies to be required too by mutating `widget.fieldDependencies`.
And after, we will do the same with the main form view, but as fieldDependencies object from fieldInfo is the same for every instances of the widget everywhere (from form arch parser), we should not alter it because we might accidentally add attributes to certain fields (for example, in our case, making the “name” field in the main view required when it shouldn't be).
This commit fix this case by using a spread operator to shallow copy fieldDependencies items.
opw-6008266
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue where right-clicking on links within email messages sometimes displayed unwanted actions. The fix expands the scope to cover all links, including those with nested HTML elements, ensuring a cleaner and more reliable email experience. This improves usability for all users.
Original PR description
Before this commit, when right-click on a link in a message, this sometimes show the message actions. A commit was dedicated on fixing this issue [1], however this was limited to exact click on `<a>`. Many links shared by email are `<a>` with some nested nodes, for example `<a><font>LINK</font></a>`. Such links were not covered by [1] and thus made the message actions show on right-click. This commit fixes the issue by not showing the message actions on right-click on links, including nested children. [1]: https://github.com/odoo/odoo/pull/244252 opw-6110949
This pull request updates the core o_spreadsheet library used in Odoo. It includes several bug fixes and improvements related to spreadsheet rendering, formula handling, and testing. These changes ensure the spreadsheet functionality remains stable and reliable.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/4561a9a809 [REL] 19.0.29 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/4561a9a809 [REL] 19.0.29 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/cd7707f944 [FIX] format: keep negative accounting suffix in large number [Task: 6068834](https://www.odoo.com/odoo/2328/tasks/6068834) https://github.com/odoo/o-spreadsheet/commit/f7b1c449c8 [IMP] tests: add image snapshots for renderer store tests [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130) https://github.com/odoo/o-spreadsheet/commit/46c70d8670 [FIX] renderer: rendering tests are wrong [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130) https://github.com/odoo/o-spreadsheet/commit/bd47b32e9e [IMP] tests: update jest to v30 [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130) https://github.com/odoo/o-spreadsheet/commit/bfb8e0595f [FIX] cf: add sanity checks on conditional format type/operator [Task: 6106092](https://www.odoo.com/odoo/2328/tasks/6106092) https://github.com/odoo/o-spreadsheet/commit/aee92bcbdd [FIX] live-server: specify host to avoid issues with some browsers [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/f5e1d32287 [FIX] spreadsheet: chart side panel content should use full height [Task: 6080680](https://www.odoo.com/odoo/2328/tasks/6080680) https://github.com/odoo/o-spreadsheet/commit/89c8b30ee2 [FIX] xlsx: export formula that returns an error [Task: 6008904](https://www.odoo.com/odoo/2328/tasks/6008904) 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> Forward-Port-Of: odoo/odoo#258579
This update resolves an issue where mentions in emails weren't being recognized when user names contained special characters like '&', '<', or '>'. The fix translates these characters back to their original form, ensuring that mentions are correctly identified and processed, allowing users to be notified properly.
Original PR description
**Description of the issue/feature this PR addresses:** The `Store.getMentionsFromText` method fails to identify mentions for users with special characters (&, <, >) in their names. Because the…
**Description of the issue/feature this PR addresses:** The `Store.getMentionsFromText` method fails to identify mentions for users with special characters (&, <, >) in their names. Because the function processes raw HTML, these characters are encoded as entities, causing them to be [filtered out](https://github.com/odoo/odoo/blob/a2b3a10255dba290ea462b9193ae11c54d8dd5e0/addons/mail/static/src/core/common/store_service.js#L599-L601) In order to resolve this, I translate the entities back into their normal representation, allowing our includes to find them. **Steps to reproduce bug:** 1) Create a user with a name containing &, <, > 2) Set it so they receive emails for notifications 3) Mention them in a long note 4) Observe that no email is sent **Current behavior before PR:** https://drive.google.com/file/d/1itBlz6havFmFi2G3mbOm3qh2_WH6uM76/view?usp=drive_link **Desired behavior after PR is merged:** https://drive.google.com/file/d/1PC2_hjBAhhC6ZSOEzs9SPYjSHrZbaplp/view?usp=drive_link opw-5895188 Forward-Port-Of: odoo/odoo#249350
This update resolves a technical problem with incorrectly formatted XML within the test reports module. Previously, the system automatically corrected these errors, but this fix ensures consistent test results moving forward. This change improves the reliability of our testing process.
Original PR description
This commit fixes a malformed HTML/XML tag in TestReports. Note: before libxml2 v2.14.0, this issue was automagically cleaned up, but not anymore. Forward-Port-Of: odoo/odoo#258569
2 changes
Resolved issues and error corrections
This update addresses a recurring issue where a test related to formatting inline code in the HTML editor would sometimes fail unpredictably. The fix ensures the color picker is displayed before attempting to select a color, preventing these intermittent test failures. This improves the stability of the HTML editor functionality.
Original PR description
Purpose of this PR: - Ensure color picker is rendered before selecting a color to avoid non-deterministic failures. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where changing a contact's name automatically updated the associated account holder's name, regardless of whether they were originally the same. Now, the account holder name only updates if the contact's name changes, maintaining data accuracy and preventing unintended modifications to bank account information.
Original PR description
**steps to reproduce:** 1. Create a contact 2. On the accounting tab, add one bank account 3. Change the name of the contact 4. The record's name updates automatically the field "Account Holder Name"…
**steps to reproduce:** 1. Create a contact 2. On the accounting tab, add one bank account 3. Change the name of the contact 4. The record's name updates automatically the field "Account Holder Name" **problem:** When changing a profile's name in the contacts app, the account holder name changes to be the same as the profile's name. **expected behaviour:** "Make the account holder name update if partner.name is changed ONLY if they were the same before the change. Otherwise keep the account holder name as is." - Referenced from the feature ticket: 5222712 That means if contact's name is the same as the account holder name, then any change to the contact's name, should as well update 'account holder name' accordingly, but if you changed the account holder name itself, then you change contact's name (if they're not the same) then the account holder name shouldn't be updated to match the contact's name. **cause:** The account holder name depends on `partner_id.name` https://github.com/odoo/odoo/blob/2394a9a7f0ece2d5a2185fa4e715d943fc044733/odoo/addons/base/models/res_bank.py#L104-L107 So whenever you change the contact's name, the account holder name changes accordingly. **Fix:** Upon creation, the account holder name is set to the partner name if no name is provided. Additionally, when the partner name changes, the account holder name is updated only if it previously matched the partnername; otherwise, it is left unchanged. **NOTE:** This is a backport of this PR: https://github.com/odoo/odoo/pull/233965 opw-5913464 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248886
2 changes
Resolved issues and error corrections
This update corrects an issue where early payment discounts and 0% tax lines on invoices were causing validation errors when sending invoices via PEPPOL. The fix ensures the correct tax exemption reason is used, resolving XML validation problems and enabling proper invoice export.
Original PR description
**PROBLEM** Early payment discount create a new line which is tax exempted. The tax exemption reason is 'Exempted from tax'. 0% tax also have a tax exemption reason that is different, which means the tax exemption subtotal are not merged. **STEP TO REPRODUCE** 1. Create a early payment discount payment term. 2. Create an invoice, with a line with a 0% tax and the early payment term. 3. Send the invoice using peppol, use a validator to validate the xml and notice you get the following errors: [BR-E-01] [BR-E-08]. A similar issue was fix in 18.0 by https://github.com/odoo/odoo/pull/250413, and the fix works for this bug. opw-6075910
This update optimizes the Google Calendar integration by preventing unnecessary cache invalidations when events are updated. The changes streamline the system's data writing process, improving performance and reducing potential delays. This results in a smoother user experience.
Original PR description
When a google event is updated, the cache is invalidated. This is not necessary as the event google_id didn't change. Also, slightly simplify the ormcache since there is a single call with active_test=False