Monday, March 30, 2026
24 changes · 19.0
Enhancements to existing features
The payment options now show the updated iDEAL / Wero branding, including refreshed logos and a separate Wero payment brand. This helps customers recognize the current payment identity and keeps checkout branding aligned with the provider’s latest presentation.
Original PR description
Before the commit: The iDEAL payment method was using the existed legacy iDEAL logo. After the commit: - Updated the display name to "iDEAL / Wero". - Replaced the legacy iDEAL logo with the new Wero logo. - Introduced a separate "Wero" payment brand. task-5922938 Forward-Port-Of: odoo/odoo#254901 Forward-Port-Of: odoo/odoo#248506
Resolved issues and error corrections
Creating a scrap order no longer crashes if the default scrap location has been deleted. This improves reliability for inventory users by handling the missing setup gracefully instead of showing an error.
Original PR description
When user tries to create a scrap order without scrap location, A traceback is raised. Steps to reproduce the error: - Install ``stock`` module - Go to Inventory > Configuration > Settings > Enable Storage Locations > Save - Go to Configuration > Locations > Delete Virtual Locations/Scrap > Delete - Go to Operations > Scrap > New Traceback: ```py KeyError: 1 ``` https://github.com/odoo/odoo/blob/7d89c092ac25ffe149fb38fb52863fdaa3b6ed5f/addons/stock/models/stock_scrap.py#L93 When the Scrap location is deleted, ``locations_per_company`` becomes an empty dictionary. Accessing a key from this empty dictionary lead to the above traceback. sentry-7307394327 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252192
Features or functions removed from Odoo
The accounting tax field no longer shows a tooltip that could give users unclear or misleading guidance. This keeps the interface simpler and avoids confusion until accurate guidance is needed.
Original PR description
Remove the misleading tooltip entirely. No need to have more details on that field right now. Task [link](https://www.odoo.com/odoo/project.task/5946889) task-5946889
Documentation and clarification updates
The corporate contributor record for Optesis has been updated to replace one listed contributor with Ibrahima NIASSE EXT. This keeps Odoo's legal contributor documentation accurate and current, with no impact on product features or users.
Original PR description
Replaced Mame Abdoul Aziz SY with Ibrahima NIASSE EXT in the contributors list. 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
Overnight attendances that span two days now record undertime on the correct dates instead of placing the full amount on the starting day. This gives managers and payroll teams more accurate daily attendance and overtime balances.
Original PR description
Create an attendance from Tuesday 20h till Wednesday 4am. You will have a single overtime record with -8 set on Tuesday. We want two overtime records, both of -4 hours one for Tuesday and the other for Wednesday. task-6079675
The HTML editor tests now explicitly load the expected Roboto font instead of relying on whatever font is available in the environment. This reduces flaky test failures and helps keep quality checks consistent across systems.
Original PR description
Purpose of this PR: - Explicitly load Roboto using FontFace in indent.test.js to avoid fallback fonts (e.g. Ubuntu) across environments. This ensures consistent rendering and prevents flaky failures caused by font-dependent computed values. task-5916115 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256070
When a credit note is created with a replacement invoice, the new invoice now keeps the original source document information. This ensures invoice PDFs show the expected source reference, improving traceability and reducing confusion in customer and accounting records.
Original PR description
### Issue before this commit: When creating a credit note using “Reverse and create invoice”, the generated invoice loses the Source field. While the original invoice correctly displays the source,…
### Issue before this commit: When creating a credit note using “Reverse and create invoice”, the generated invoice loses the Source field. While the original invoice correctly displays the source, the new invoice created after reversal does not, leading to missing information in the report. ### Steps to reproduce the issue: 1. Create a sales order for product A 2. Deliver product A 3. Create invoice 4. Create credit note by clicking on "Reverse and create invoice" 5. The new invoice correctly remains linked to the Sales order 6. However, the source document disapear on the PDF ### Cause of the issue: In the reversal flow, the new invoice is created using copy_data() without explicitly preserving the invoice_origin field. As a result, the newly created invoice does not inherit the source information from the original invoice, even though it is still logically linked. ### Reason to introduce the fix: To ensure consistency between invoices and preserve important traceability information, the invoice_origin field must be propagated to the new invoice created during the reversal process. This guarantees that the Source is correctly displayed in the PDF. opw-6034574 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254290
Creating a new analytic item from an analytic account's gross margin shortcut now automatically links it to the correct analytic account. This prevents manual re-entry and reduces the risk of unlinked margin records.
Original PR description
When accessing analytic items from the gross margin smart button on an analytic account, creating a new record does not pre-fill the analytic account field. This happens because the context does not set `default_account_id` for the active analytic account, leading to newly created lines not being linked at creation time. This commit ensures the analytic account is correctly passed through the context, so it is automatically set when creating a new analytic line from this flow. Steps to reproduce: - Open an analytic account - Click on the gross margin smart button - Create a new analytic item Before: analytic account not set by default After: analytic account is pre-filled via context task-3909624 Forward-Port-Of: odoo/odoo#256091 Forward-Port-Of: odoo/odoo#255726
The Project app now explicitly loads a required rating component before its own setup runs. This prevents installation or update failures caused by missing rating information and helps keep Project deployments reliable.
Original PR description
The `project` module's `rating_rating_views.xml` references the `publisher_comment` field (defined by `portal_rating`) via xpath. Since `project` already depends on `portal` and `rating`…
The `project` module's `rating_rating_views.xml` references the `publisher_comment` field (defined by `portal_rating`) via xpath. Since `project` already depends on `portal` and `rating` (`portal_rating`'s own dependencies), declaring `portal_rating` explicitly just makes the implicit dependency explicit and ensures correct load order.
```yml
2026-03-27 21:26:26,093 2235 INFO odoo odoo.modules.loading: Loading module project (47/79)
2026-03-27 21:26:26,197 2235 INFO odoo odoo.registry: module project: creating or updating database tables
2026-03-27 21:26:27,601 2235 INFO odoo odoo.modules.loading: loading project/security/project_security.xml
2026-03-27 21:26:27,820 2235 INFO odoo odoo.modules.loading: loading project/security/ir.model.access.csv
2026-03-27 21:26:27,859 2235 INFO odoo odoo.modules.loading: loading project/security/ir.model.access.xml
2026-03-27 21:26:27,864 2235 INFO odoo odoo.modules.loading: loading project/data/digest_data.xml
2026-03-27 21:26:27,877 2235 INFO odoo odoo.modules.loading: loading project/report/project_task_burndown_chart_report_views.xml
2026-03-27 21:26:27,898 2235 INFO odoo odoo.modules.loading: loading project/views/account_analytic_account_views.xml
2026-03-27 21:26:27,929 2235 INFO odoo odoo.modules.loading: loading project/views/digest_digest_views.xml
2026-03-27 21:26:27,947 2235 INFO odoo odoo.modules.loading: loading project/views/rating_rating_views.xml
2026-03-27 21:26:27,983 2235 WARNING odoo odoo.modules.loading: Transient module states were reset
2026-03-27 21:26:27,986 2235 ERROR odoo odoo.registry: Failed to load registry
2026-03-27 21:26:27,986 2235 CRITICAL odoo odoo.service.server: Failed to initialize database `odoo`.
Traceback (most recent call last):
File "/opt/odoo/odoo/service/server.py", line 1544, in preload_registries
registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'], reinit_modules=config['reinit'])
File "/opt/odoo/odoo/tools/func.py", line 88, in locked
return func(inst, *args, **kwargs)
File "/opt/odoo/odoo/orm/registry.py", line 199, in new
load_modules(
File "/opt/odoo/odoo/modules/loading.py", line 464, in load_modules
load_module_graph(
File "/opt/odoo/odoo/modules/loading.py", line 217, in load_module_graph
load_data(env, idref, 'init', kind='data', package=package)
File "/opt/odoo/odoo/modules/loading.py", line 59, in load_data
convert_file(env, package.name, filename, idref, mode, noupdate=kind == 'demo')
File "/opt/odoo/odoo/tools/convert.py", line 693, in convert_file
convert_xml_import(env, module, fp, idref, mode, noupdate)
File "/opt/odoo/odoo/tools/convert.py", line 792, in convert_xml_import
obj.parse(doc.getroot())
File "/opt/odoo/odoo/tools/convert.py", line 663, in parse
self._tag_root(de)
File "/opt/odoo/odoo/tools/convert.py", line 616, in _tag_root
raise ParseError(msg) from None # Restart with "--log-handler odoo.tools.convert:DEBUG" for complete traceback
odoo.tools.convert.ParseError: while parsing /opt/odoo/addons/project/views/rating_rating_views.xml:22
Error while parsing or validating view:
Element '<xpath expr="//label[@for='publisher_comment']">' cannot be located in parent view
View error context:
{'file': '/opt/odoo/addons/project/views/rating_rating_views.xml',
'line': 1,
'name': 'rating.rating.form.project',
'view': ir.ui.view(922,),
'view.model': 'rating.rating',
'view.parent': ir.ui.view(594,),
'xmlid': 'rating_rating_view_form_project'}
2026-03-27 21:26:27,987 2235 INFO odoo odoo.service.server: Initiating shutdown
```
This PR fixes https://github.com/odoo/odoo/pull/256203. I didn't remove `portal` and `rating` dependencies to avoid possible stable policy issue.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prSearching the Chart of Accounts by code now includes archived accounts when the inactive accounts filter is selected. This ensures finance users can find older or disabled accounts as expected, avoiding missing search results.
Original PR description
The _search_code method used to search code_store without setting active_test=False, so filtering on inactive accounts and then searching by code returned no results. The inner query only matched active records while the outer domain required active=False. The same fix has already been applied to sibling methods in this file: - `_search_new_account_code` (#253753) - `_constrains_code` (#248559) Steps to reproduce: 1. Open Chart of Accounts 2. Activate the "Inactive Accounts" filter 3. Search for an account code that exists among archived accounts 4. Expected: matching archived accounts shown 5. Actual: no results --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Spanish tax labels now appear in Spanish instead of English for users of the Spain localization. This reduces confusion for Spanish businesses when reviewing or configuring taxes in Odoo.
Original PR description
It was a previous dev in which the fw-port failed. Here is the old [PR](https://github.com/odoo/odoo/pull/238857) The tax names were displayed in English, and it's confusing for the Spanish users. Now, the taxes are displayed in spanish task-6041023 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255674 Forward-Port-Of: odoo/odoo#255074
When an employee is archived while still checked in, the system now records a checkout at the current time. This prevents open attendance records from lingering and helps keep attendance data accurate when employee records are deactivated.
Original PR description
Before: - When an employee was archived, their attendance was not updated. After: - When an employee is archived, if they are currently checked in, they will be automatically checked out at the current timestamp. task-5916700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255845 Forward-Port-Of: odoo/odoo#255524
A timing issue in the product catalog could cause purchase catalog tests to fail when adding a product before the selected section was fully updated. The fix ensures the correct section is used reliably, improving stability for accounting and purchasing workflows.
Original PR description
Cause: The `selectedSectionId` was not yet updated in the environment when the product was added, resulting in a `None` value being passed to `_update_order_line_info`. Fix: Use `this.env.selectedSectionId` when available, and fall back to `this.env.searchModel.selectedSection.sectionId` only if it is undefined or null. runbot-241960
This update stabilizes an automated test for web form behavior by preventing the same quick-create action from being triggered twice. It reduces false test failures in the development pipeline without changing normal user behavior.
Original PR description
This commit fixes a non deterministic one2many field test by ensuring that we don't quick create the record twice.
Before this commit, it might sometimes happen that the validation of the input ("Enter", by default) produced a second name_create. Note that in practice this is highly unlikely to happen as if the user presses Enter, the "Quick create" item in the dropdown only appears during a single frame, thus making impossible for the user to click on it.
runbot error~242204
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-prA recent update caused long partner names in approval reports to overflow, making the reports visually unreadable. This fix adds a column limit to the partner field in the report, ensuring all data is displayed correctly and preventing formatting issues. This improves the report's usability and data clarity.
Original PR description
step to reproduce: - install "approval" with demo data - have a partner with name length > 63 - open one of the approvals and change its type to "general approval" - add this partner in contact field - print approval request report Observation: - the partner overflows out of report Fix: - we limit the partner field with `col-9`. For a safe measure i have added `col-9` for `request_owner_id` and `approver_ids` **Before** <img width="1057" height="326" alt="image" src="https://github.com/user-attachments/assets/a8eea789-5cc7-4658-88b5-78751759d043" /> **After** <img width="994" height="330" alt="image" src="https://github.com/user-attachments/assets/bfbc061b-a6e0-4593-a3cc-c85cb81db6e2" /> opw-6005752 Forward-Port-Of: odoo/enterprise#111130
This update corrects a bug where planning slots were incorrectly created for rental orders, even when 'Plan Services' was disabled. The fix ensures that slots are only generated when 'Plan Services' is enabled, streamlining the rental planning process and preventing potential confusion. This change improves the accuracy of rental order planning.
Original PR description
Steps to reproduce: ------------------- 1. Install `sale_renting_planning`. 2. Create a rental service product with: - "Can be Sold" enabled - "Plan Services" disabled - UoM set to "Units" 3. Create and confirm a rental order with this product. 4. Go to Planning and check for slots related to this order. (no slots at this stage) 5. Update the quantity of the rental order. 6. Check Planning again for slots related to this order. Issue: ------ Planning slots are created after updating the quantity of the sale order, even when "Plan Services" is not enabled. Cause: ------ Slot records are created without checking whether "Plan Services" is enabled, which leads to unwanted planning entries. related commit: 74eef70 Solution: --------- Add a condition to ensure planning slots are created only when "Plan Services" is enabled. opw-6051012 Forward-Port-Of: odoo/enterprise#112278
This update resolves an issue where users without write access to the Point of Sale (PoS) in the AT (Austria) version of Fiskaly would receive an access error when attempting to authenticate after a token expiration. The fix ensures that access errors are handled correctly, preventing disruptions to sales transactions for our AT customers.
Original PR description
When trying to auth directly from the PoS when the token expires, if you are logged in with a user that doesn't have write access to the PoS. You would get an access error. Steps to reproduce: ------------------- * Setup Fiskaly in an AT company * Open PoS and try to make a sale * To fake the token expiration I modified the code so that the request always return 401 status code > Observation: You get an access error opw-5925203
This update resolves an inconsistency in the tax report when creating vendor bills with mixed vehicle and non-vehicle expense lines. The fix allows for accurate reporting by relaxing a strict matching rule for vehicle IDs, ensuring shared tax lines are correctly processed regardless of whether a vehicle is assigned. This improves the reliability of financial reporting.
Original PR description
**Steps to reproduce:** * Install the **account** and **fleet** modules. * Create a vendor bill with two expense lines using the same tax. * Assign a vehicle_id to one line but leave the other…
**Steps to reproduce:** * Install the **account** and **fleet** modules. * Create a vendor bill with two expense lines using the same tax. * Assign a vehicle_id to one line but leave the other without a vehicle. * Confirm the vendor bill. * Go to **Accounting > Reporting > Tax Report** and Go to `Account > Tax` report. **Observed behavior:** * The tax report shows: 'This report contains inconsistencies. The affected lines are marked with a warning.' **Cause:** * The `_get_extra_query_base_tax_line_mapping()` override forced vehicle_id matching using `COALESCE(base_line.vehicle_id, 0) = COALESCE(account_move_line.vehicle_id, 0)`. * When lines share a tax but have different vehicle_id values (one set, one NULL), Odoo creates a single tax line with `vehicle_id = NULL`. * The strict COALESCE constraint prevented this tax line from matching either base line (NULL ≠ vehicle_id and NULL ≠ NULL when coalesced to 0), causing the inconsistency. **Fix:** * Changed the constraint to only enforce vehicle_id matching when both the base line and tax line have a vehicle_id set. * If either side is NULL, the match is allowed, letting shared tax lines work correctly across mixed vehicle/non-vehicle expense lines. opw-5956645 Forward-Port-Of: odoo/enterprise#112313 Forward-Port-Of: odoo/enterprise#110616
This update fixes an issue related to how dates and times are displayed, specifically the inclusion of seconds. The change restores the previous behavior of showing seconds when desired, and clarifies the datetime format system. This ensures consistent and accurate time formatting across Odoo.
Original PR description
In this [commit] the short format has been removed from misc methods because there was no more _short format fields in res.lang. But the short format was used to remove seconds from the res.lang format. Now, this behaviour has been restored with the new datetime format system and the unused format 'long' and 'full' has been removed from the doc string to avoid misunderstanding. The formatDateTime from the JS use the format from the res.lang too. So the same behaviour has been implemented there to be able to show seconds through the option 'showSeconds'. It's also fix the fact that this option didn't have any effect when the datetime was shown in numeric mode. [commit]: odoo/odoo@062b140 opw-6030342
This update resolves a test failure related to calculating AVS deductions in the payroll module. The issue stemmed from an incorrect date calculation within the test environment, specifically when simulating a year of 2027. The fix uses a frozen test time of 2026-02-28 to accurately replicate the test conditions.
Original PR description
[FIX] l10n_ch_hr_payroll_elm_transmission: fix avs test for faketime build
Bug reproduction:
1 - v.17->run test_generic_avs_deductions test with faketime 2027-01-01 12:00 UTC->test fails
Bug cause:
1 - In the test, compute_sheet()->_get_payslip_lines->_compute_rule->_get_avs_rates is called
2 - There is a line like that if line.date_from <= target and (not line.date_to or target <= line.date_to)
3 - I looked to avs_line_ids = fields.One2many(default=_get_default_avs_line_ids)
4 - In _get_default_avs_line_ids -> 'date_from': fields.Date.today().replace(month=1, day=1) date_from is calculated like that -> when the year is 2027, the date_from is 2027-01-01 and it is bigger than the target in the test.
Bug solution:
1 - I used @freeze_time("2026-02-28") in my test to prevent this behavior.
Runbot Error Link: https://runbot.odoo.com/odoo/runbot.build.error/240992
task - 6018940
Forward-Port-Of: odoo/enterprise#109975This update fixes an issue where the canteen cost was incorrectly calculated for Belgian employees, even when they had no attendance records. The fix ensures that the canteen cost is only applied if the employee has earned money through attendance or work during the payslip period, preventing incorrect charges.
Original PR description
[FIX] l10n_be_payroll: fix canteen cost computation
Bug reproduction: belgium company -> create a new employee -> new contract (payroll wage > 0) -> canteen_cost = 50 -> create payslip -> allocate time off for full month (such that there will be no attendance) -> recompute payslip -> still canteen cost is calculated
Bug cause:
1 - If l10n_be_canteen_cost is > 0 it was computing the canteen cost line for sure
2 - If result_rules['BASIC']['total'] is > 0 then the canteen cost was 50.
Bug solution:
1 - I add worked_days['WORK100'].amount != 0 to the computation condition.
2 - If there is any earned money from attendance or working in that payslip duration, the canteen cost should be deducted completely
3 - If the employee is absent during the payslip, the employee should not pay the canteen cost.
task - 6045406
Forward-Port-Of: odoo/enterprise#111995
Forward-Port-Of: odoo/enterprise#110991This update resolves an issue where tax lines within the bank reconciliation widget couldn't be manually unmatched when the related tax account was set to 'reconcilable'. Now, users can correctly unmatch these lines, ensuring accurate reconciliation of tax payments. This improves the usability of the bank reconciliation process.
Original PR description
In the bank reconciliation widget, tax lines are protected from unreconciliation to maintain tax integrity. However, when the tax account is set as reconcileable the user may need to manually unmatch transactions. Steps to reproduce: - Open the 'Tax Paid' account and enable 'Allow Reconciliation' - Create a bill using a tax and post it - Go to the Bank Reconciliation widget - Select a statement line and match it with the tax line from the bill Issue: The line cannot be unmatched because the related button is missing opw-5871821 Forward-Port-Of: odoo/enterprise#110186
This update resolves an issue that caused errors when deleting counterpart lines in the Bank Reconciliation widget. The fix ensures the system correctly handles data, preventing unexpected errors and improving the stability of this key financial process. This change was triggered by a bug in how a specific method handled data, impacting the Bank Reconciliation workflow.
Original PR description
The `get suspenseAccountLine`` method could return False, which is not valid for the BankRecButtonList component props. This commit ensures the method returns either an object or undefined. Step to reproduce: - Enable developer mode - Open the Bank Reconciliation widget - Create a bank transaction - Reconcile the transaction - Click on the trash icon on the counterpart line - Previously, a traceback would occur due to invalid props opw-6012604 opw-6066531 opw-6066116 opw-6065924 opw-6063884 opw-6062905 opw-6062590 opw-6060781
This update adds specific journal entry options for F4 and F2 VAT types within the Spanish VAT reporting module. This ensures accurate accounting and reporting for these common VAT classifications, aligning with Spanish tax regulations. The change enhances the functionality of the l10n_es_reports module.