Daily updates from Odoo
Thursday, March 5, 2026
20 changes · 19.0
Resolved issues and error corrections
This update corrects a bug that caused duplicate Dimona activities to be created in the payroll system. Specifically, when updating employee versions or running automated tasks, the system was incorrectly generating multiple activities for the same employee. This fix ensures that only one Dimona activity is created, streamlining payroll processing and preventing data inconsistencies.
Original PR description
This pr restores the previous behaviour of the dimona and part-time activities creation when the cron is ran or when a version or employee is updated. The original bug was: create an instance on…
This pr restores the previous behaviour of the dimona and part-time activities creation when the cron is ran or when a version or employee is updated. The original bug was: create an instance on saas-18.4 with l10n_be_hr_payroll settings > company > my company > update infos > country: Belgium employee > new > payroll > contract > start_date: any date (this should create a first dimona activity) settings > technical > automation > scheduled actions > "HR Employee: Update Current Version" > run manually `_trigger_l10n_be_next_activities` in `hr.version` of `l10n_be_hr_payroll` is duplicating Dimona activities on records that already have one. We check if a dimona activity already exists for a given `hr.employee` before creating the new activity. Same is done for dimona declaration of part times. The activity now redirects to the employee form (instead of the version form) and appears in it. [tasks-5134380](https://www.odoo.com/odoo/project/1251/tasks/5134380) Forward-Port-Of: odoo/enterprise#96423
This update resolves an issue where the Sendcloud shipping API required product weights to be at least 0.00099. This commit ensures that product weights are now at least 0.001, preventing errors and ensuring accurate shipping calculations through the Sendcloud integration. This improves the reliability of shipments processed through Sendcloud.
Original PR description
The Sendcloud API do not allow parcel details to have a weight value less than 0.00099 . This commit makes sure the products weights are at least 0.001. ref: <img width="1850" height="689" alt="image" src="https://github.com/user-attachments/assets/10242315-3c4d-4670-b77d-8cb429e00891" /> Forward-Port-Of: odoo/enterprise#107676
This update corrects inaccuracies in the XML files used for processing Swedish payments (SEPA). Specifically, it ensures the correct BIC number is used, removes a misleading placeholder value, and allows users to select the appropriate payment version for 'iso_se' even without a SEPA payment method configured. This improves the accuracy and reliability of Swedish payment processing.
Original PR description
We currently have customizations for the iso20022 xml file for payments in Sweden. But those customizations aren't correct. This commit fix multiples issues: 1) In DbtrAgt, we sometimes have bankgiro information. But this node should always contain the BIC number for Swedish payments. 2) The _get_cleaned_bic_code method was replacing the real bic code with a fake value like 'SE:Bankgiro', but this seems to be wrong. None of the SE banks ask for this BIC, so we remove it. 3) The sepa_pain_version field is supposed to tell Odoo which pain version to use. But the problem is this field is computed, and only editable once the user set the SEPA payment method, but for iso_se, we want to let the user choose as well, even if he didn't add SEPA as payment method. This commit change the invisible on the field, so it can be edited as soon as iso_se is in the journal payment methods. task-5427570 Forward-Port-Of: odoo/enterprise#105536
This update fixes an issue where tax reports were generating negative values for carried over tax lines (-81, -82, etc.). This ensures accurate tax reporting and avoids potential discrepancies in financial data. The change was triggered by a bug report and related internal tracking.
Original PR description
When generating the xml for tax report, negative values should not be present in the xml for carried over lines (81, 82, 83, 86, 87, and 88) Steps: - Create a RBILL for today - 1 month, add an invoice line with tax using one of the following tags: -81, -82, -83, -86, -87 or -88 in its base refund repartition line - Open the tax report on the month of the RBILL - Generate the xml, either by the dedicated button, or by creating and posting the closing entry -> there is line(s) for negative amounts opw-5955323 opw-5428395 Forward-Port-Of: odoo/enterprise#109389 Forward-Port-Of: odoo/enterprise#108916
This update resolves an issue where refreshing the tax return report page caused a system error. The fix ensures the report loads smoothly after refreshing, improving the user experience and preventing data disruptions. This enhancement focuses on stability and reliability of a key accounting function.
Original PR description
Previously, refreshing the tax-return reports page could lead to a traceback due to `account.report` being empty when `get_options` was called. This happened especially when switching reports or refreshing the page after selecting a report. Steps to reproduce: 1. Go to Accounting > Tax Returns 2. Click on any tax return 3. Open the report using action_open_report 4. Refresh the page ref: https://drive.google.com/file/d/1z3D7lurg4gyFh7bmCj2PQZ1A-Bg2FvKj/view This commit: - Adds fallback logic in `get_options` to recover the report from previous options or context. - Checks if the report exists before rerouting or processing options. As a result, refreshing the page no longer causes a traceback and the report reloads smoothly.
This update resolves a bug in the AI chat composer that caused crashes when the HTML composer was enabled. The fix ensures focus handling correctly works for both text and HTML composer types, preventing errors and improving stability.
Original PR description
*=ai_app In AI chat, focusing the composer used to call ev.target.select(). That works for the text composer (textarea), but not for the HTML composer (contenteditable), where select() doesn’t exist and causes a TypeError. This update makes focus handling respect the active composer mode: - text mode keeps the existing select behavior - html mode uses the editor focus path instead task-5981018
This update resolves a rare crash in the Gantt view that occurred when users filtered tasks through search options. The fix prevents the renderer from losing track of pills when filters are applied, ensuring the Gantt view remains stable and reliable for users.
Original PR description
This commit fixes a traceback in the Gantt view caused by a race condition during search operations. If a user clicks a search dropdown item located directly above a task pill, and that search filters out the underlying pill, a `pointerenter` event can fire on the pill just as the dropdown closes. Because the search amy already be applied, the renderer could lose track of the pill, causing the handler to crash when trying to access it. This commit adds a safety check to the event handler to exit early if the hovered pill is no longer found in the renderer.
This update ensures that WhatsApp messages sent through the Enterprise version of Odoo accurately include the correct user's ID. Previously, the system was sending messages with an incorrect partner ID, which could cause issues with message delivery and user identification. This fix resolves a technical error that has been corrected.
Original PR description
Enterprise counter-part. https://github.com/odoo/odoo/pull/251641 Forward-Port-Of: odoo/enterprise#109364
This update resolves a problem where the Stripe payment integration wasn't working correctly for certain locations (like Mexico). The change to default to EUR caused an error when the currency wasn't active, preventing the Stripe account from loading. This fix ensures Stripe functionality is reliably available for supported regions.
Original PR description
**STEP TO REPRODUCE** On a freshdb with only base module. 1. install hr_expense_stripe. 2. install l10n_mx (or any location that's not EU, US or UK). 3. select one of the mx demo company. 4. try opening the invoicing/accounting app. 5. There will be a traceback when loading the stripe account on the dashboard. **CAUSE** https://github.com/odoo/enterprise/pull/108293 changed the default currency from USD to EUR. But EUR could be unactive when searching for it, leading to to stripe_currency_id being empty. opw-59752385
This update resolves a crash occurring when posting expense entries with the Avalara Avatax integration. The change adjusts how Avatax handles expense move types, specifically addressing a 'KeyError' related to 'in_receipt'. This ensures smoother expense processing for US-based employees using Avatax.
Original PR description
Currently, the expenses flow with Avatax integration crashes when posting the expense entry. Steps to reproduce: - Have an employee with an address in the US. - Enable 'Detect Automatically' in the Avalara fiscal position. - Create an expense for the employee, paid by Employee. - Submit > Post Journal entry > Post Expense. Action will be blocked by a traceback reporting error `KeyError: 'in_receipt'` Analysis: After [1] expense journal entries are now 'in_receipt'. The dictionary in account_avatax does not take into account this move type. This provides a fallback to 'Any' for any other move types [1] https://github.com/odoo/odoo/commit/f835ac0c8adb49d04bed746fd624b8976cc32991 opw-5872768
This update corrects a technical issue that was preventing internal users from accessing AI tools within the Odoo Enterprise platform. The fix involved adjusting access permissions to allow internal users to retrieve the necessary tool information, ensuring seamless functionality for AI-powered features. This resolves a reported error during voice transcript commands.
Original PR description
Steps to reproduce: 1. Open any editor and use /voice transcript command. 2. Start recording, say some words, stop recording. 3. Observe the access error on `tool_ids`. The `tool_ids` field on `ai.topic` is restricted to `base.group_system`, preventing internal users from accessing it. The fix is to use sudo to retrieve the available tools. ticket task-5965009
This update resolves an issue where tax report tags were incorrectly sorted, preventing proper auto-completion functionality. The fix ensures tags are correctly ordered, improving the user experience and accuracy of tax reporting. Improved testing has also been implemented to prevent similar issues in the future.
Original PR description
Commit https://github.com/odoo/odoo/commit/db0d499952192ede0def2a070e103ba67952387c inverted some tags which is wrong Tags must be sorted for the auto complete to work properly Improving tests to catch more errors opw-5415426
This update improves the Gantt editor by allowing all integer fields within a model to be used as color options. Previously, only fields directly visible in the editor's view were selectable. This change provides greater flexibility for visualizing project timelines and tasks.
Original PR description
Before this commit, only fields already present in the view were selectable for the color field in the gantt editor. After this commit, all int fields of the model are available task-5981029 Forward-Port-Of: odoo/enterprise#109189
This update corrects a display error in the Activity Logs report. Previously, the report was incorrectly appearing within the Sign Template list view, leading to an error. The fix ensures the report appears in the correct Sign Request view, improving usability and preventing technical issues.
Original PR description
Version: - saas-18.2 Issue: - The "Activity Logs" report was showing in the Sign Template list view. When clicking it, a traceback occurred because the report tried to read a `sign.request` record from a `sign.template` context. Cause: - The report model was set to `sign.request`, but the`binding_model_id` was set to `model_sign_template`. - This mismatch caused the report to appear in the wrong place. Solution: - Updated the `binding_model_id` to `model_sign_request` so the report now appears in the Sign Request view, which matches the report model and prevents the error. task-5984137 Forward-Port-Of: odoo/enterprise#109171
This update fixes an issue where flexible calendar employees were incorrectly displaying unavailable days in planning and related modules. The change ensures that only public holidays and leaves are reflected as unavailable, providing a more accurate representation of employee availability. This improves the planning process for teams using flexible work schedules.
Original PR description
### Issue: When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible…
### Issue:
When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible calendar should not have any grayed out days other than public holidays.
### Steps to reproduce:
- Create a new work schedule:
- Flexible Hours
- 24 hours per week
- 8 average hours per day
- Create an employee with this work schedule
- Open Planning app
- Only the three first days of the week are not grayed out
### Cause:
With 24 hours per week, the worked time can be done in three days. Odoo considers that the first three days of the given time frame are worked, but the others aren't. This result is returned by `_work_intervals_batch()`. In `_unavailable_intervals_batch()` we then build the unavailabilities by taking the inverse of the work intervals. The only exception was for fully flexible resources (i.e. without a calendar).
### Solution:
The case we need to consider is for flexible resources: they are available anytime, all week long except on public holidays and leaves.
To do this we fix the method `_unavailable_intervals_batch()` which is then called by each module. If the resource is flexible, then we only return the interval of the public holidays overlapping with the time frame.
Works in `appointment`, `hr_holiday_gantt`and `project_enterprise`.
In `planning`, we need to skip the case where nothing is returned in `leaves_mapping` otherwise it will consider the `company_leaves` during weeks with no public holiday or leaves.
In `hr_attendances_gantt`, `_unavailable_intervals_batch()` is not called. So we change the way the unavailabilities were computed to call `_unavailable_intervals_batch()` instead.
Forward-Port-Of: odoo/enterprise#109422
Forward-Port-Of: odoo/enterprise#105521This update addresses a change in how Helpdesk articles are searched. Previously, setting a non-root article as the main article allowed searching across its entire family of articles. Now, searching only returns the selected article itself. Additionally, a minor issue with dropdown behavior has been fixed.
Original PR description
*: website_helpdesk_knowledge **Steps to reproduce:** - Install Helpdesk/Knowledge/Website apps - Go to Knowledge - Set up a Knowledge workspace root article with some child articles to it - Go to…
*: website_helpdesk_knowledge
**Steps to reproduce:**
- Install Helpdesk/Knowledge/Website apps
- Go to Knowledge
- Set up a Knowledge workspace root article with some child articles to it
- Go to Helpdesk > Configuration > Helpdesk Teams
- Open a Helpdesk team, and go to its Help Center config
- Check Knowledge and set a non-root article as main Article
- Go to Website > Help
First issue (non-root main article):
- Type a word which is present in both the article and one of its child articles
- Only the given article match the word
- If you use the root article it will match in any descendant
Second issue (in every case):
- Type a word in the search bar
- Wait for the dropdown to appear
- Click elsewhere, dropdown is properly hidden
- Try to change the search > Traceback
**Issue:**
The domain used to find the articles to match the search uses the current id as the `root_article_id`:
`['|', ('id', '=', team_article.id), ('root_article_id', '=', team_article.id)],` which was previously working in every case as it was not possible to set a non-root article in the team setting.
This was later changed to allow any article as the default website page. As a result, when a non-root article is selected, the search domain only applies to that specific article and no longer includes its descendants.
The other issue is related to the added boostrap attribute `data-bs-toggle="dropdown"` which is not properly reset when the dropdown is removed, and triggers the creation of an empty dropdown.
**Fix:**
Doesn't seem easy to fix to allow the search on all the descendants of the given article as we can't use the article `root_article_id` and filter out the unwanted results in a clean way (and it doesn't seem doable with a direct domain). Instead clarify the situation in the help of the article.
Also manually reset the attribute for `_onFocusOut`.
related: https://github.com/odoo/enterprise/commit/ed971d4d02624f8b864ab6c37c6e7db8ba3dfe11
opw-5258607
Forward-Port-Of: odoo/enterprise#107438This update corrects a problem with how leave periods are calculated, specifically addressing potential inconsistencies caused by different time zones. By updating the system to use 'request_date_from' and 'request_date_to' instead of 'date_from' and 'date_to', the system now accurately reflects leave periods regardless of user time zone settings.
Original PR description
This commit fixes the leaves work interruption constraint by replacing `date_from` and `date_to` with `request_date_from` and `request_date_to`, thereby resolving any inconsistencies that may arise from time zone differences. task-5966780 Forward-Port-Of: odoo/enterprise#109233 Forward-Port-Of: odoo/enterprise#108541
A recent update caused a disruption in our SEPA direct debit payment processing. Customers were unable to complete payments using this method due to a technical error. This fix resolves the issue, restoring reliable SEPA direct debit functionality.
Original PR description
Issue: --- The SEPA direct debit is broken. Steps to reproduce: --- 1- Enable SEPA direct debit in payment providers. 2- Add something to cart and try paying using SEPA direct debit. You get the error: `payment.provider object has no attribute company.` Cause: --- This is introduced after #250326. opw-5993720 Forward-Port-Of: odoo/enterprise#109672
This update resolves an issue where duplicate labels were appearing for widget properties within the Odoo Studio. The fix involves adding temporary code to prevent the duplication of label content, addressing a known bug in the underlying OWL framework. This ensures a cleaner and more consistent user experience when creating and editing widget properties.
Original PR description
steps: - Install Project and Studio - Open studio, add a decimal field - Click on it - There are two "Minimum Digits" instead of "Digits" & "Minimum Digits" Add dummy `t-set` nodes before `t-esc` directives in property sub-templates to prevent label content from being rendered twice. This is a known OWL bug (https://github.com/odoo/owl/issues/1610) where `t-esc` inside a named slot gets duplicated. Since the issue lies in the OWL2 framework itself, a `<t t-set="__dummy"/>` is used as a workaround to break the duplication pattern in owl2. opw-5974611
This update resolves an issue where by-products tracked by serial numbers were incorrectly showing extra lines in the shop floor manufacturing order view. The change ensures that by-products only display lines that have been manually added, aligning with the intended workflow. This improves the clarity and accuracy of shop floor data.
Original PR description
When the "pre fill lot/serial numbers in shopfloor" setting is enabled on the manufacturing operation type, by-products tracked by serial number were incorrectly showing extra empty lines in…
When the "pre fill lot/serial numbers in shopfloor" setting is enabled on the manufacturing operation type, by-products tracked by serial number were incorrectly showing extra empty lines in shopfloor MO cards (both in overview and work center views). Steps to reproduce: 1. Create a bill of materials for a final product 2. Add a consumable component 3. Create an operation without steps 4. Add a by-product tracked by serial number 5. Specify that the by-product is produced in the operation above 6. In Inventory > Configuration > Operations Types, open the Manufacturing operation type, go to the Traceability section and enable "Pre fill lot/serial numbers in shop floor moves" 7. Create a manufacturing order for the BOM and confirm it 8. Open the Shop Floor view from the MO 9. Observe the extra line for the by-product in both overview and work center views Root cause: The visibleMoveLines getter in stock_move.js was showing ALL move lines (including unpicked ones) when picking_type_prefill_shop_floor_lots was enabled, without distinguishing between raw materials/components and by-products. By-products should never show pre-filled lines since users must register them manually by clicking the + button. Solution: Modified the visibleMoveLines getter to always filter by-products to show only picked move lines, regardless of the prefill_shop_floor_lots setting. This ensures by-products only display lines that have been explicitly registered by the user, while regular components continue to show pre-filled lines when the setting is enabled. Task-5431295 Forward-Port-Of: odoo/enterprise#109574 Forward-Port-Of: odoo/enterprise#103260