Daily updates from Odoo
Monday, March 30, 2026
135 changes
11 changes
Resolved issues and error corrections
This update allows users to access and view canceled signature requests within the Odoo portal. Previously, canceled requests were hidden, preventing users from seeing important communication history and document details. The change simplifies the user experience by aligning the display for canceled requests with completed requests.
Original PR description
Previously, users were redirected to the home page if they tried to access a signature request in the 'canceled' state. This prevented them from viewing the communication history or the document metadata. This commit: - Removes the 'canceled' state restriction in the portal controller. - Updates the portal template to show "View Document" instead of "Sign" for canceled requests, similar to the completed state. Task: 6034621 Forward-Port-Of: odoo/enterprise#111534 Forward-Port-Of: odoo/enterprise#110974
A test used in the Odoo Enterprise payroll module failed due to an incorrect date calculation. This fix adjusted the test environment to ensure accurate results, preventing future disruptions to payroll processing. The change addresses a discrepancy in how date ranges were being evaluated during testing.
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 in the l10n_pe_edi_pos module that prevented accurate consolidation of Point of Sale (POS) orders. The system now validates order groupings, preventing errors when attempting to combine invoices that don't meet necessary criteria and providing helpful error messages to the user.
Original PR description
Joining the values in the selection field with a coma, and then putting everything in another selection field was plain wrong. We now check a bit better what we're generating, and refrain the user with error messages when they try grouping on the same invoices orders that do not share the necessary key values. Forward-Port-Of: odoo/enterprise#111616
This update resolves a crash issue when opening tax reports in Odoo Enterprise. The fix ensures reports without a defined return type automatically use the company's tax periodicity, preventing errors and improving report stability. This enhances the reliability of financial reporting.
Original PR description
When a report uses 'previous_return_period' date_scope on one of its expressions, if there's no account.return.type linked to that report, the opening of the report crashes. This is a bit stupid,…
When a report uses 'previous_return_period' date_scope on one of its expressions, if there's no account.return.type linked to that report, the opening of the report crashes. This is a bit stupid, since a return type without periodicity will anyway fallback to the the company's tax periodicity field. When there's no return type, we should simply fallback in the same way. To reproduce: - Make a Belgian company, install the CoA and localization - Manually uninstall l10n_be_reports - Try opening the tax report Another message also checked that we couldn't compute this date_scope in case there was more than one return type linked to the report, arguing they have different periodicities, so we can't infer which one to use. However, it they actually shared the same periodicity, that check failed anyway. We refine it to authorize this case, and only raise if they truly have different periodicities. opw-6022150 Forward-Port-Of: odoo/enterprise#111872 Forward-Port-Of: odoo/enterprise#111796
This update resolves a technical issue preventing invoices with discounts and decimal values (over 2 decimals) from successfully sending to ARCA for Arabic EDI processing. The fix utilizes a truncated unit price for discount calculations, ensuring accurate decimal alignment and preventing errors.
Original PR description
After changes made in Odoo of how the decimal precision works some of the code we use to prepare the data to create EDI invoices now fails. We already adapt the code to fix the data depending of the expected webserive format but we miss a case related to when invovice has discounts. The problem is that any invoice with lines that has more than 2 decimals and also have a discount will fail when trying send it to ARCA because the computed amount has differences in the decimals. Now we use the truncated unit price to compute the discount instead of the full amount with decimal of the `line.price_unit` value. Forward-Port-Of: odoo/enterprise#111518 Forward-Port-Of: odoo/enterprise#110706
This update clarifies the error message displayed when an upsell's start date is set after the next invoice date. This change ensures users receive clearer guidance, preventing confusion and potential issues with subscription billing. It's a simple fix to improve the user experience.
Original PR description
Update the error message when an upsell start date is on or after the next invoice date, so it be more clear for the users. task-5893032 Forward-Port-Of: odoo/enterprise#106757
This update resolves an issue where upgrading the `l10n_ae` module would fail if the user had renamed the "United Arab Emirates" country in Odoo's settings. The fix replaces references to country names in a key data file with a stable XMLID, ensuring consistent module upgrades regardless of user customizations.
Original PR description
### Steps to reproduce ------------------ - Install `l10n_ae` module. - Go to *Settings → Countries* and rename the country "United Arab Emirates" (e.g. change it to "UAE"). - Upgrade the `l10n_ae`…
### Steps to reproduce
------------------
- Install `l10n_ae` module.
- Go to *Settings → Countries* and rename the country "United Arab Emirates" (e.g. change it to "UAE").
- Upgrade the `l10n_ae` module.
### Issue
-----
The file `l10n_ae/data/res.bank.csv` references the country using its name ("United Arab Emirates"). During the module upgrade, the CSV import tries to resolve the country relation using the country name. If the country name has been modified by the user (for example to "UAE"), the lookup fails and the module upgrade crashes with:
```python3
No matching record found for name 'United Arab Emirates' in field 'Country'
```
### Root Cause
----------
Using translatable/display names in CSV data is unreliable, as these values can be customized or translated by users.
### Fix
---
Replace the country name reference with the stable XMLID `base.ae` in `res.bank.csv`.
Using XMLIDs ensures consistent resolution regardless of name changes or translations.
opw-6015302
upg-3950261
tbg-2492
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#255993This update corrects an issue where the Odoo module upgrade would fail if the country names in CSV data files (for Peru and Ecuador) were changed. By using stable XML IDs instead of names, the system now reliably resolves many-to-one relationships during module upgrades, preventing crashes.
Original PR description
### Steps to reproduce ------------------ - Install `l10n_pe` or `l10n_ec` module. - Go to *Settings → Countries* and rename the country (e.g. "Peru" → "PERÚ", "Ecuador" → "ECUADOR"). - Upgrade the…
### Steps to reproduce
------------------
- Install `l10n_pe` or `l10n_ec` module.
- Go to *Settings → Countries* and rename the country (e.g. "Peru" → "PERÚ",
"Ecuador" → "ECUADOR").
- Upgrade the module.
### Issue
-----
The files `l10n_pe/data/res.bank.csv` and `l10n_ec/data/res.bank.csv`
reference countries using their names (e.g. "Peru", "Ecuador").
During module upgrade, the CSV import resolves many2one relations using
the country name. If the country name has been modified by the user,
the lookup fails and the module upgrade crashes with:
```python3
2026-03-06 23:48:11,112 27 CRITICAL db_3950261 odoo.service.server: Failed to initialize database `db_3950261`.
Traceback (most recent call last):
File "/home/odoo/src/odoo/19.0/odoo/service/server.py", line 1510, in preload_registries
registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'], reinit_modules=config['reinit'])
File "/home/odoo/src/odoo/19.0/odoo/tools/func.py", line 88, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/19.0/odoo/orm/registry.py", line 199, in new
load_modules(
File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 456, in load_modules
load_module_graph(
File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 216, in load_module_graph
load_data(env, idref, mode, kind='data', package=package)
File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 59, in load_data
convert_file(env, package.name, filename, idref, mode, noupdate=kind == 'demo')
File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 689, in convert_file
convert_csv_import(env, module, pathname, fp.read(), idref, mode, noupdate)
File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 754, in convert_csv_import
raise Exception(env._(
Exception: Module loading l10n_pe failed: file l10n_pe/data/res.bank.csv could not be processed:
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
select id,name,code from res_country where code='PE'
+-----+----------------------------------------------------------------------+------+
| id | name | code |
|-----+----------------------------------------------------------------------+------|
| 173 | {"de_DE": "Peru", "en_US": "PERÚ", "es_ES": "PERÚ", "es_PE": "Perú"} | PE |
+-----+----------------------------------------------------------------------+------+
```
### Root Cause
----------
Using translatable/display names in CSV data is not reliable, as these
values can be customized or translated.
### Fix
---
Replace country name references with stable XMLIDs:
- `base.pe` for Peru
- `base.ec` for Ecuador
Using XMLIDs ensures consistent resolution regardless of name changes
or translations.
opw-6015302
upg-3950261
tbg-2492
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#256201
Forward-Port-Of: odoo/odoo#254096This update fixes an issue where code blocks within toggle lists would lose their formatting when the toggle was closed. The fix ensures that multiline code content is correctly preserved, regardless of the toggle's state, providing a consistent and functional experience for users. This improves the readability and usability of code snippets within the application.
Original PR description
### Steps to Reproduce: - Create a toggle list and add content. - Expand the toggle list and insert a code block (e.g.: /code). - Add multiple lines inside the code block using Enter. - Refresh the…
### Steps to Reproduce: - Create a toggle list and add content. - Expand the toggle list and insert a code block (e.g.: /code). - Add multiple lines inside the code block using Enter. - Refresh the page with the toggle open, content is preserved. - Close the toggle and refresh then content collapses into one line. ### Description of the issue/feature this PR addresses: - When the toggle list is closed, the code block is inside `display: none` container. In this state, `innerText` depends on rendered layout and does not preserve newline characters `\n`. As a result, multiline code content is extracted as single line. ### Desired behavior after PR is merged: - Read html and normalize it into plain text by: - Converting `<br>` tags into newline characters. - Stripping remaining HTML tags. - Decoding HTML entities back to their literal characters. - Removing the extra newline introduced by a trailing `<br>` - Cleaning up invisible zero-width characters. task-5909034 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248391
This update resolves an issue preventing barcode scanning of product packaging when a product doesn't have a barcode defined. The fix ensures the system searches for the product when a barcode is scanned on packaging, allowing for seamless barcode scanning functionality within the Point of Sale module. This improves the user experience and accuracy of sales transactions.
Original PR description
Step to reproduce - Create a product - Add two attributes: 1. One with Instantly creation mode 2. One with Never creation mode - Define packaging from the Sales tab - Add a barcode on the variant packaging ex: 111356,11357 - Scan the packaging barcode in POS Observation: - we get a traceback `TypeError: Cannot read properties of undefined (reading 'product_template_attribute_value_ids')` Cause: - when we do not have barcode on product, when opening `openConfigurator` - (as we have few varianst) product get undefined. https://github.com/odoo/odoo/blob/f229f23d7bf3d837ff5577c36145bf2ba410ea22/addons/point_of_sale/static/src/app/services/pos_store.js#L738 - Hence the traceback Fix: - For the case, when packaging has barcode but not the product, we search for product in that case too. opw-5886570 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253195 Forward-Port-Of: odoo/odoo#248838
This update ensures the HTML editor's tests consistently use the Roboto font, regardless of the user's computer. Previously, variations in fonts could cause test failures. This change improves the reliability of our testing process and ensures a more predictable user experience for HTML editing.
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
14 changes
Resolved issues and error corrections
A recent update caused partner names in the approval request report to overflow, making the report unreadable. This fix adds a column limit to the partner field, ensuring all data displays correctly and preventing visual errors. This improves the report's usability and data presentation.
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 fixes a warning displayed in the tax report when vendor bills have expense lines with different vehicle assignments. The change allows for more flexibility in how tax lines are matched, ensuring accurate reporting even with mixed vehicle expense lines. 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 resolves an issue where web_studio would generate an error when users attempted to save reports with empty XML formats. The fix prevents the system from attempting to process invalid XML data, ensuring reports can be saved correctly. This improves the user experience and prevents data loss.
Original PR description
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External…
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External > Type Text in report - Save > Edit Sources > Remove full XML > Save Error: `XMLSyntaxError:Document is empty, line 1, column 1 (<string>, line 1)` This error occurs because line [1] in `web_editor` attempts to access nodes by using `etree.fromstring()` with an empty `view.arch`, which is empty, resulting in an error. In earlier versions, this error was already handled by the `_check_xml` constraint, which raised a validation error when an `etree.ParseError` occurred while parsing `etree.fromstring(view.arch)` with an empty `view.arch` (see code reference [2]). However, recent changes introduced in commit [3] allow `view.arch` to be empty. As a result, this error is no longer handled by the constraint. This commit fixes the issue by adding a condition to prevent calling `etree.fromstring()` when `view.arch` is empty, avoiding attempts to access nodes from invalid data. It also updates the logic in the `web_studio` module's `get_xml_editor_resources` method to ensure resources are processed only when a valid view architecture is available. [1]: https://github.com/odoo/odoo/blob/8a88756bed194910bc5a47e93f0e29610dbeee1f/addons/web_editor/models/ir_ui_view.py#L367 [2]: https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/odoo/addons/base/models/ir_ui_view.py#L372-L377 [3]: https://github.com/odoo/odoo/commit/8334ea5c777e5a478f12b8bb7a2f54bcae537d0f sentry-6288795955 Forward-Port-Of: odoo/enterprise#112111 Forward-Port-Of: odoo/enterprise#88613
A test used in the Odoo Enterprise payroll module failed due to an incorrect date calculation. This fix adjusted the test environment to ensure accurate results, preventing future disruptions to payroll processing. The change addresses a discrepancy in how dates were being interpreted during testing.
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 ensures that changes to salary information within the Odoo system only affect related calculations, specifically the mobility budget. Previously, changes in other areas could trigger unintended updates, now the system is more consistent and reliable when managing salary configurations. This improves data accuracy and reduces potential errors.
Original PR description
For consistency purposes, we only trigger the inverse on the mobility budget computation if we are in the context of the salary configurator. Changing the wage in the back end or changing the employer cost should only touch the wage and not other benefits
This update resolves a technical issue where a controller in the E-Commerce localization module (l10n_eg_iot) was incorrectly referencing outdated code from a previous Odoo version. This fix ensures the module functions correctly and avoids potential disruptions to the E-Commerce process. It's a routine maintenance update.
Original PR description
`iot_box_setup` override is still calling the previous method names, mistakenly fw ported from 19. This commit fixes it.
This update resolves a crash issue when opening tax reports in Odoo Enterprise. The fix ensures reports without a defined return type automatically use the company's tax periodicity, preventing errors and improving report stability. This enhances the reliability of financial reporting.
Original PR description
When a report uses 'previous_return_period' date_scope on one of its expressions, if there's no account.return.type linked to that report, the opening of the report crashes. This is a bit stupid,…
When a report uses 'previous_return_period' date_scope on one of its expressions, if there's no account.return.type linked to that report, the opening of the report crashes. This is a bit stupid, since a return type without periodicity will anyway fallback to the the company's tax periodicity field. When there's no return type, we should simply fallback in the same way. To reproduce: - Make a Belgian company, install the CoA and localization - Manually uninstall l10n_be_reports - Try opening the tax report Another message also checked that we couldn't compute this date_scope in case there was more than one return type linked to the report, arguing they have different periodicities, so we can't infer which one to use. However, it they actually shared the same periodicity, that check failed anyway. We refine it to authorize this case, and only raise if they truly have different periodicities. opw-6022150 Forward-Port-Of: odoo/enterprise#111872 Forward-Port-Of: odoo/enterprise#111796
This update prevents unnecessary rental planning slots from being created when the 'Plan Services' feature is disabled. Previously, updating a rental order would trigger the creation of slots, even without planning. This fix ensures that slots are only generated when 'Plan Services' is enabled, streamlining the rental planning process.
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 clarifies the error message displayed when an upsell's start date is set after the next invoice date. This change ensures users receive clearer guidance, preventing confusion and potential issues with subscription billing. It's a simple fix to improve the user experience.
Original PR description
Update the error message when an upsell start date is on or after the next invoice date, so it be more clear for the users. task-5893032 Forward-Port-Of: odoo/enterprise#106757
This update resolves a bug where commission calculations were incorrectly defaulting to 0% when the target completion was set to 0%. The fix ensures that commissions are accurately calculated when the target is 0, addressing a potential revenue discrepancy. This improvement impacts sales reporting accuracy.
Original PR description
Before this commit, when target completion was 0% and the commission was equal to X (where X is not null), the commission could not be equal to X. It would be equal to 0. It was working with target amount equal to 0.
This update resolves an issue where excessively long product names in the Master Production Schedule would cause other schedule columns to disappear from view. The fix wraps long text within product names to prevent this visual disruption, ensuring all schedule information remains accessible.
Original PR description
Problem: In the master production schedule, if a product on the schedule has a name that would extend to the right edge of the screen, all of the other colums for the schedule will be completely hidden. Solution: We will wrap the text in the <a> tag containing the product name. Steps to Replicate (Runbot v19): 1. Open the Master Production Schedule 2. Click the pencil on one of the products 3. Click into the product and change its name to be something very, very long 4. Navigate back to the MPS and notice that you cannot see the actual schedule elements, even if you scroll to the end. opw-6066088 Forward-Port-Of: odoo/enterprise#111896
This update resolves an issue where right-clicking while editing a message in the email system displayed the Odoo context menu instead of the standard browser menu. Now, right-clicking correctly opens the browser's default context menu, improving the user experience and consistency.
Original PR description
Before this commit, right-clicking while editing a message opened the message context menu instead of the browser's default menu. After this commit, right-clicking while editing a message opens the browser's default context menu, and the message context menu is no longer triggered. task-6065753
This update resolves an issue that prevented users from creating scrap orders when a scrap location was missing. The fix ensures the system handles the absence of a scrap location gracefully, preventing a technical error and allowing users to properly dispose of excess inventory. This improves the reliability of the stock management process.
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
This update fixes an issue where code blocks within toggle lists would lose their formatting when the toggle was closed. The code now correctly preserves newline characters within the code block's HTML, ensuring that multi-line code is displayed accurately regardless of the toggle's state. This improves the user experience when working with code snippets.
Original PR description
### Steps to Reproduce: - Create a toggle list and add content. - Expand the toggle list and insert a code block (e.g.: /code). - Add multiple lines inside the code block using Enter. - Refresh the…
### Steps to Reproduce: - Create a toggle list and add content. - Expand the toggle list and insert a code block (e.g.: /code). - Add multiple lines inside the code block using Enter. - Refresh the page with the toggle open, content is preserved. - Close the toggle and refresh then content collapses into one line. ### Description of the issue/feature this PR addresses: - When the toggle list is closed, the code block is inside `display: none` container. In this state, `innerText` depends on rendered layout and does not preserve newline characters `\n`. As a result, multiline code content is extracted as single line. ### Desired behavior after PR is merged: - Read html and normalize it into plain text by: - Converting `<br>` tags into newline characters. - Stripping remaining HTML tags. - Decoding HTML entities back to their literal characters. - Removing the extra newline introduced by a trailing `<br>` - Cleaning up invisible zero-width characters. task-5909034 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248391
6 changes
Resolved issues and error corrections
A recent update caused partner names in the approval request report to be cut off when exceeding a certain length. This fix adds a column limit to the partner field, ensuring all data is displayed correctly and preventing data truncation. This improves the report's accuracy and readability.
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 resolves an inconsistency in the tax report when vendor bills include expense lines with different vehicle assignments. The fix allows for accurate reporting by relaxing a strict matching rule that previously flagged mixed vehicle lines. This ensures all tax calculations are correct, regardless of whether a vehicle is associated with an expense line.
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
A test used an incorrect date reference (2027) which caused it to fail. This fix adjusted the test's date to 2026-02-28 to accurately reflect the payroll calculations, ensuring the test now passes. This resolves a potential issue with reporting accuracy.
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 clarifies the error message displayed when an upsell's start date is set after the next invoice date. This change ensures users receive clearer guidance, preventing confusion and potential issues with subscription billing. It's a simple fix to improve the user experience.
Original PR description
Update the error message when an upsell start date is on or after the next invoice date, so it be more clear for the users. task-5893032 Forward-Port-Of: odoo/enterprise#106757
This update resolves a test failure within the industry_fsm_report module. The issue stemmed from a wizard opening unexpectedly when there was only one worksheet, causing test failures. A workaround was implemented by adding a worksheet before running the tour to prevent the wizard from opening.
Original PR description
When there is only one worksheet, the ‘**Explore Worksheets Using an Example Template**’ wizard opens. Because of this, the test fails without demo data. If we add steps for this wizard, it won’t open when there is more than one worksheet, which will again cause the test to fail. Also, we cannot add this conditon on step. Therefore, to ignore this wizard, i created a worksheet before running the tour so that the wizard does not open. https://github.com/odoo/enterprise/blob/85bd9d80a1a784f1baff1493b2eaec4a17ea9c9b/industry_fsm_report/models/project_task.py#L122-L135 task-4489657 runbot issue-240933
This update resolves a bug that occurred when creating contracts with a working schedule having zero hours. The issue caused a calculation error (division by zero) during wage computation. This fix ensures accurate wage calculations for all contract types, regardless of working hour values.
Original PR description
When a working schedule has 0 working hours, creating a contract raises a traceback during hourly wage computation. Steps to reproduce the error: - Install ``l10n_au_hr_payroll`` module - Switch to ``My Australian Company`` - Create a working schedule without any working hours - Create an employee and assign this working schedule > Save - Click on Contracts smart button Traceback: ```py ZeroDivisionError: float division by zero ``` https://github.com/odoo/enterprise/blob/bd746aa43f549c4f7813a849e00447b55e084f21/l10n_au_hr_payroll/models/hr_contract.py#L113-L115 The hourly wage is computed using the working schedule’s hours per day. When this value is 0, it results in the above traceback. sentry-7355577930 Forward-Port-Of: odoo/enterprise#111629
21 changes
Resolved issues and error corrections
This update prevents a critical error that occurred when users attempted to create scrap orders without a designated scrap location. The issue stemmed from accessing an empty dictionary after a scrap location was deleted, leading to a traceback. This fix ensures that scrap orders can now be created successfully, regardless of the scrap location setup.
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
This update corrects an issue preventing the export of Profit & Loss reports with footnotes in the Luxembourg localization. The previous export process relied on an outdated model, causing errors. The fix now correctly utilizes the new `account.report.annotation` model for footnote references, ensuring successful XML generation.
Original PR description
**Steps to reproduce:** * Install the **l10n_lu_reports** module. * Go to **Accounting → Reporting → Profit & Loss**. * Add a footnote on a report line (**⋮ → Annotate**). * Click **Export (XML)** to open the export wizard. * Enable **Import notes as references** and export. **Observed behavior:** * Export fails with `KeyError: 'account.report.manager'`. * XML file cannot be generated when references are enabled. **Cause:** * The export logic relied on the deprecated `account.report.manager` model. * This model was removed in v17([commit](https://github.com/odoo/enterprise/pull/33604/changes#diff-5fc5051f5c0211c0eec96b892e7d29e01b68d804417443502d17bccd8333d7ecL41)) and replaced by `account.report.footnote`. * The footnote retrieval code was not migrated accordingly. **Fix:** * Migrate reference retrieval to use `account.report.footnote`. opw-5890630 Forward-Port-Of: odoo/enterprise#111845 Forward-Port-Of: odoo/enterprise#107765
A recent update caused partner names in the approval request report to overflow, making the report visually unclear. This fix adds a column limit to the partner field, ensuring all data is displayed correctly and preventing the report from becoming unreadable. This improves the report's usability and data accuracy.
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 fixes an issue where invoices created with the 'Pay Later' payment method in the Point of Sale module were missing the necessary QR code for payment. The fix ensures that invoices correctly identify the bank partner, resolving this problem and allowing for proper payment processing. This improves the user experience for customers using this payment option.
Original PR description
Step to reproduce: - Install l10n_ch_pos and make sure swiss company has tax id filled - Create a swiss customer with an email address and vat, add full address - Open a pos session, and make an invoice for a product with tax, - select payment method, which allows `pay_later`, i.e. payment without journal_id Observation: - the invoiced order, do not have qr for payment, because the invoice do not have `bank_partner_id` Cause: - `_get_partner_bank_id` is recently updated in commit[1], which do not considered `pay_later` option [1] https://github.com/odoo/odoo/commit/7e63991dceb6e443b950e6a1b94454a82d5668c7 Fix: - Fixed the fallback logic for `_get_partner_bank_id` opw-6023060 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254892 Forward-Port-Of: odoo/odoo#254117
This update ensures that when creating new analytic items from the gross margin smart button, the correct analytic account is automatically selected. Previously, new records didn't link to an account, requiring manual setup. This change streamlines the process and improves data accuracy within the analytic accounting module.
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
This update fixes an issue where chatbot restart messages were incorrectly included in new ticket or lead descriptions. Now, only messages sent after the chatbot is restarted are accurately reflected, ensuring ticket descriptions are clean and relevant. This improves the clarity and usability of customer support tickets.
Original PR description
Before this commit: When a chatbot conversation is restarted and the script creates a new ticket/lead, the description also includes messages from the previous session. After this commit: Only the messages sent after the chatbot conversation is restarted are included in the ticket/lead description. Task-5118966 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255336 Forward-Port-Of: odoo/odoo#253566
This update replaces the old iDEAL logo with the new Wero logo for improved brand consistency. The change ensures that customers see the correct payment brand when using the iDEAL payment method within Odoo, enhancing the user experience.
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
This update resolves an issue where the tax report incorrectly flagged inconsistencies when vendor bills had expense lines with different vehicle assignments. The fix allows for accurate reporting when lines share a tax but have varying vehicle IDs, ensuring consistent tax calculations for all expenses.
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 ensures that the system correctly checks archived accounts when creating unaffected earnings accounts. Previously, this caused validation errors, particularly during upgrades with the `l10n_sa` module, due to a search for duplicate account codes including archived ones.
Original PR description
Archived accounts are also searched when looking for duplicate codes since https://github.com/odoo/odoo/commit/cd8d9718427e48aaa79be21f9a08e89b79b573f9 We need to check archived accounts as well when creating the unaffected earnings account, to avoid triggering the validation if an archived account has the same code. This is failing on upgrades with `l10n_sa` installed where the account `sa_account_999999` has been archived.
This update resolves an issue where the VAT partner listing report was not displaying all relevant customers. The fix involves adjusting a setting within the report to load all partners, ensuring accurate reporting of financial data. This improves data visibility and reporting accuracy for tax compliance.
Original PR description
With l10n_be company: - Create at least two invoices for two different customers (companies) for whom you will add a fake VAT number. Make sure the total on both your invoices is more than 250€ and…
With l10n_be company: - Create at least two invoices for two different customers (companies) for whom you will add a fake VAT number. Make sure the total on both your invoices is more than 250€ and set their Accounting date to last year. - Go check the VAT partner Listing report (Accounting > Reporting); make sure you see both partners in the listing. - Click on returns > Check that report return then Submit and download the XML file: both partners & amounts will appear. - Now with dev mode, go to Accounting reports, open the Partner VAT listing form > Options > set the "load more limit" to 1. Download the XML again: only the first partner appears (the only that was loaded with the load more limit. This commit is a backport of bugfix: PR odoo/enterprise#106134 commit e532750fe3dc1f2d10d995d01446b04a3a227a72 Original problem introduced in `saas-18.3`: PR odoo/enterprise#111783 commit 4c927b389252b595bcbb44d020899ae5abf0aa89 Ticket [link](https://www.odoo.com/odoo/project.task/6051120) opw-6051120
A test used in the payroll module (l10n_ch_hr_payroll_elm_transmission) was failing due to an incorrect date calculation. The fix involved adjusting the test's time setting to ensure accurate calculations for future payroll years, preventing a disruption in reporting.
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 a labeling issue with the 0% VAT rate for sales outside the EU in Sweden. The tax name has been corrected to '0% EX RS' to accurately reflect its usage, and the associated grid has been updated. This ensures accurate tax reporting and compliance for Swedish customers.
Original PR description
Currently, the tax for "VAT Sale of service outside EU 0%" has the 0% EU RS name and is associated with the se_39 grid. Since it is for outside the EU, it's name should be 0% EX RS and the grid should be se_40 opw-5798152 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251750
This update fixes an issue where Chrome logs weren't reliably captured during shutdown, particularly when errors occurred. The changes also address Chrome's log buffering behavior and add resilience to ensure a smoother shutdown process, preventing data loss.
Original PR description
odoo/odoo#255054 saved the chrome log at the end of a tour (logging that as `INFO` on success and `RUNBOT` on failure). However as it turns out there are a few issues with that: 1. In case of chrome error during termination (`stop`), those errors can not be in the log, since the log was already saved. 2. Chrome buffers logs a lot more than anticipated, and because `--v=0` logs are a lot less chatty than `--v=1` the logs routinely show essentially nothing (a few tour steps are logged then nothing). Also make `stop` a bit more resilient to chrome issues: - handle errors around ws shutdown - wait for chrome to shut down before we try to remove the data directory - also add a fallback *killing* chrome if it doesn't seem to be shutting down Forward-Port-Of: odoo/odoo#256306 Forward-Port-Of: odoo/odoo#256061
This update resolves an issue that prevented the creation of contracts when a working schedule had zero hours. The fix prevents a division-by-zero error during hourly wage computation, ensuring contracts can be created correctly. This improves the reliability of the Australian payroll module.
Original PR description
When a working schedule has 0 working hours, creating a contract raises a traceback during hourly wage computation. Steps to reproduce the error: - Install ``l10n_au_hr_payroll`` module - Switch to ``My Australian Company`` - Create a working schedule without any working hours - Create an employee and assign this working schedule > Save - Click on Contracts smart button Traceback: ```py ZeroDivisionError: float division by zero ``` https://github.com/odoo/enterprise/blob/bd746aa43f549c4f7813a849e00447b55e084f21/l10n_au_hr_payroll/models/hr_contract.py#L113-L115 The hourly wage is computed using the working schedule’s hours per day. When this value is 0, it results in the above traceback. sentry-7355577930 Forward-Port-Of: odoo/enterprise#111629
This update fixes an issue where URLs in emails were incorrectly encoded, potentially leading to display problems. The change utilizes modern URL handling techniques for accurate URL construction and display, ensuring correct links are presented to users. This improves the reliability of email communications within Odoo.
Original PR description
Before this commit, the URL was fully encoded using encodeUrl. This commit replaces this approach with the more modern [URL api](https://developer.mozilla.org/en-US/docs/Web/API/URL), which [handles encoding](https://url.spec.whatwg.org/#dom-url-href) properly. This commit also removes decodeUrl. It was possible for a user to send a URL and have a different one displayed in the UI due to decoding. Task-6041689 Forward-Port-Of: odoo/odoo#254383
A test tour was failing because the test user lacked the necessary security group (`group_production_lot`) to enable line grouping in the stock barcode model. This fix adds the required group, allowing the tour to complete successfully and ensuring proper functionality for lot scanning and packaging.
Original PR description
```js ---------- FAILED: [7/19] Tour test_quality_check_packages_lots_tour → Step .o_barcode_line_summary ---------- { 'trigger': '.o_barcode_line_summary', 'run': 'click' },…
```js
---------- FAILED: [7/19] Tour test_quality_check_packages_lots_tour →
Step .o_barcode_line_summary ----------
{
'trigger': '.o_barcode_line_summary',
'run': 'click'
},
------------------------------------------------------------------------
```
The tour `test_quality_check_packages_lots_tour` was failing at the step
waiting for `.o_barcode_line_summary` after calling `o_put_in_pack`.
**Root cause:**
the JS barcode model sets `groupingLinesEnabled` directly from
the `group_production_lot` security group flag returned by the backend:
https://github.com/odoo/enterprise/blob/bd35e9c16a6c0fd743c934024db2821b8ae21fdc/stock_barcode/static/src/models/barcode_model.js#L53
When `groupingLinesEnabled` is false, `groupLines()` skips the grouping
logic entirely and individual move lines are rendered as flat
`LineComponent` instances. The `.o_barcode_line_summary` element only
exists inside `GroupedLineComponent`, which is only rendered when lines
are actually grouped (i.e. a parent line has `line.lines` sublines).
The test setup already granted `group_tracking_lot` (required to show the
`o_put_in_pack` button) but was missing `group_production_lot`. Without
it, after scanning `lot-01` twice and packing, the two lot sub-lines were
never merged into a `GroupedLineComponent`, so `.o_barcode_line_summary`
never appeared in the DOM and the tour timed out.
Fix: add `group_production_lot` alongside `group_tracking_lot` in the
test user's groups so that line grouping is enabled in the JS model,
allowing `GroupedLineComponent` to render `.o_barcode_line_summary` as
expected by the tour.
similar fix - https://github.com/odoo/enterprise/pull/82677/changes/05883b2c9cadb1187df404a4bef638f933922755
---
runbot error:241926This update resolves a bug that prevented the FSM reporting tour from completing correctly when run without demo data. A new worksheet was added to stop the "Explore Worksheets" wizard from appearing, ensuring the tour flows as intended. This improves the user experience for accessing the FSM reporting features.
Original PR description
**Reason for creating the worksheet:** ------------- When the tour runs without demo data, only one worksheet exists, so the **“Explore Worksheets Using an Example Template”** wizard opens and stops the tour. To avoid this, I created an extra worksheet so the wizard does not open and the tour continues normally. https://github.com/odoo/enterprise/blob/85bd9d80a1a784f1baff1493b2eaec4a17ea9c9b/industry_fsm_report/models/project_task.py#L122-L135 task-4489657 Forward-Port-Of: odoo/enterprise#81823
This update clarifies the error message displayed when an upsell's start date is set after the next invoice date. This change ensures users receive clearer guidance, preventing confusion and potential issues with subscription billing. It’s a simple fix to improve user experience.
Original PR description
Update the error message when an upsell start date is on or after the next invoice date, so it be more clear for the users. task-5893032 Forward-Port-Of: odoo/enterprise#106757
This update corrects a change in the URL required to send e-invoices to the Serbian government. The previous URL was outdated, preventing proper e-invoice submission. This fix ensures compliance with Serbian regulations and allows seamless e-invoice processing.
Original PR description
**PROBLEM** The url to send e-invoice to the serbian government has changed. opw-6055622 Forward-Port-Of: odoo/odoo#256095
This update resolves an issue where Odoo displayed a misleading warning message to users when they didn't immediately set a password during file uploads. The system now correctly checks for a password during the saving process, improving the user experience and eliminating this unnecessary notification.
Original PR description
Before the change, when the user uploads a file, Odoo automatically shown a warning message saying that the content of the file or the password are incorrect. Now the system does not show the warning when a password is not set and checks if the password is set when saving task-6036219 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253834
This update corrects a technical detail by removing outdated tags (<report> and <act_window>) from the Odoo import files. These tags were previously removed in another change, but this commit ensures they are no longer present, maintaining the integrity of the import process. This ensures consistent and reliable data imports.
Original PR description
`<report>` and `<act_window>` tags has been removed in https://github.com/odoo/odoo/pull/98138, but not in the import_xml.rng file. This commit removes the two tags from the file. Forward-Port-Of: odoo/odoo#220116
5 changes
Resolved issues and error corrections
A recent update caused partner names in the approval request report to overflow and display incorrectly when names exceeded a certain length. This fix adds a column limit to the partner field in the report, ensuring all data is displayed correctly and preventing visual errors. This improves the report's readability and accuracy.
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 resolves a test failure related to the calculation of AVS deductions in the Swiss payroll module. The issue stemmed from a date calculation within the test environment that incorrectly compared dates, causing the test to fail. The fix uses a specific test time setting to ensure consistent date comparisons during testing.
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 resolves an issue where Field Service users with restricted access couldn't add customers to tasks, resulting in an access error. The fix involved a secure update to customer phone numbers and added restrictions to control who can modify them, ensuring all users can correctly manage tasks.
Original PR description
Steps to Reproduce: - 1. Log in with a user having only "Field Service > User" access. 2. Create a new task in an field service project. 3. Add a customer on the task. 4. Access error is raised. Issue: - - Field service users could not create a task with a customer. - An access error appeared during task creation. Cause: - - When a customer was added to the task, the partner_phone inverse method was triggered. - This method attempted to write on the partner record. Solution: - - Added a check before writing to avoid unnecessary writes. - Used sudo() to update the partner phone securely. - Added view-level restriction using base.group_partner_manager to control who can edit the phone number. task-5039657 Forward-Port-Of: odoo/enterprise#93969
This update resolves an issue that prevented contract creation when a working schedule had zero hours. The fix prevents a division-by-zero error during hourly wage computation, ensuring contracts can be created correctly. This improves the reliability of the Australian payroll module for My Australian Company users.
Original PR description
When a working schedule has 0 working hours, creating a contract raises a traceback during hourly wage computation. Steps to reproduce the error: - Install ``l10n_au_hr_payroll`` module - Switch to ``My Australian Company`` - Create a working schedule without any working hours - Create an employee and assign this working schedule > Save - Click on Contracts smart button Traceback: ```py ZeroDivisionError: float division by zero ``` https://github.com/odoo/enterprise/blob/bd746aa43f549c4f7813a849e00447b55e084f21/l10n_au_hr_payroll/models/hr_contract.py#L113-L115 The hourly wage is computed using the working schedule’s hours per day. When this value is 0, it results in the above traceback. sentry-7355577930 Forward-Port-Of: odoo/enterprise#111629
This update clarifies the error message displayed when an upsell's start date is set after the next invoice date. This change ensures users receive clearer guidance, preventing confusion and potential issues with subscription billing. It's a simple fix to improve the user experience.
Original PR description
Update the error message when an upsell start date is on or after the next invoice date, so it be more clear for the users. task-5893032 Forward-Port-Of: odoo/enterprise#106757
28 changes
New functionality added to Odoo
This update adds a required audit checklist for the French localization of Odoo Enterprise. It incorporates a spreadsheet provided by the PO (presumably a client) to ensure compliance with French reporting regulations. This ensures accurate and compliant financial reporting for French customers.
Original PR description
The french localization does not have a specific audit checklist The change is to add checks for the FR audit based on spreadsheet provided by PO task: 5411636
This update introduces a new report for French businesses, specifically the 2065 SD corporate tax return. It's part of a broader 'Liasse Fiscale' reporting bundle designed to streamline tax compliance for French companies within the Odoo Enterprise system. This addition supports accurate and timely reporting for French tax authorities.
Original PR description
This commit adds the 2065 SD corporate tax return report part of the "Liasse Fiscale" bundle of reports for France. Task ID: 5417366
Enhancements to existing features
This pull request updates the data files used for generating French report signatures, specifically incorporating new versions for the years 2031-2069. These changes ensure accurate and up-to-date signature templates for French accounting reports within the Odoo Enterprise system. This improves compliance and reporting accuracy for our French clients.
This update enhances how Odoo writes translated data to fields, now supporting dictionaries as field values. This change improves the flexibility and accuracy of translated content within the system, ensuring translations are correctly applied to various data points. It addresses a limitation in the previous code.
Original PR description
the override of `write` and `create` for translated fields, should support dict as field value. https://github.com/odoo/odoo/pull/246357
Resolved issues and error corrections
This update fixes a visual issue on the employee insurance form within the payroll module, ensuring the layout is correctly displayed on smaller screens. The problem stemmed from a technical issue with how input fields were being rendered, and the fix utilizes a different layout structure to resolve this. This ensures a consistent and user-friendly experience for all employees.
Original PR description
Step to reproduce: Employee -> Payrol Tab -> Insurance section -> Company contribution, Employee Contribution, Employee Voluntary Amount -> views not okay in small screens Cause: o_input_box not working with field as o_input_box_overlay_end Solution: using o_row Task: 6070539
This update fixes an issue where manufacturing order notes with only images were being hidden in the Shop Floor view. The change ensures that notes containing images or text are always displayed, improving the clarity and usability of this important production information.
Original PR description
In the Shop Floor view, manufacturing order notes containing only images were being hidden. The logic was stripping all HTML tags to check for text content; if no text was found, the entire note was treated as empty and returned false. This commit: - Updates `logNote` in `MRPDisplayRecord` to ensure the note is returned if it contains either visible text or an `<img>` tag. task-6048473 Forward-Port-Of: odoo/enterprise#111617
This update aligns the user interface of the Sign Now wizard with the Send Request wizard, creating a more uniform experience for users regardless of how they initiate the process (Sign Now or Send Request). This enhances usability and provides a clearer, more consistent workflow for users completing legal agreements.
Original PR description
in this commit i alligned the UI of sign send request wizard to look similar for both cases when the user click sign now and when the user click send request (self sign and send request) Task: 5942397 Forward-Port-Of: odoo/enterprise#108832
This update ensures the Helpdesk module correctly relies on the Portal Rating module following a recent system merge. Explicitly defining this dependency resolves a potential issue and maintains the stability of the Helpdesk functionality. This change is a routine maintenance update.
Original PR description
Before this commit, the helpdesk module now needs `portal_rating` module in its dependencies due to the merge of #112269 This commit updates the dependencies of helpdesk module to explicitly set the `portal_rating` in its dependencies.
This update fixes a visual inconsistency in the Sign app's PDF viewer. Previously, the viewer didn't follow the user's Odoo theme preference. Now, the PDF viewer automatically adapts to light or dark mode based on the user's Odoo settings, ensuring a consistent and professional user experience.
Original PR description
this PR includes 2 Fixes: 1- restore the sign item placeholder initialization that was removed by mistake in a previous refactoring 2- sync the pdf viewer theme with the global odoo theme ( the pdf viewer is an isolated iframe thus its not aware of any theme changes that happens in the parent html so we needed a js bridge to inject the theme values to the viewer) task: 6064905
This update ensures that public holidays are not considered when calculating time off for 'Unpaid' leaves. This change improves the accuracy of leave balances and simplifies the process for employees requesting unpaid leave. It addresses a previous inconsistency in how unpaid leave was handled.
Original PR description
-Public Holidays are set to be ignored in "Unpaid" leaves.
This update resolves problems with the trial balance PDF and working file exports in Odoo Enterprise. Specifically, incorrect dates in the working file exports and issues with the custom template were addressed, ensuring accurate reporting.
Original PR description
Steps to reproduce: - Export the PDF of the trial balance OR - Export a working file Both use the custom template of the trial balance. The date of the working file was also incorrect. Forward-Port-Of: odoo/enterprise#111409
This update resolves a problem where percentage fields in contract salaries were not loading correctly or displaying accurate values. The fix ensures that salary calculations and data display within the HR contract management module are now functioning as intended, improving data accuracy and usability.
Original PR description
Forward-Port-Of: odoo/enterprise#110940 Forward-Port-Of: odoo/enterprise#110785
A test used in the Swiss payroll module (l10n_ch_hr_payroll) was failing due to an incorrect date calculation within the AVS deduction process. This fix adjusts the test's time setting to ensure accurate results, preventing future test failures and maintaining the correct AVS calculations.
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 a technical issue that caused a traceback error when generating the 281.10 report in the Belgian payroll module. The fix ensures accurate report generation by adjusting how the system determines if a payslip is associated with a vehicle, resolving a dependency issue related to the absence of the fleet module.
Original PR description
[FIX] l10n_be_payroll: fix traceback in 281.10 sheets
Bug reproduction: Go to any version>=17.0 -> select belgium company -> install only belgium payroll (don't install fleet one) -> fill in niss, certification level, address, Time in R&D -> generate payslip and confirm it -> try to generate 281.10 report -> traceback
Bug cause:
1 - In traceback it was saying payslip doesn't have vehicle_id, in 281.10 sheet preparation (in function _get_atn_nature), there is a term like that
2 - Payslip doesn't have it because fleet module is not there.
Bug solution:
1 - Instead of checking the payslip has vehicle like that, we calculated it by using paylsip line_ids
2 - If the code ATN.CAR is there and the total of it is not zero, which means this payslip has a vehicle indeed.
task - 6037206
Forward-Port-Of: odoo/enterprise#111960
Forward-Port-Of: odoo/enterprise#110860This update allows users to access and view canceled signature requests within the Odoo portal. Previously, canceled requests were hidden, preventing access to important communication history and document details. Now, users will see the document and can review the request's status.
Original PR description
Previously, users were redirected to the home page if they tried to access a signature request in the 'canceled' state. This prevented them from viewing the communication history or the document metadata. This commit: - Removes the 'canceled' state restriction in the portal controller. - Updates the portal template to show "View Document" instead of "Sign" for canceled requests, similar to the completed state. Task: 6034621 Forward-Port-Of: odoo/enterprise#111534 Forward-Port-Of: odoo/enterprise#110974
This update resolves a crash issue when opening tax reports without a linked return type. The system now automatically falls back to the company's tax periodicity, ensuring reports open reliably. This improves the overall stability and usability of our tax reporting functionality.
Original PR description
When a report uses 'previous_return_period' date_scope on one of its expressions, if there's no account.return.type linked to that report, the opening of the report crashes. This is a bit stupid,…
When a report uses 'previous_return_period' date_scope on one of its expressions, if there's no account.return.type linked to that report, the opening of the report crashes. This is a bit stupid, since a return type without periodicity will anyway fallback to the the company's tax periodicity field. When there's no return type, we should simply fallback in the same way. To reproduce: - Make a Belgian company, install the CoA and localization - Manually uninstall l10n_be_reports - Try opening the tax report Another message also checked that we couldn't compute this date_scope in case there was more than one return type linked to the report, arguing they have different periodicities, so we can't infer which one to use. However, it they actually shared the same periodicity, that check failed anyway. We refine it to authorize this case, and only raise if they truly have different periodicities. opw-6022150 Forward-Port-Of: odoo/enterprise#111872 Forward-Port-Of: odoo/enterprise#111796
This update resolves a recurring issue where the Italian POS printer experienced errors when offline. The fix adds a safety mechanism to gracefully handle network disruptions during receipt printing, preventing tracebacks and ensuring smoother operation for users. This improves the reliability of the Italian POS system.
Original PR description
When loosing internet connexion a lot of tracebacks appear is the pos if we use the italian fiscal printer. Steps to reproduce: ------------------- * Setup italian fiscal printer for a shop * Open shop * Turn wi-fi off * Add items to cart * Go to payment screen > Traceback * Add a payment and validate > Traceback Why the fix: ------------ Don't try to reach the printer if we're offline regarding the price to pay. We add a try catch block around the call for printing the receipt. If the try block fails when the network is offline we assume it's just because of the offline mode. If it failed while online we raise the error. opw-5432090 Forward-Port-Of: odoo/enterprise#112076 Forward-Port-Of: odoo/enterprise#105515
This update fixes a potential issue where automated email systems (Mail Defender) could unintentionally cancel or reschedule appointments. The system now uses a form instead of a direct link, preventing these automated actions. This ensures appointments are handled correctly and reliably.
Original PR description
…ointments Mail defender services may click URLs in emails to verify their contents. Additionally they may sometimes interact with the page and visit related pages. For this reason URLs sent in emails should not trigger any action directly nor contain any simple link that could trigger an action. The "cancel/reschedule" anchor URL is replaced with a form which bots should not click. We also port the fix done in appointment to the view in appointment as it replaces the original view in this module. task-4555579 Forward-Port-Of: odoo/enterprise#112202 Forward-Port-Of: odoo/enterprise#79831
This update resolves issues causing warnings and tracebacks in several Odoo reports. By correcting how report parameters are defined, the system now handles warnings correctly, preventing errors and ensuring consistent report data. This improves the reliability and accuracy of key financial and tax reports.
Original PR description
Following odoo/enterprise#110087, `this.` was added before the warningParams, however it's defined in the ctx using t-set resulting in undefined values in a lot of reports. In the worst case, a traceback could occur when the report loaded like in l10n_lu_reports and the best case, the warning would just be missing (which isn't blocking but is wrong). The params to reportAction could also be set to undefined like in account_intrastat.
This update fixes an issue where archived employee versions were incorrectly appearing in payroll pay run reports. The change filters out archived employees from the domain, ensuring that only active employees are included in pay run calculations. This prevents inaccurate payroll reporting and maintains data integrity.
Original PR description
Steps to reproduce: 1. Create an employee with a contract for this month 2. Archive the employee (but not the version) 3. Create a pay run 4. The employee's version will appear in the list Cause: The domain takes versions for archived employees. Fix: Add active_employee in the domain. Task: 6022437 Forward-Port-Of: odoo/enterprise#110709 Forward-Port-Of: odoo/enterprise#110073
This update clarifies the error message displayed when an upsell start date is set too close to the next invoice date. This change ensures users receive clearer guidance, preventing potential issues with subscription setup and improving the overall user experience. It's a simple fix to enhance usability.
Original PR description
Update the error message when an upsell start date is on or after the next invoice date, so it be more clear for the users. task-5893032 Forward-Port-Of: odoo/enterprise#106757
This update fixes an issue where long product names in the Master Production Schedule would cause other schedule columns to disappear. The fix wraps long text within product names to ensure the entire schedule remains visible and functional. This improves the usability of the production planning tool.
Original PR description
Problem: In the master production schedule, if a product on the schedule has a name that would extend to the right edge of the screen, all of the other colums for the schedule will be completely hidden. Solution: We will wrap the text in the <a> tag containing the product name. Steps to Replicate (Runbot v19): 1. Open the Master Production Schedule 2. Click the pencil on one of the products 3. Click into the product and change its name to be something very, very long 4. Navigate back to the MPS and notice that you cannot see the actual schedule elements, even if you scroll to the end. opw-6066088 Forward-Port-Of: odoo/enterprise#112386 Forward-Port-Of: odoo/enterprise#111896
This update resolves an issue where the system incorrectly identified Swift accounts due to changes in Wise's API. By handling both 'swift_code' and 'SwiftCode' variations, the system now reliably processes direct deposit payments, preventing errors and ensuring accurate account identification.
Original PR description
Internally, Wise has changed their return value of their API to sometimes return `swift_code` and other times return `SwiftCode` depending on the create time of the recipient account. If the account is older than a few months it will use `SwiftCode` as the return value of GET /v2/accounts when they are created with type `swift_code` in the POST. As such, to be defensive this code handles both cases to not make any assumptions in case users have old or new accounts. This stops a traceback where the system doesn't think it's a swift account and tries to access abartn even though it doesn't exists. task-6070033 Forward-Port-Of: odoo/enterprise#112075
Features or functions removed from Odoo
This update removes the ability for non-internal users to view the IM status of other users. This change improves user privacy and reduces unnecessary data exposure, aligning with our commitment to responsible data practices. It simplifies the system for all users.
Original PR description
community PR: https://github.com/odoo/odoo/pull/248806 This commit removes the possibility for non-internal users to see the IM status of other users/guests. Non-internal users don't need this information, making it unnecessarily invasive.
This update removes outdated code related to thumbnail synchronization, specifically addressing a forgotten status restriction and a simplified condition. This cleanup improves the efficiency and maintainability of the documents module, ensuring a smoother user experience.
Original PR description
Purpose ======= In e6647b1c198395d6da1ee67f1bf7ac12db97cb95 we always synchronize the thumbail of the target and its shortcuts. But we forgot to remove the status "restricted", and the condition can be simplified. Task-6058483
This update removes outdated code related to the old tablet view for work orders. As the Shop Floor app replaced the tablet view, this cleanup ensures the system remains optimized and avoids unnecessary complexity. It's a routine maintenance task to improve efficiency.
Original PR description
As the tablet view was replaced by the Shop Floor app, it's now time to clean up the remaning tablet view code that wasn't removed at the time.
Miscellaneous changes
This pull request updates the master version of Odoo Enterprise with the latest rolldown, ensuring the system is running on the most current code. This update includes bug fixes and performance improvements, maintaining the stability and functionality of the core Odoo Enterprise platform. It's a routine maintenance task to keep the system up-to-date.
This pull request updates the visual templates used when creating sign requests in the Enterprise version of Odoo. These changes improve the user experience and ensure consistency in the design of sign request workflows. This is an internal update to improve the user interface.
10 changes
Resolved issues and error corrections
A 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.
5 changes
Resolved issues and error corrections
This update ensures that payment references are automatically updated when an invoice name is changed, improving invoice tracking and reconciliation. Currently, only the invoice name was updated, but this fix synchronizes the payment reference and related account move lines for accurate payment processing. This resolves an issue where payment details weren't consistently reflecting name changes.
Original PR description
Issue: Updating the invoice name should update the payment reference if the invoice isn't already sent. Step to reproduce: - Create an invoice, - Post it, - Draft it, - Change name, - Post it again, Current behavior: only the invoice name change Expected behavior: - invoice name change - payment_reference update - linked account_move_line labeled payment_term are updated as payment_term _inverse_payment_reference trigger a recompute of the right account move line name. opw-5428471
This update resolves a test failure related to the calculation of AVS deductions in the Swiss payroll module. The issue stemmed from an incorrect date calculation within the test environment, specifically when simulating data from 2027. The fix uses a temporary date freeze to ensure consistent test results.
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 clarifies the error message displayed when an upsell start date is set after the next invoice date. This change ensures users receive clearer guidance, preventing potential issues with subscription setup and improving the overall user experience. It's a simple fix to enhance usability.
Original PR description
Update the error message when an upsell start date is on or after the next invoice date, so it be more clear for the users. task-5893032 Forward-Port-Of: odoo/enterprise#106757
This update resolves an issue where PDF generation failed when users uploaded empty XML files. The fix skips PDF extraction when raw data is missing, preventing errors and ensuring consistent PDF creation. This improves the reliability of the documents account module.
Original PR description
Currently an error is generated and the file is not generated when the user uploads an empty XML file (e.g., ref file [1]). Error: `AttributeError: 'bool' object has no attribute 'decode'` This error occurs because the uploaded file contains no raw data. As a result, the system fails to retrieve the file content during PDF extraction from the XML at line [2]. This commit fixes the issue by skipping PDF extraction from the XML when the document has no raw data. The process now returns False early if the document contains no raw content. [1]: https://drive.google.com/file/d/1hRbgEsTL-iWhiAO245z_10HRH6nh3rUQ/view?usp=sharing [2]: https://github.com/odoo/enterprise/blob/00e2e658312eda2d3dae04eb966fd538972e5243/documents_account/models/documents_document.py#L52 sentry-7173452999
This update fixes a visual issue in the time off management Gantt chart. Previously, refused time off requests weren't clearly highlighted, making it difficult to see which requests were declined. This change ensures that refused time off is visually struck through, improving clarity and accuracy for managers.
Original PR description
Before this commit, the gantt view in Management > Time off menu does not strike the time off refused. The reason is because the wrong js_class is used inside that view. This commit updates the js_class to use inside that view to make sure the time off refused are striked. Issue similar to https://github.com/odoo/odoo/issues/248868