Daily updates from Odoo
Friday, February 27, 2026
293 changes
21 changes
Resolved issues and error corrections
This update resolves an issue where the tax report export button was failing when companies had different VAT numbers. By adding a setting to allow for branch company selection, the button now correctly handles multi-company setups, ensuring accurate report generation. This improves the reliability of financial reporting.
Original PR description
To reproduce the issue: - Create a company with a branch - Give the company and its branch different VAT numbers - Make both companies active in the company selector - Open the tax report - Click on gear icon - Click on the XML(l10n_lu_reports)/Export SAWT & QAP(l10n_ph_reports) button ===> The following error is raised: "Please select the main company and its branches in the company selector to proceed." This is because the tax report's options only consider one of the two companies (because they have different VAT numbers). The button is not declared as branch_allowed, so when clicked, it checks whether all the companies of the branch hierarchy are in the options => they're not => error. We can fix this by simply making the buttons branch_allowed. Followup on: https://github.com/odoo/enterprise/commit/34ba0609e984496f0dcc862f0d7a46c6721beab9 task-5416330 Forward-Port-Of: odoo/enterprise#105961
This update fixes the XML templates used for Dutch SBR and ICP reports to align with the latest 2026 version of the Dutch taxonomy. This ensures accurate reporting for our Dutch clients, complying with local tax regulations and improving data consistency.
Original PR description
Fix the xml SBR and SBR ICP file template for the 2026 version of dutch taxonomy Documentation: https://www.sbr-nl.nl/werken-met-sbr/taxonomie/documentatie-nederlandse-taxonomie task-5974129
This update resolves a build error in the Odoo Enterprise payroll accounting module. The previous test incorrectly counted employees triggering warnings, leading to inaccurate results. The fix now accurately checks for the presence of invalid employee IDs within the warning data, ensuring correct payroll calculations.
Original PR description
> To be FW'ed till `saas~19.1` only. issue: - the test written in commit 0653104 checks the employees' count in warning from `warning_data` dictionary - which will not work in case of multiple employees fulfilling that warning as the warning searches models' data, instead of just test data. fix: - instead of relying on `warning_data['count']` for invalid employee, checked how many times does the invalid employee's ID appear in the `warning_data`. runbot-240910 task-5958862 Forward-Port-Of: odoo/enterprise#108242
This update ensures that opening notes are consistently saved in the Point of Sale session, regardless of whether the cash payment method is enabled. Previously, notes weren't stored when the cash method wasn't configured, leading to potential data loss. This change improves the reliability of POS note-taking functionality.
Original PR description
Before this commit: -------------- - When the cash method was not available for config, opening notes values were not being stored in session data. After this commit: -------------- - Opening notes values will be stored in session data even when the cash method is not available for config. task-5474822 Forward-Port-Of: odoo/odoo#249953 Forward-Port-Of: odoo/odoo#243956
This update fixes an issue where the 'Packages' report combined multiple package details into a single, unreadable page. Now, each package is printed on a separate page, allowing for clear identification and reducing the risk of errors during packing and shipping. This improves operational efficiency and accuracy.
Original PR description
Issue before this PR: ========================= - Currently, when printing a `Packages` report that contains `multiple packages` all `Package with Content` reports are printed as a `single continuous…
Issue before this PR: ========================= - Currently, when printing a `Packages` report that contains `multiple packages` all `Package with Content` reports are printed as a `single continuous document` without any line or page separation between packages. - This leads to issues because each `Package with Content` report is meant to be printed individually and physically attached to its corresponding package during packing and logistics operations. It creates `confusion and a risk of mislabeling`, as users must `manually interpret and separate package boundaries` when handling printed documents. Steps to Reproduce: ========================= 1. Install the `Inventory` app. 2. Go to Configuration → Settings and enable the `Packages` option. 3. Create a new transfer with multiple product lines and click `Mark as Todo`. 4. In Detailed Operations, assign `different packages` to at least two different product lines and `Validate` the transfer. 5. Open the `Actions` menu, select `Print → Packages`. 6. Open the generated PDF. All packages are printed on the same page, without any page or line separation. **Packages report before this PR:** <img width="500" height="300" alt="combined" src="https://github.com/user-attachments/assets/6a6b8cb5-bcf3-488e-b95a-7670db8fc6ad" /> Cause of the issue:- ========================= In the file `report_package_barcode.xml`, a `t-foreach` loop is used to iterate over the packages included in the report. However, the report template does not define any `page break or visual separation` between iterations. As a result, each package is rendered consecutively in a single, continuous page instead of being split into separate pages. After this PR:- ========================= This PR ensures that, when printing a `Packages` report containing `multiple packages`, each `Package with Content` starts on a new page. This clear separation allows users to easily identify and handle `individual package details`, reducing confusion and the risk of mislabeling, while preserving the existing report layout and content. **Packages report after this PR:** <img width="491" height="500" alt="breaked (1)" src="https://github.com/user-attachments/assets/d87a52e5-8b54-49d4-911a-2e07e487c0d8" /> TaskID-5025192 Forward-Port-Of: odoo/odoo#241762
This update resolves an issue where products weren't automatically marked as 'published' on the website when assigned to a category. The fix ensures that the product's website visibility is correctly updated during the category assignment process, preventing products from being hidden.
Original PR description
Error: AssertionError: False is not true self.assertTrue(product.website_published) Cause: Commit https://github.com/odoo/odoo/commit/ca198cfc7c41a8c15b2734518016007aa1c16457 relies on _onchange_public_categ_ids to set website_published=True when a category is assigned. Two issues: 1. website_published was not in the dialog form view, so its onchange value was never tracked or sent to the server on save. 2. The tour clicks Save before the onchange response is received, so the product is saved without website_published=True. Fix: - Add website_published as an invisible field in the dialog form view so its value is tracked and sent on save. - Wait for the category badge to appear before submitting, ensuring the onchange has completed before save. runbot-237976 Forward-Port-Of: odoo/odoo#250596 Forward-Port-Of: odoo/odoo#249027
This update fixes an issue where social security numbers were incorrectly displayed across different company versions in the payroll module. The change restricts SSN visibility to only appear within the relevant country's company records, ensuring data privacy and compliance. This improves the accuracy and security of employee data.
Original PR description
[FIX] l10n_hr_payroll: limit l10n_xx_ssn to appear only in xx companies Bug reproduction: Select version >= saas-19.2 -> select your company -> payroll->employee->personal->you will see social security number even though that can belong to SA, MX, EG. Bug cause: added ssn fields are not restricted to their own l18n, then they are appearing in each employee form views. Bug solution: add country restrictions for MX, EG, SA to not appear in other country's company. task - 5974006
This update fixes an issue where input fields weren't resizing correctly in Safari and Firefox, leading to overflow. The fix dynamically calculates input widths, eliminating the need for browser-specific workarounds and ensuring consistent sizing across all supported browsers. This improves the user experience and prevents visual errors.
Original PR description
Before this PR, `autoresizeInput` used a fixed buffer of `5px` to compensate for input borders. This caused incorrect sizing when inputs had thicker borders, leading to overflow issues. Safari 16 and…
Before this PR, `autoresizeInput` used a fixed buffer of `5px` to compensate for input borders. This caused incorrect sizing when inputs had thicker borders, leading to overflow issues. Safari 16 and earlier versions did not include padding and border in `scrollWidth`. To work around this, browser detection via regex was used to add a hardcoded extra value. A similar issue appeared in Firefox 145, where scrollWidth also excluded padding and border, causing inputs to overflow again. After this PR, The buffer is no longer hardcoded. The border width is now calculated dynamically and applied correctly to the final width. Browser sniffing has been removed entirely. Instead, the logic detects at runtime whether scrollWidth includes padding; if not, the missing padding is added to the computed width. This makes the behavior consistent across browsers and prevents overflow without relying on user agent checks. task-[5412025](https://www.odoo.com/odoo/project/1519/tasks/5412025) Forward-Port-Of: odoo/odoo#250723 Forward-Port-Of: odoo/odoo#241315
This update resolves a potential data corruption issue that occurred when OCR processed CVs. Specifically, incorrect contact information was being written to applicant records and linked partners, particularly when CVs were forwarded or linked to existing company contacts. The fix adds safeguards to prevent this overwriting and maintain accurate data.
Original PR description
When OCR processes a CV, it writes extracted name/email/phone onto the applicant, which then propagates to the linked res.partner via the email_from inverse. This causes data corruption in two cases: - The CV was forwarded: the OCR email belongs to the candidate but email_from is the forwarder's address. Writing OCR data would overwrite the forwarder's partner with the candidate's details. - The existing partner is a company contact (parent_id set) or is linked to a user account (user_ids set). Writing OCR data would overwrite user/business partner with the candidate's details. Both guards are applied and added tests that check the flows. task-5949635 Forward-Port-Of: odoo/enterprise#108128
This update fixes an issue where rental accessories added from the cart's suggested products were failing due to mismatched rental periods. Now, the accessory's rental period matches the existing cart's period, ensuring accessories are correctly added to the cart and preventing errors. This improves the user experience for rental product purchases.
Original PR description
Why this commit --- When adding a rental accessory product from the cart page suggested products, the…
Why this commit --- When adding a rental accessory product from the cart page suggested products, the [add_to_cart](https://github.com/odoo/enterprise/blob/19.0/website_sale_renting/controllers/cart.py#L52-L58) was triggered without the rental start and end dates(None was taken by default). As a result, the system uses [default rental duration](https://github.com/odoo/enterprise/blob/19.0/website_sale_renting/models/sale_order.py#L95-L99) for comparison and considers the accessory as having a different rental period then on the sale order and raised an error preventing it from being added to the cart. This issue did not occur when adding the same product from its product page, as the rental context was correctly provided there. After this Commit --- The rental start and end dates from the current sale order are passed when adding accessory products from the cart page suggested products. This ensures that rental period consistency checks succeed and the accessory can be added without raising an invalid operation error. Steps to Reproduce --- 1. Create two rental products A and B. 2. Configure product B as an accessory of product A. 3. Add product A to the cart with any rental period(except default). 4. From the cart page, attempt to add product B from suggested products. 5.Observe the error about mixing different rental periods. Here is the video demonstrating on how the error is reproduced : https://github.com/user-attachments/assets/3d5e6f96-cebd-4221-8592-1bdb6ae40ec7 Expected Result The accessory product is added to the cart using the same rental period as the existing cart's rental period. OPW: 5823691 Forward-Port-Of: odoo/enterprise#107343 Forward-Port-Of: odoo/enterprise#106426
This update prevents archived subtasks from being duplicated when a parent task is copied. Previously, duplicated tasks incorrectly included inactive subtasks, leading to confusion and potential data inconsistencies. This change ensures that duplicated tasks only contain active subtasks, improving data accuracy and usability.
Original PR description
Currently, when duplicating a task that contains `archived subtasks`, the archived subtasks are also duplicated. **Steps to reproduce:** - Install the `project` module. - Open any `project` and create a task with a subtask. - `Archive` the subtask. - `Duplicate` the parent task. **Observation:** The duplicated task contains a copy of the archived subtask, even though it is inactive. **Root Cause:** At [1], subtasks are duplicated without checking their active status. As a result, archived (`active=False`) subtasks are also copied during duplication. **Fix:** This commit ensures that archived subtasks are not copied when duplicating a task. [1]: https://github.com/odoo/odoo/blob/531b887aec92c2fbf57495992be9fbc32d9ea20e/addons/project/models/project_task.py#L822 opw-5926009 Forward-Port-Of: odoo/odoo#250901 Forward-Port-Of: odoo/odoo#248167
This update enhances how Odoo recognizes structured bank transactions from Belgium (BE). Previously, transactions without a specific prefix (+ or *) weren't correctly identified. Now, Odoo can properly process transactions formatted as xxx/xxxx/xxxxx, ensuring accurate financial record keeping.
Original PR description
The aim of this commit is handling the case where the Belgian VCS-OGM is not starting with + or *. Before this commit, transactions without one of these 2 characters wasn't marked as structured. With this commit, we do handle this format as well: xxx/xxxx/xxxxx task-5403947 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250665
This update ensures that all chat windows display a subtitle for the agent, regardless of whether the agent's description is set. Previously, the subtitle was blank, which has now been corrected by adding a default message. This improves the user experience and consistency of the chat interface.
Original PR description
The chat subtitle is false, if the agent description is not set. This commit fixes the issues by adding a default message if subtitle is missing. Task-5916227 Forward-Port-Of: odoo/enterprise#106949
This update fixes an issue where payment advice reports weren't properly handling employees with multiple bank accounts. The team verified all bank accounts and BIC codes, ensuring that reports are now generated accurately, even when using secondary bank accounts with invalid information. This prevents reporting errors and ensures accurate financial data.
Original PR description
steps to reproduce: - install `l10n_in_hr_payroll` - create an employee, with multiple bank accounts - add invalid BIC in one of the bank accounts with isn't primary - notice that you will still be able create the advice report with invalid data. issue: - after the support of multiple bank accounts, the payment advice methods were not adapted with it. fix: - checked all the banks and their BIC. task-5890497 Forward-Port-Of: odoo/enterprise#107283
This update resolves an issue where action buttons on the work entry Gantt view would cause errors when no employees were assigned to selected entries. The fix now intelligently hides these buttons when there are no employees, preventing unexpected errors and improving the user experience.
Original PR description
On gantt view of work entries when user multi-selects entries, action buttons appears Ex. Set, Reset etc. When their are no employees in the column, on clicking these action buttons gives traceback. Ex:- `TypeError: Cannot read properties of undefined (reading '0')` or `KeyError: 'employee_id'` This fix will hide these buttons when there are no employees present. task-[5445718](https://www.odoo.com/odoo/project/1251/tasks/5445718) Forward-Port-Of: odoo/enterprise#108995 Forward-Port-Of: odoo/enterprise#105957
This update fixes an issue where Point of Sale orders would incorrectly display the wrong date if the PoS device had an outdated time setting. Now, orders are always created with the correct date as determined by the server, ensuring accurate order records and preventing potential discrepancies.
Original PR description
Before this commit, if the PoS device had a wrong date, the orders created while being online would have a wrong date_order. This commit prioritizes the server date for the order that is currently being processed when the PoS is online. opw-5884498 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248897
This update resolves a technical problem that was preventing users from correctly searching for products within the product catalog. The fix addressed a race condition and a broken configuration in the search panel, ensuring accurate and reliable search results. This improves the user experience and prevents potential errors.
Original PR description
- `PurchaseStockProductCatalogSearchModel._fetchSections()` was calling `super._fetchSections()` without `await`, causing `sectionsPromise` to resolve immediately before sections finished loading.…
- `PurchaseStockProductCatalogSearchModel._fetchSections()` was calling `super._fetchSections()` without `await`, causing `sectionsPromise` to resolve immediately before sections finished loading. This made `expandDefaultValue()`, `expandValues()`, and `updateActiveValues()` run with empty sections in `onWillStart`, leaving `state.expanded` and `state.active` uninitialized and causing a crash when the template accessed `state.expanded[section.id][valueId]`.
```
UncaughtPromiseError > OwlError
Uncaught Promise > An error occured in the owl lifecycle (see this Error's "cause" property)
Occured on 127.0.0.19:8069 on 2026-02-24 10:16:04 GMT
OwlError: An error occured in the owl lifecycle (see this Error's "cause" property)
Error: An error occured in the owl lifecycle (see this Error's "cause" property)
at handleError (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:762:101)
at App.handleError (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:1420:29)
at Fiber._render (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:787:19)
at Fiber.render (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:785:6)
at ComponentNode.initiateRender (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:855:47)
Caused by: TypeError: Cannot read properties of undefined (reading '1')
at PurchaseSuggestCatalogSearchPanel.template (eval at compile (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:1375:421), <anonymous>:25:69)
at App.callTemplate (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:1011:129)
at PurchaseSuggestCatalogSearchPanel.template (eval at compile (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:1375:421), <anonymous>:85:15)
at PurchaseSuggestCatalogSearchPanel.template (eval at compile (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:1375:421), <anonymous>:138:34)
at PurchaseSuggestCatalogSearchPanel.template (eval at compile (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:1375:421), <anonymous>:19:29)
at Fiber._render (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:786:96)
at Fiber.render (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:785:6)
at ComponentNode.initiateRender (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:855:47)
```
- `purchase_stock.ProductCatalogSearchPanelContent` had a broken xpath: a `<t t-if>` element inside `<xpath position="attributes">`. OWL's `modifyAttributes()` silently skips non-`<attribute>` children, so the conditional class was never applied. Replaced with a proper `t-att-class` ternary binding.
Forward-Port-Of: odoo/odoo#250810This update resolves several issues impacting the Odoo Profiler's reliability, specifically related to thread management and data handling. The fixes prevent errors that could interrupt profiling sessions and ensure consistent data collection, leading to more accurate performance insights. These improvements enhance the overall stability and usability of the profiling tool.
Original PR description
Multiple fixes for the Profiler. Issues: - Python throws cannot join current thread when using the entry count with memory and traces async profilers. - The periodic profilers were waiting the full amount of the sleep before ending. - When using the entry_count, the memory profiler was throwing a non serializable object error - Sometimes the memory collector throws an error that the tracemalloc needs to be started so that it collects. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248501 Forward-Port-Of: odoo/odoo#232551
This update ensures that employees cannot check in through the attendance app if location tracking is enabled and a location cannot be determined. This prevents inaccurate attendance records and ensures data integrity, particularly important for payroll and workforce management reporting.
Original PR description
When a user is trying to check in on the attendance app with the setting Device tracking enabled and the location cannot be determined, it should raise an error to prevent the check-in without a valid location. Task: 5486178 Forward-Port-Of: odoo/odoo#249753
This update resolves an issue related to how sick leave is tracked in Belgium, specifically when extended periods of absence occur. The change moves a targeted logic to a localized module to avoid conflicts and ensure accurate work entry type matching, improving the reliability of sick leave calculations. This addresses a previous localization problem and enhances the overall accuracy of HR data.
Original PR description
In Belgium, when more than a month of consecutive sick time of is taken, every day over the month is of a different type of work entry (sick time of without pay). This means that work entries relative to the same leave have different work entry types which was causing problems when checking the matching of the types. To fix this, a previous PR (https://github.com/odoo/odoo/pull/237829) made it so that if the internal_leaves computation returned empty, every leave was considered. Because of this some problems in the HK localization arose so we go back to the original code and we move the BE specific changes to the BE localization module. To do this, we move the logic in a function which we will override inside that module (see related Enterprise PR). Task: 5472538 Enterprise PR: https://github.com/odoo/enterprise/pull/105776 Forward-Port-Of: odoo/odoo#246116
This update corrects a problem in how Odoo handles extended sick leave in Belgium. Previously, different work entry types for consecutive sick days caused matching issues. The fix ensures accurate tracking of sick leave durations by specifically recognizing different types of sick leave, resolving a previous issue in the Hong Kong localization.
Original PR description
In Belgium, when more than a month of consecutive sick time of is taken, every day over the month is of a different type of work entry (sick time of without pay). This means that work entries relative to the same leave have different work entry types which was causing problems when checking the matching of the types. To fix this, a previous PR (https://github.com/odoo/odoo/pull/237829) made it so that if the internal_leaves computation returned empty, every leave was considered. Because of this some problems in the HK localization arose so we go back to the original code (see related Community PR) and we move the BE specific changes to the BE localization module. Here we override the check function to allow for the specific case described above, where LEAVE110 is the code for sick time off and LEAVE214 is the code for sick time of without pay. Task: 5472538 Community PR: https://github.com/odoo/odoo/pull/246116 Forward-Port-Of: odoo/enterprise#105776
20 changes
Resolved issues and error corrections
This update resolves an issue where the tax report export button wouldn't work correctly when companies had different VAT numbers and branches. The fix ensures the button recognizes and processes all companies within the branch hierarchy, allowing users to export reports accurately. This improves the functionality of the tax reporting feature.
Original PR description
To reproduce the issue: - Create a company with a branch - Give the company and its branch different VAT numbers - Make both companies active in the company selector - Open the tax report - Click on gear icon - Click on the XML(l10n_lu_reports)/Export SAWT & QAP(l10n_ph_reports) button ===> The following error is raised: "Please select the main company and its branches in the company selector to proceed." This is because the tax report's options only consider one of the two companies (because they have different VAT numbers). The button is not declared as branch_allowed, so when clicked, it checks whether all the companies of the branch hierarchy are in the options => they're not => error. We can fix this by simply making the buttons branch_allowed. Followup on: https://github.com/odoo/enterprise/commit/34ba0609e984496f0dcc862f0d7a46c6721beab9 task-5416330 Forward-Port-Of: odoo/enterprise#105961
This update resolves a build error in the payroll accounting module related to how warning tests are run. The previous test incorrectly counted employees, failing when multiple employees triggered the same warning. The fix now accurately checks for the number of times an invalid employee ID appears in the warning data, ensuring the test functions correctly.
Original PR description
> To be FW'ed till `saas~19.1` only. issue: - the test written in commit 0653104 checks the employees' count in warning from `warning_data` dictionary - which will not work in case of multiple employees fulfilling that warning as the warning searches models' data, instead of just test data. fix: - instead of relying on `warning_data['count']` for invalid employee, checked how many times does the invalid employee's ID appear in the `warning_data`. runbot-240910 task-5958862 Forward-Port-Of: odoo/enterprise#108242
This update resolves a technical error that prevented the generation of Dutch tax reports. The issue stemmed from a misunderstanding of how data was being processed, specifically related to a boolean flag within the report's data structure. This fix ensures accurate report generation for Dutch users.
Original PR description
After this [commit](https://github.com/odoo/enterprise/commit/402ec47),…
After this [commit](https://github.com/odoo/enterprise/commit/402ec47), [ec_sales_list_tag_ids](https://github.com/odoo/enterprise/blob/c6b8727b9c926a4f817249b94cfc24dcbd66147f/l10n_nl_reports/models/account_return.py#L21) is built by flattening the values of `ec_sales_list_tags_info` using `chain(*values())`.
The tag IDs are fetched from[ _get_tax_tags_for_nl_sales_report()](https://github.com/odoo/enterprise/blob/c6b8727b9c926a4f817249b94cfc24dcbd66147f/l10n_nl_reports/models/account_sales_report.py#L75), which returns a dictionary containing:
- a flag (`use_taxes_instead_of_tags = False`)
```.py
(Pdb) ec_sales_list_tags_info
{'goods': [67], 'services': [71], 'triangular': [69], 'use_taxes_instead_of_tags': False}
```
When flattening the dictionary values, `chain` expects all values to be iterable. While the boolean flag is not iterable,
which results in a `TypeError: 'bool' object is not iterable`.
```.py
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 493, in load_modules
migrations.migrate_module(package, 'end')
File "/home/odoo/src/odoo/19.0/odoo/modules/migration.py", line 220, in migrate_module
exec_script(self.cr, installed_version, pyfile, pkg.name, stage, stageformat[stage] % version)
File "/home/odoo/src/odoo/19.0/odoo/modules/migration.py", line 257, in exec_script
mod.migrate(cr, installed_version)
File "/tmp/tmpzg7oi478/migrations/account_reports/saas~18.3.1.0/end-account-returns.py", line 341, in migrate
generate_or_refresh_all_returns(company)
File "/home/odoo/src/enterprise/19.0/account_reports/models/account_return.py", line 232, in _generate_or_refresh_all_returns
self._generate_all_returns(fiscal_country.code, company, domestic_tax_unit)
File "/home/odoo/src/enterprise/19.0/l10n_nl_reports/models/account_return.py", line 22, in _generate_all_returns
ec_sales_list_tag_ids = list(chain(*ec_sales_list_tags_info.values()))
TypeError: 'bool' object is not iterable
```
In this fix, the boolean flag is removed before chaining since only tag ID lists are needed and the flag causes an error.
Forward-Port-Of: odoo/enterprise#107213This update ensures that opening notes are consistently saved to the system's session data, regardless of whether the cash payment method is enabled. Previously, this functionality was missing when the cash method wasn't configured, leading to potential data loss. This change improves the reliability of POS note recording for all users.
Original PR description
Before this commit: -------------- - When the cash method was not available for config, opening notes values were not being stored in session data. After this commit: -------------- - Opening notes values will be stored in session data even when the cash method is not available for config. task-5474822 Forward-Port-Of: odoo/odoo#249953 Forward-Port-Of: odoo/odoo#243956
This update fixes an issue where the 'Packages' report combined all package details onto a single page, causing confusion and potential mislabeling. Now, each package's information is printed on a separate page, allowing for clear and accurate handling during packing and logistics.
Original PR description
Issue before this PR: ========================= - Currently, when printing a `Packages` report that contains `multiple packages` all `Package with Content` reports are printed as a `single continuous…
Issue before this PR: ========================= - Currently, when printing a `Packages` report that contains `multiple packages` all `Package with Content` reports are printed as a `single continuous document` without any line or page separation between packages. - This leads to issues because each `Package with Content` report is meant to be printed individually and physically attached to its corresponding package during packing and logistics operations. It creates `confusion and a risk of mislabeling`, as users must `manually interpret and separate package boundaries` when handling printed documents. Steps to Reproduce: ========================= 1. Install the `Inventory` app. 2. Go to Configuration → Settings and enable the `Packages` option. 3. Create a new transfer with multiple product lines and click `Mark as Todo`. 4. In Detailed Operations, assign `different packages` to at least two different product lines and `Validate` the transfer. 5. Open the `Actions` menu, select `Print → Packages`. 6. Open the generated PDF. All packages are printed on the same page, without any page or line separation. **Packages report before this PR:** <img width="500" height="300" alt="combined" src="https://github.com/user-attachments/assets/6a6b8cb5-bcf3-488e-b95a-7670db8fc6ad" /> Cause of the issue:- ========================= In the file `report_package_barcode.xml`, a `t-foreach` loop is used to iterate over the packages included in the report. However, the report template does not define any `page break or visual separation` between iterations. As a result, each package is rendered consecutively in a single, continuous page instead of being split into separate pages. After this PR:- ========================= This PR ensures that, when printing a `Packages` report containing `multiple packages`, each `Package with Content` starts on a new page. This clear separation allows users to easily identify and handle `individual package details`, reducing confusion and the risk of mislabeling, while preserving the existing report layout and content. **Packages report after this PR:** <img width="491" height="500" alt="breaked (1)" src="https://github.com/user-attachments/assets/d87a52e5-8b54-49d4-911a-2e07e487c0d8" /> TaskID-5025192 Forward-Port-Of: odoo/odoo#241762
This update corrects a bug where archived subtasks were unintentionally copied when duplicating a task. Previously, the system didn't check if a subtask was inactive before duplication, leading to unnecessary data duplication. Now, archived subtasks are excluded from the duplication process, streamlining task management.
Original PR description
Currently, when duplicating a task that contains `archived subtasks`, the archived subtasks are also duplicated. **Steps to reproduce:** - Install the `project` module. - Open any `project` and create a task with a subtask. - `Archive` the subtask. - `Duplicate` the parent task. **Observation:** The duplicated task contains a copy of the archived subtask, even though it is inactive. **Root Cause:** At [1], subtasks are duplicated without checking their active status. As a result, archived (`active=False`) subtasks are also copied during duplication. **Fix:** This commit ensures that archived subtasks are not copied when duplicating a task. [1]: https://github.com/odoo/odoo/blob/531b887aec92c2fbf57495992be9fbc32d9ea20e/addons/project/models/project_task.py#L822 opw-5926009 Forward-Port-Of: odoo/odoo#250901 Forward-Port-Of: odoo/odoo#248167
This update fixes an issue where payment advice reports weren't properly handling employees with multiple bank accounts. The fix ensures that invalid bank information (BICs) in non-primary accounts no longer allows the creation of incorrect payment advice reports, improving data accuracy and compliance.
Original PR description
steps to reproduce: - install `l10n_in_hr_payroll` - create an employee, with multiple bank accounts - add invalid BIC in one of the bank accounts with isn't primary - notice that you will still be able create the advice report with invalid data. issue: - after the support of multiple bank accounts, the payment advice methods were not adapted with it. fix: - checked all the banks and their BIC. task-5890497 Forward-Port-Of: odoo/enterprise#107283
This update fixes an issue where input fields would overflow due to inconsistent sizing calculations across different browsers, particularly Safari and Firefox. The change dynamically adjusts for padding and borders, ensuring correct sizing and preventing visual glitches for users.
Original PR description
Before this PR, `autoresizeInput` used a fixed buffer of `5px` to compensate for input borders. This caused incorrect sizing when inputs had thicker borders, leading to overflow issues. Safari 16 and…
Before this PR, `autoresizeInput` used a fixed buffer of `5px` to compensate for input borders. This caused incorrect sizing when inputs had thicker borders, leading to overflow issues. Safari 16 and earlier versions did not include padding and border in `scrollWidth`. To work around this, browser detection via regex was used to add a hardcoded extra value. A similar issue appeared in Firefox 145, where scrollWidth also excluded padding and border, causing inputs to overflow again. After this PR, The buffer is no longer hardcoded. The border width is now calculated dynamically and applied correctly to the final width. Browser sniffing has been removed entirely. Instead, the logic detects at runtime whether scrollWidth includes padding; if not, the missing padding is added to the computed width. This makes the behavior consistent across browsers and prevents overflow without relying on user agent checks. task-[5412025](https://www.odoo.com/odoo/project/1519/tasks/5412025) Forward-Port-Of: odoo/odoo#250723 Forward-Port-Of: odoo/odoo#241315
This update prevents incorrect data from being written to applicant records when CVs are processed via OCR. Specifically, it corrects data corruption that occurred when forwarding emails or linking applicants to existing business partners. This ensures accurate applicant information within the system.
Original PR description
When OCR processes a CV, it writes extracted name/email/phone onto the applicant, which then propagates to the linked res.partner via the email_from inverse. This causes data corruption in two cases: - The CV was forwarded: the OCR email belongs to the candidate but email_from is the forwarder's address. Writing OCR data would overwrite the forwarder's partner with the candidate's details. - The existing partner is a company contact (parent_id set) or is linked to a user account (user_ids set). Writing OCR data would overwrite user/business partner with the candidate's details. Both guards are applied and added tests that check the flows. task-5949635 Forward-Port-Of: odoo/enterprise#108128
This update resolves a bug where image sizes were being unintentionally reduced during rotation within the HTML editor. The fix ensures that padding around images is correctly accounted for, maintaining the intended image size and appearance. This improves the user experience when working with images in website content.
Original PR description
**Current behavior before PR:** Steps to reproduce: - In website, drag and drop a `text - image` snippet. - Click on image, click on Transform button. - Try to rotate the image. - You will notice that the size of the image is reduced a bit. This issue happens because in `image_transformation.js`, `convertPixelWidthToPercentage` converts image width from `px` to percentage. In this case image's parentElement has padding, causing reduction in image's size. **Desired behavior after PR is merged:** This PR ensures that `paddingLeft` and `paddingRight` of image's parentElement is ignored from calculation so that image size doesn't get changed. task-5884679 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246508
This update enhances how Odoo recognizes structured bank transactions from Belgium (VCS-OGM). Previously, transactions without a leading '+' or '*' were not correctly identified as structured. Now, Odoo can properly process transactions formatted as 'xxx/xxxx/xxxxx', ensuring accurate financial reporting and record-keeping.
Original PR description
The aim of this commit is handling the case where the Belgian VCS-OGM is not starting with + or *. Before this commit, transactions without one of these 2 characters wasn't marked as structured. With this commit, we do handle this format as well: xxx/xxxx/xxxxx task-5403947 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250665
This update addresses several technical issues within the Hoot component of Odoo, enhancing its reliability and performance. Specifically, it corrects a problem with how blob responses are handled, resolves an issue with test results, and limits a potentially problematic configuration option. These changes ensure smoother operation and data integrity.
Original PR description
### [FIX] web: Hoot - backport fixes This commit backports the following fixes that have been applied in further versions: - add correct mime type to XHR blob responses [1]; - fix missing diff from failed test results [2]; - wrap 'raw' value option in a dictionnary to limit unintended use, use 'raw' as a default for text-based matchers [3]. [1] 9156bf1 [2] 2216a0b [3] 3080362 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250929
This update resolves an issue where action buttons on the work entry Gantt view would cause errors when no employees were assigned. The fix now automatically hides these buttons when there are no employees present, preventing unexpected errors and improving the user experience.
Original PR description
On gantt view of work entries when user multi-selects entries, action buttons appears Ex. Set, Reset etc. When their are no employees in the column, on clicking these action buttons gives traceback. Ex:- `TypeError: Cannot read properties of undefined (reading '0')` or `KeyError: 'employee_id'` This fix will hide these buttons when there are no employees present. task-[5445718](https://www.odoo.com/odoo/project/1251/tasks/5445718) Forward-Port-Of: odoo/enterprise#105957
This update corrects a minor issue in the Attendance module where duplicate field names were appearing in the attendance list view. Specifically, the 'in_location' and 'out_location' fields had redundant names. This change ensures a cleaner and more user-friendly experience when managing attendance data.
Original PR description
Steps to reproduce: -------------------------------------- 1. Install the Attendance module 2. Go to the attendance list view 3. Click on the optional fields tray Observation: -------------------------------------- Duplicate field name Longitude (In) Issue: -------------------------------------- For the `in_location` field, a duplicate string was added in the list view Solution: -------------------------------------- Changed string to `Location (In)` for `in_location` field and changed string to `Location (Out)` for `out_location` field Before: <img width="348" height="511" alt="image" src="https://github.com/user-attachments/assets/109ff380-df4f-4dc6-ad01-a955d85436c7" /> After: <img width="330" height="503" alt="image" src="https://github.com/user-attachments/assets/894e6045-ec34-4296-8aff-f0e7bee32d9f" /> opw-5909500 Forward-Port-Of: odoo/odoo#249404
This update ensures that Point of Sale orders always use the correct date from the server, regardless of the date displayed on the POS device. Previously, incorrect date settings on the POS could lead to inaccurate order timestamps. This change improves data accuracy and reliability for all Point of Sale transactions.
Original PR description
Before this commit, if the PoS device had a wrong date, the orders created while being online would have a wrong date_order. This commit prioritizes the server date for the order that is currently being processed when the PoS is online. opw-5884498 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248897
This update resolves a technical glitch in the product catalog search panel that was causing the system to crash. The fix addressed a race condition in how data was loaded, preventing errors when users searched for products. This ensures the search functionality operates reliably.
Original PR description
- `PurchaseStockProductCatalogSearchModel._fetchSections()` was calling `super._fetchSections()` without `await`, causing `sectionsPromise` to resolve immediately before sections finished loading.…
- `PurchaseStockProductCatalogSearchModel._fetchSections()` was calling `super._fetchSections()` without `await`, causing `sectionsPromise` to resolve immediately before sections finished loading. This made `expandDefaultValue()`, `expandValues()`, and `updateActiveValues()` run with empty sections in `onWillStart`, leaving `state.expanded` and `state.active` uninitialized and causing a crash when the template accessed `state.expanded[section.id][valueId]`.
```
UncaughtPromiseError > OwlError
Uncaught Promise > An error occured in the owl lifecycle (see this Error's "cause" property)
Occured on 127.0.0.19:8069 on 2026-02-24 10:16:04 GMT
OwlError: An error occured in the owl lifecycle (see this Error's "cause" property)
Error: An error occured in the owl lifecycle (see this Error's "cause" property)
at handleError (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:762:101)
at App.handleError (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:1420:29)
at Fiber._render (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:787:19)
at Fiber.render (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:785:6)
at ComponentNode.initiateRender (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:855:47)
Caused by: TypeError: Cannot read properties of undefined (reading '1')
at PurchaseSuggestCatalogSearchPanel.template (eval at compile (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:1375:421), <anonymous>:25:69)
at App.callTemplate (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:1011:129)
at PurchaseSuggestCatalogSearchPanel.template (eval at compile (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:1375:421), <anonymous>:85:15)
at PurchaseSuggestCatalogSearchPanel.template (eval at compile (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:1375:421), <anonymous>:138:34)
at PurchaseSuggestCatalogSearchPanel.template (eval at compile (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:1375:421), <anonymous>:19:29)
at Fiber._render (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:786:96)
at Fiber.render (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:785:6)
at ComponentNode.initiateRender (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:855:47)
```
- `purchase_stock.ProductCatalogSearchPanelContent` had a broken xpath: a `<t t-if>` element inside `<xpath position="attributes">`. OWL's `modifyAttributes()` silently skips non-`<attribute>` children, so the conditional class was never applied. Replaced with a proper `t-att-class` ternary binding.
Forward-Port-Of: odoo/odoo#250810This update prevents employees from checking in through the attendance app when location tracking is enabled and a location cannot be determined. This ensures accurate attendance records and avoids incorrect check-in data, improving the reliability of our time tracking system.
Original PR description
When a user is trying to check in on the attendance app with the setting Device tracking enabled and the location cannot be determined, it should raise an error to prevent the check-in without a valid location. Task: 5486178 Forward-Port-Of: odoo/odoo#249753
This update resolves a potential issue during Odoo database upgrades. Previously, removing a payroll rule could cause upgrade scripts to fail. This change ensures upgrade scripts continue to function correctly even if a referenced rule has been deleted, improving the reliability of database updates.
Original PR description
This method is used in various places, including when upgrading a database. When doing so, it is done in a post upgrade script. If later one of the updated rules is removed, the pre-script removing it will run before the post script trying to update it, causing the migration to fail as the update method tries to browse a falsy value. This updates the `update_properties_definition_domain` method so that it ignores falsy values when browsing, allowing previous upgrade scripts to run even if the referred rule has been since deleted. Forward-Port-Of: odoo/enterprise#102964
This update fixes a critical error in the calculation of employer costs for Swiss payroll. Previously, employer costs were incorrectly displayed as zero due to a missing flag. The update now accurately computes and displays these costs, ensuring accurate financial reporting and compliance for Swiss businesses using Odoo Enterprise.
Original PR description
The computation of the employer cost in Switzerland was wrong (always 0) because the rules didn't have the appears_on_employee_cost_dashboard flag set and were therefore not counted in the computation of the fiels. Furthermore we modify the override of the function used to compute the values of some fields, to add the correct computation of the employer cost. Task: 5354103 Forward-Port-Of: odoo/enterprise#106839
This update fixes a technical error preventing managers without specific permissions from scheduling meetings related to appraisals. The fix replaces a restricted data field with a simpler one, ensuring managers can now correctly schedule meetings as intended. This improves the user experience for all managers.
Original PR description
Steps to reproduce: - Create two employees: one as a manager and the other as a subordinate. - Ensure that the manager does not have any officer or appraisal rights. - Create an appraisal for the subordinate through the manager. - Confirm the appraisal and then click the Schedule Meeting button Issue: - The manager should schedule a meeting even though he does not have the rights, but a traceback error occurs due to access rights issues when trying to schedule a meeting. Reason: - The manager is unable to access the related_partner_id due to restrictions set by the officer/manager group, which results in a traceback error. Fix: - Replace the related_partner_id with the work_contact_id of the employee. Since related_partner_id is computed from work_contact_id, we can directly use work_contact_id task-5881127 Forward-Port-Of: odoo/enterprise#106106
3 changes
Resolved issues and error corrections
This update fixes the XML templates used for Dutch SBR and ICP reports to align with the latest 2026 version of the Dutch taxonomy. This ensures accurate reporting for our Dutch clients, complying with local tax regulations and improving data consistency.
Original PR description
Fix the xml SBR and SBR ICP file template for the 2026 version of dutch taxonomy Documentation: https://www.sbr-nl.nl/werken-met-sbr/taxonomie/documentatie-nederlandse-taxonomie task-5974129
This update fixes an error in the Spanish Profit & Loss reports where specific accounts (7950 and 7957) were incorrectly placed in section 10. The change aligns with official Spanish tax documentation, ensuring accurate reporting for non-SME fiscal localization packages. This ensures compliance with Spanish tax regulations.
Original PR description
In the Profit & Loss reports, accounts 7950 and 7957 were incorrectly shown in section 10 instead of section 6 These accounts appear only for non-SME fiscal localization packages According to the official Spanish tax documentation, these accounts should belong to section 6 and not section 10: https://www.boe.es/buscar/act.php?id=BOE-A-2007-19884 opw-5363664 Forward-Port-Of: odoo/enterprise#108575 Forward-Port-Of: odoo/enterprise#107949
This update fixes an issue where newly hired employees were incorrectly receiving their private email address as their work email. The fix clears the employee's work_email field during the contract signing process, ensuring it reflects the intended work email. This prevents data inconsistencies and improves the accuracy of employee records.
Original PR description
**Steps to Reproduce:** 1. Send an offer to an applicant. 2. The applicant submits their details via the salary configurator and enters their private email in the Email field. 3. Once the offer and contract are signed, an employee record is created in Odoo. 4. In the created employee record, the `work_email` field is populated with the email entered in the salary configurator. This same value is also present in `private_email`, which is correct. **Reason:** - The email entered in the salary configurator is stored on the partner and represents the applicant's private email. - The employee's `work_email` field is linked to the partner's email via compute and inverse methods, causing it to inherit the private email value when the employee record is created. **Solution:** - Explicitly clear the employee's work_email field when the applicant sign. task: 5502797 Forward-Port-Of: odoo/enterprise#108769 Forward-Port-Of: odoo/enterprise#106974
22 changes
Resolved issues and error corrections
This update addresses minor technical issues within the Odoo web framework (Hoot) to improve stability and reliability. Specifically, it corrects a problem with how data is transmitted, fixes a reporting issue with test results, and restricts a potentially problematic feature. These changes ensure smoother operation and prevent unexpected errors.
Original PR description
### [FIX] web: Hoot - backport fixes This commit backports the following fixes that have been applied in further versions: - add correct mime type to XHR blob responses [1]; - fix missing diff from failed test results [2]; - wrap 'raw' value option in a dictionnary to limit unintended use, use 'raw' as a default for text-based matchers [3]. [1] 9156bf1 [2] 2216a0b [3] 3080362 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects the XML templates used for Dutch SBR and ICP tax reports to align with the latest 2026 version of the Dutch taxonomy. This ensures accurate reporting for our Dutch customers, complying with local regulations and improving the reliability of financial data.
Original PR description
Fix the xml SBR and SBR ICP file template for the 2026 version of dutch taxonomy Documentation: https://www.sbr-nl.nl/werken-met-sbr/taxonomie/documentatie-nederlandse-taxonomie task-5974129
This update fixes an issue where a POS order could incorrectly apply a pricelist even if it wasn't the customer's standard pricelist. This occurred when the order was linked to a previously paid order. The change ensures that only valid, available pricelists are applied to POS orders, improving order accuracy and preventing potential pricing errors.
Original PR description
When changing the customer on a POS order, if the customer's pricelist is not in the list of available pricelists for the POS, but the pricelist was loaded due to loading a paid order, the POS would still set that pricelist on the order. opw-5461556 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248365 Forward-Port-Of: odoo/odoo#247029
This update fixes an issue with invoices generated for SII (Chile's tax authority) by ensuring the correct XML tags are used for withholding information. The change updates specific template elements to align with SII's invoice format requirements, preventing potential errors during invoice confirmation. This ensures compliance with Chilean tax regulations.
Original PR description
Link to SII API Documentation: https://www.sii.cl/factura_electronica/formato_dte.pdf Problem: The DTE template was using incorrect XML elements for withholdings when confirming an invoice with SII. This fix replaces: ImptRetOtrMnda -> ImpRetOtrMnda ValorImpOtrMnda -> VlrImpOtrMnda so the generated DTE matches SII specifications. OPW-5437484 Forward-Port-Of: odoo/enterprise#105152
This update fixes an issue where Odoo incorrectly displayed records after a user switched companies. Previously, the system didn't immediately update the URL needed for the correct record view, leading to incorrect displays. Now, the system reliably directs users to the correct record after a company change, ensuring a smoother user experience.
Original PR description
Have a flow where an action act_window is executed and wants to open a record in the form view, but that record is not in one of the companies that the current user is logged in. The ORM will crash with an access denied, that the JS catches cleverly (see odoo/odoo@6213c40932236101b529b82f0ea9fce1829c8c24) and tries to reload on that failed action after altering the allowed companies. Before this commit, this flow was imperfect because the url (that allows to reload at the right place) was not written immediately. So, more often than not, we ended up on the wrong view after reload. After this commit, we end up in the right action after reload. 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#250401
This update corrects a bug that caused time off reports to incorrectly open as allocation records. The issue stemmed from a misalignment in the database query used to generate the reports, leading to incorrect record identification. This fix ensures that time off requests are now correctly displayed and opened within the intended time off reporting interface.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249015
This update fixes a confusing error message users received when attempting to generate leads without sufficient credits. The system now correctly handles the scenario where credits are unavailable, providing a clearer message and preventing users from needing to manually adjust filters. This improves the user experience and ensures smooth lead generation.
Original PR description
Before this commit, when the user uses CRM to generate new leads and does not have credits, the error message they would get is "Your request did not return any result (no credits were used). Try removing some filters." This commit fixes this in _perform_request by instead of expecting InsufficientCreditError raised it now expects the credit_error flag to be set. task-5925047 Forward-Port-Of: odoo/odoo#250433
This update corrects a technical issue preventing invoices sent via Peppol from passing validation. The system was incorrectly using 'UNSPSC' instead of the required 'TST' code for commodity classifications. This change ensures compliance with Peppol standards and allows invoices to be successfully transmitted.
Original PR description
**Steps to reproduce:** * Install the **product_unspsc** module. * Create a product with a **UNSPSC category**. * Create and post an invoice for this product. * Send the invoice via **Peppol**.…
**Steps to reproduce:** * Install the **product_unspsc** module. * Create a product with a **UNSPSC category**. * Create and post an invoice for this product. * Send the invoice via **Peppol**. **Observed behavior:** * Peppol validation fails with error **[BR-CL-13]**: *“Item classification identifier identification scheme identifier MUST be coded using one of the UNTDID 7143 list.”* * The XML uses `listID='UNSPSC'` in `cbc:ItemClassificationCode`. **Cause:** * The `listID` attribute was set to the literal string **'UNSPSC'**. * According to the **UNCL7143** code list, the correct scheme identifier for UNSPSC is **'TST'**, not 'UNSPSC'. **Fix:** * Replace `listID='UNSPSC'` with `listID='TST'` when generating the commodity classification node. * Update and extend tests to validate the correct scheme identifier. * Same for CPV code from the documentation i's code is also changed to 'STI'. ref: https://docs.peppol.eu/poacc/billing/3.0/codelist/UNCL7143/ opw-5948723 Forward-Port-Of: odoo/odoo#249788
This update fixes an issue where the VAT Book download was only generating for the primary company, even when related branches (with the same CUIT) were selected. Now, when multiple companies with the same CUIT are chosen, the VAT Book download will include data for all of them, ensuring accurate reporting for businesses with multiple branches.
Original PR description
#### Issues: VAT Book should download for all selected companies with same CUIT as the current one. #### Step to reproduce: - In a company in Argentina ("Parent Company") - Create a branch "Child…
#### Issues:
VAT Book should download for all selected companies with same CUIT as the current one.
#### Step to reproduce:
- In a company in Argentina ("Parent Company")
- Create a branch "Child Company A" with no CUID
- Create a branch "Child Company B" with a different CUID than parent
- Go to "Child Company A"
- Either:
- i. Select both "Parent Company" and "Child Company A" but not "Child Company B"
- ii. Select all 3 "Parent Company", "Child Company A" and "Child Company B"
- In Accounting > Report > Tax Return :
- Download the VAT Book (wheel > "VAT book(ZIP)")
#### Current behavior:
i. Get Invalid Operation
ii. Download the VAT Book for "Parent Company" only
#### Expected behavior:
- Download the VAT Book for both "Parent Company" and "Child Company A"
A previous call to get_options provide the client with the info about which selected companies have the same CUIT as the current company. Therefore companies in the options are the correct ones.
opw-5385585
Forward-Port-Of: odoo/enterprise#101898This update fixes an issue where table menu buttons were not visible or positioned correctly within the HTML editor. The change ensures the table menu functions as expected, providing a better user experience for creating and editing tables. It addresses a technical configuration problem within the HTML editor's internal workings.
Original PR description
Description of the issue: Commit [1] replaces `overlay` with `localOverlay` for the table menu. However, studio uses its own `wysiwyg` instance and config, which does not define `localOverlayContainers`, causing a traceback when `table_menu` accesses `this.config.localOverlayContainers.key`. Solution: - Define `localOverlayContainers` and its corresponding key in studio’s `wysiwyg` config. - Additionally, adjust the table menu position calculation when the table cell is inside an iframe. ENT PR: https://github.com/odoo/enterprise/pull/108874 [1]: https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec Forward-Port-Of: odoo/odoo#250645
This update resolves an issue preventing power buttons from appearing in Odoo Studio reports. The fix defines a key configuration within Studio's editor, ensuring proper functionality and addressing a previous bug related to missing overlay definitions. This enhances the user experience within the Studio report editor.
Original PR description
Description of the issue: Commit [1] replaces `overlay` with `localOverlay` for the table menu. However, studio uses its own `wysiwyg` instance and config, which does not define `localOverlayContainers`, causing a traceback when `table_menu` accesses `this.config.localOverlayContainers.key`. Solution: - Define `localOverlayContainers` and its corresponding key in studio’s `wysiwyg` config. - Additionally, adjust the table menu position calculation when the table cell is inside an iframe. - Also Before `localOverlayContainers` was not defined in studio, so power buttons did not appear in studio reports. Now that `localOverlayContainers` is defined, power buttons must be excluded from the main plugin to prevent them from appearing inside studio. Community PR: https://github.com/odoo/odoo/pull/250889 [1]: https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec Forward-Port-Of: odoo/enterprise#108724
This update resolves a technical issue where certain attributes weren't being properly set on model classes, leading to slower tests and occasional failures. Fixing this improves the stability and reliability of our test suite, ensuring smoother development and deployment of new features. This primarily impacts the chart_template area.
Original PR description
Followup / fixup to #249005, as these can / do cause trouble due to overlogging (mostly the chart_template one). Forward-Port-Of: odoo/odoo#250575
This update prevents archived subtasks from being duplicated when a parent task is copied. Previously, duplicated tasks incorrectly included inactive subtasks, leading to unnecessary clutter. This change ensures a cleaner and more efficient task management experience.
Original PR description
Currently, when duplicating a task that contains `archived subtasks`, the archived subtasks are also duplicated. **Steps to reproduce:** - Install the `project` module. - Open any `project` and create a task with a subtask. - `Archive` the subtask. - `Duplicate` the parent task. **Observation:** The duplicated task contains a copy of the archived subtask, even though it is inactive. **Root Cause:** At [1], subtasks are duplicated without checking their active status. As a result, archived (`active=False`) subtasks are also copied during duplication. **Fix:** This commit ensures that archived subtasks are not copied when duplicating a task. [1]: https://github.com/odoo/odoo/blob/531b887aec92c2fbf57495992be9fbc32d9ea20e/addons/project/models/project_task.py#L822 opw-5926009 Forward-Port-Of: odoo/odoo#250738 Forward-Port-Of: odoo/odoo#248167
This update fixes a bug where multiple physical gift cards added to a single Point of Sale (PoS) order were not being created in the backend. The issue stemmed from a misinterpretation of data keys, leading to incorrect gift card counts. This ensures all gift cards are properly recorded, improving order accuracy and preventing revenue loss.
Original PR description
When selling mutliple physical gift cards in the same PoS order, no gift cards were created. Steps to reproduce: ------------------- * Open PoS * Add a gift card to the order * Click on the gift card line and set a physical gift card with a value of 100€ * Add another gift card to the order * Click on the gift card line and set a physical gift card with a value of 50€ * Validate the order > Observation: No gift card is created in the backend Why the fix: ------------ When looking for the `oldChanges` we tried to retrieve the gift card code as `gift_code` but the key name is `code`. Because of this the `pointsCount` was wrong. opw-5928320 Forward-Port-Of: odoo/odoo#249951 Forward-Port-Of: odoo/odoo#249066
This update resolves a display issue in the Email Marketing app where test emails were incorrectly showing as 'removed' in Chatter. The fix ensures that test messages are automatically removed when sent, preventing this misleading display and maintaining a clean Chatter view. This improves the user experience when testing email campaigns.
Original PR description
**Steps to reproduce:** - Go to Email Marketing app - Create a mailing campaign - Set its recipients to Contact - Click on the test button to send a test mail to any mail - Go to the first contact…
**Steps to reproduce:**
- Go to Email Marketing app
- Create a mailing campaign
- Set its recipients to Contact
- Click on the test button to send a test mail to any mail
- Go to the first contact record
- Chatter will show `This message has been removed` message
**Issue:**
Previously, message created for testing were ignored by the Chatter as they were empty. As we now keep empty messages visible but with removed content display, they shows up on related records.
```py
record = self.env[mailing.mailing_model_real].search([], limit=1)
```
**Fix:**
Ensure the related messages are unlinked at the same time as the test mail in `send_mail_test` by setting `is_notification` to `False` to trigger the `unlink` logic.
```py
def unlink(self):
# cascade-delete the parent message for all mails that are not created for a notification
mail_msg_cascade_ids = [mail.mail_message_id.id for mail in self if not mail.is_notification]
res = super(MailMail, self).unlink()
if mail_msg_cascade_ids:
self.env['mail.message'].browse(mail_msg_cascade_ids).unlink()
return res
```
related: https://github.com/odoo/odoo/commit/21f92550f83cbd38df2c223c65c61bd16dc8e2b0
opw-5502787
Forward-Port-Of: odoo/odoo#247805This update fixes a technical issue that was disrupting automated payment flows within Odoo. The previous version was encountering errors due to 'unsure data,' which is now simply removed. This ensures seamless processing of incoming payments and prevents disruptions to key business operations.
Original PR description
The last iteration[^1] was preventing automated flows from running smoothly because it was raising an error. Instead, we now just remove the unsure data. [^1]: 1794fce234735ed174599891435d4e2accc1632 Forward-Port-Of: odoo/odoo#250941
A recent issue caused live chat sessions to crash when multiple sessions were started quickly. This fix eliminates a dependency on outdated data, ensuring stable session creation. The update improves the reliability of our live chat functionality.
Original PR description
Since [1], a crash could occur when starting several live chat sessions quickly. Before this PR, the `thread` getter depended on `savedState`. In [1], `thread` became a field on the live chat service. There can be a slight delay where thread has been cleared, but saved state still exists. The `_createThread` method shouldn't rely on `savedState` to determine if there is a thread. [1]: https://github.com/odoo/odoo/pull/173197 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#250626
This update corrects a technical issue in the Spanish reporting module (l10n_es_reports) where an unnecessary date scope was added. This change ensures reports are generated accurately and efficiently, resolving a potential data processing problem. The fix was implemented as a straightforward correction.
Original PR description
In the Forward Port of this PR: https://github.com/odoo/enterprise/pull/108575 A date_scope was wrongly added opw-5363664 Forward-Port-Of: odoo/enterprise#108886
This update fixes a minor issue in the employee departure wizard by switching to a more reliable archiving method. Previously, toggling active status caused problems; now, archiving ensures employees are properly removed from the system, aligning with best practices and related enterprise updates. This improves data accuracy and stability.
Original PR description
When archiving an employee from the departure wizard, use the action_archive method instead of toggle_active. Related to odoo/enterprise#100437 task: 5354002 Forward-Port-Of: odoo/odoo#250632 Forward-Port-Of: odoo/odoo#247224
This update corrects a bug that prevented users with RTL languages (like Arabic) from dragging and dropping snippets into the web editor. The fix adjusts the code to correctly identify drop zones based on the RTL language setting, ensuring functionality for all users.
Original PR description
When dropping outside a dropzone but still on the page, the code checks if the drop happened well outside of the sidebar (so on its left). However, in RTL languages, the sidebar is positioned on the left, so we need to check if the drop is on the right side of it instead. The fix checks if the sidebar is at the left edge (the body of the document should have the `o_rtl` class) and verifies the drop position is on the right of the sidebar. Steps to reproduce: - Set your profile to Arabic - Drag and drop a snippet outside of a dropzone => It's not dropped, but it should, as it would with an LTR language. task-5484936 Forward-Port-Of: odoo/odoo#247759
This update fixes an issue where newly hired employees were incorrectly inheriting their private email address as their work email. The fix clears the employee's work_email field during the contract signing process, ensuring it reflects the correct work email provided by the applicant. This prevents data inconsistencies and improves data accuracy.
Original PR description
**Steps to Reproduce:** 1. Send an offer to an applicant. 2. The applicant submits their details via the salary configurator and enters their private email in the Email field. 3. Once the offer and contract are signed, an employee record is created in Odoo. 4. In the created employee record, the `work_email` field is populated with the email entered in the salary configurator. This same value is also present in `private_email`, which is correct. **Reason:** - The email entered in the salary configurator is stored on the partner and represents the applicant's private email. - The employee's `work_email` field is linked to the partner's email via compute and inverse methods, causing it to inherit the private email value when the employee record is created. **Solution:** - Explicitly clear the employee's work_email field when the applicant sign. task: 5502797 Forward-Port-Of: odoo/enterprise#108769 Forward-Port-Of: odoo/enterprise#106974
This update resolves an issue where kiosk users couldn't add products with descriptions and no attributes to their order. The fix ensures these products are correctly recognized as valid and allows users to add them to the cart, improving the kiosk ordering experience. This prevents a frustrating user experience and ensures all products can be ordered.
Original PR description
Steps to reproduce: ------------------------------- - Install pos_self_order - Open kiosk - Select product that has description and no attributes. - Attempt to add it to the cart. Issue: ----------------------- - Add to Cart button remains disabled despite product being available. Cause: ------------------------- - The system incorrectly treated the product as having incomplete selection. Fix: --------------------- - Ensure such products are treated as valid and can be added to the cart. Task-4868023
3 changes
Resolved issues and error corrections
This update fixes a problem where archived employees incorrectly retained their appraisal dates, causing scheduling conflicts. The change ensures that archived employee appraisal dates are cleared, preventing future issues when managing appraisal plans for companies. This improves the accuracy and reliability of the appraisal process.
Original PR description
**Steps to reproduce:** Based on this feedback https://www.odoo.com/odoo/project.task/5270281 companies with archived employees face an issue when they try to toggle Appraisals Plans from Appraisls -> Configuration -> Settings -> Appraisals Plans **Issue:** The propblem is that when employees with next appraisal date are archived, their next appraisal date is not cleared which leads to past date conflicts upon trying to set the next appraisals dates for all the employees (which is done through toggling the Appraisals Plans checkbox) **Solution:** - Unset the next appraisal date upon archiving an employee - exclude archived employees from _compute_next_appraisal_date method Task: 5354002 Forward-Port-Of: odoo/enterprise#108505 Forward-Port-Of: odoo/enterprise#100437
This update fixes the XML templates used for Dutch SBR and ICP reports to align with the latest 2026 version of the Dutch taxonomy. This ensures accurate reporting for our Dutch customers, complying with local tax regulations and improving data reliability.
Original PR description
Fix the xml SBR and SBR ICP file template for the 2026 version of dutch taxonomy Documentation: https://www.sbr-nl.nl/werken-met-sbr/taxonomie/documentatie-nederlandse-taxonomie task-5974129
This update resolves an issue where rapidly clicking the 'Back' button during barcode internal transfer creation resulted in duplicated quantities being added to the transfer. The fix ensures that multiple back clicks don't trigger redundant saving operations, preventing incorrect quantity calculations.
Original PR description
**Steps to reproduce:** * Install `stock` module. * Go to the > Settings*, enable *Packages* and *Storage Locations*(warehouse). * Create a storable product and set *Tracking Inventory* to **By…
**Steps to reproduce:** * Install `stock` module. * Go to the > Settings*, enable *Packages* and *Storage Locations*(warehouse). * Create a storable product and set *Tracking Inventory* to **By Quantity** and set some *barcode* * Update the on-hand quantity for the product and assign it to one packages. * Open *Barcode > Operations > Internal Transfer* and create a new transfer. * Click the *gear icon* in the top-right corner to open the barcode scanning flow. * manually enter the created product barcode and apply it. * Click the **Back** button multiple times in quick succession. * Go to the backend and open the created internal transfer. **Observed behavior:** * The internal transfer is created with *double quantities* compared to what was added in the barcode interface. **Cause:** * When clicking the *Back* button, the following flow is triggered: `exit()` → `beforeQuit()` → `save()`. https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/components/main.js#L406-L414 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L473-L475 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_picking_model.js#L828-L832 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L477-L483 * If the button is clicked multiple times rapidly, `exit()` is called again before the previous `save()` RPC completes. * This results in multiple `save()` calls being executed, causing duplicated quantities on the picking. reference - https://github.com/odoo/enterprise/pull/103999/changes/b791239c154deb6a25f85d65ebc72e3ac53b6c74 **Fix:** * Prevent rapidly clicking the Back button multiple times does not multiply quantities. --- opw-5375899 Forward-Port-Of: odoo/enterprise#108788 Forward-Port-Of: odoo/enterprise#103130
13 changes
Resolved issues and error corrections
This update resolves an issue where the 'account_iso20022' module was generating invalid XML for Swiss payment files (pain.001). The fix ensures that only one of BIC or ClrSysMmbId is included, aligning with Swiss banking standards. This prevents payment processing errors and ensures compliance.
Original PR description
**Steps to reproduce:** - Install 'account_iso20022', 'l10n_ch' and switch to a Swiss company - Have a bank with a BIC number and an account for that bank with a clearing number - Create a vendor…
**Steps to reproduce:** - Install 'account_iso20022', 'l10n_ch' and switch to a Swiss company - Have a bank with a BIC number and an account for that bank with a clearing number - Create a vendor bill for a Swiss partner or payrun report - Pay with "Swiss ISO20022" > generate xml pain001 - Validate against xsd or any swiss pain001 test plateform > Incorrect rules usage ! not valid xml ! **Cause:** In the XML the field BIC and ClrSysMmbId are present. Only one of them can be present. See the [documentation (page 27 and 33)](https://www.six-group.com/dam/download/banking-services/interbank-clearing/fr/standardization/iso/swiss-recommendations/archives/implementation-guidelines-ct/implementation-guidelines-ct_v1_6_1.pdf). **Solution:** Create the method `_get_ClrSysMmbId()` which will only return for Swiss if there is no BIC number. This is a partial unrevert of [this commit](https://github.com/odoo/enterprise/commit/177c7bbc890c3d142010de2cb7d0d9d6752c7fd9#diff-282e44e861d61542f3bc6d40e61b73fd1556f659d53ecd8bf9430dcec79c2fd6). opw-4872507 Forward-Port-Of: odoo/enterprise#108796 Forward-Port-Of: odoo/enterprise#108461
This update streamlines the process of finding or creating bank accounts within Odoo Enterprise. The changes consolidate how bank accounts are handled across multiple modules, reducing potential errors and improving data consistency. This enhancement ensures more reliable financial transactions and reporting.
Original PR description
*: account_invoice_extract,hr_constract_salary,payment_sepa_direct_debit Forward-Port-Of: odoo/enterprise#108238
This update resolves an issue where a specific configuration of salary inputs on employee records would cause a calculation error during payslip generation. The fix prevents the system from incorrectly interpreting a hidden input field as a valid number, ensuring accurate payroll processing. This improves the reliability of payslip calculations.
Original PR description
**Steps to reproduce** - Have a salary rule - Condition based on: Salary Input - Input on: Employee - On the employee form, click on "Add inputs" in the Payroll tab - Add an input - Enter a value - Click on "Inputs" to fold the section and hide the input - Try to compute a new payslip for this employee, error: `ValueError: invalid literal for int() with base 10: 'separator_1'` **Cause** By default, the separator doesn't have a `value` key, but after the first interaction to hide its elements, it is added to keep track of the folded state (see `_toggleSeparators` in `web`). **Solution** Ensure separators are ignored. opw-5928247 Forward-Port-Of: odoo/enterprise#108731 Forward-Port-Of: odoo/enterprise#107326
This update fixes the XML templates used for generating Dutch SBR and ICP tax reports, aligning them with the latest 2026 version of the Dutch taxonomy. This ensures accurate reporting for our Dutch customers, complying with regulatory requirements and improving the reliability of financial data.
Original PR description
Fix the xml SBR and SBR ICP file template for the 2026 version of dutch taxonomy Documentation: https://www.sbr-nl.nl/werken-met-sbr/taxonomie/documentatie-nederlandse-taxonomie task-5974129
This update fixes an issue where the payroll update process would fail when a common working schedule was deleted. The fix ensures that the system correctly handles situations where a referenced schedule is no longer present, preventing errors and maintaining accurate payroll calculations. This impacts all localized payroll modules.
Original PR description
*:ae,au,bd,be,ch,eg,id,jo,ke,lt,lu,ma,my,nl,pk,pl,ro,sk,tr,us When the ``Standard 40 hours/week`` working schedule is deleted and the ``Payroll: Update data`` cron runs, a traceback is raised. For…
*:ae,au,bd,be,ch,eg,id,jo,ke,lt,lu,ma,my,nl,pk,pl,ro,sk,tr,us
When the ``Standard 40 hours/week`` working schedule is deleted
and the ``Payroll: Update data`` cron runs, a traceback is raised.
For ``l10n_us_hr_payroll`` module
Steps to reproduce the error:
- Install ``l10n_us_hr_payroll`` module with demo data
- Go to Employees > Configuration > Settings > Change Company Working Hours
- Go to Working Schedules > Delete ``Standard 40 hours/week`` working schedule
- Run the ``Payroll: Update data`` cron
Traceback:
```py
ValueError: External ID not found in the system: resource.resource_calendar_std
ParseError: while parsing /home/odoo/src/enterprise/l10n_us_hr_payroll/data/hr_payroll_structure_type_data.xml:3, somewhere inside <record id="structure_type_employee_us" model="hr.payroll.structure.type">
<field name="name">United States: Employee</field>
<field name="default_resource_calendar_id" ref="resource.resource_calendar_std"/>
<field name="country_id" ref="base.us"/>
</record>
```
The ``Payroll: Update data`` cron updates payroll data that references
the ``Standard 40 hours/week`` working schedule.
If the user has deleted this working schedule, the external ID no longer exists,
leading to the above traceback.
sentry-7166574553
Forward-Port-Of: odoo/enterprise#108730
Forward-Port-Of: odoo/enterprise#106950This update resolves a technical issue preventing the account reports annotation tour from functioning correctly. The change adjusts the confirmation button used in the tour to align with recent styling updates, ensuring the tour operates as intended. This improves the user experience for accessing and utilizing the account reports feature.
Original PR description
This PR updates the account reports annotation tour to use the correct confirmation button after the dialog styling change, fixing the failing test trigger. community: https://github.com/odoo/odoo/pull/247708 task-5873845 Forward-Port-Of: odoo/enterprise#108806
This update resolves an issue where the tax report export button wouldn't work correctly when companies had different VAT numbers and branches. The fix ensures the button correctly considers the entire branch hierarchy, allowing users to export reports for all relevant companies. This improves the accuracy and usability of the tax reporting feature.
Original PR description
To reproduce the issue: - Create a company with a branch - Give the company and its branch different VAT numbers - Make both companies active in the company selector - Open the tax report - Click on gear icon - Click on the XML(l10n_lu_reports)/Export SAWT & QAP(l10n_ph_reports) button ===> The following error is raised: "Please select the main company and its branches in the company selector to proceed." This is because the tax report's options only consider one of the two companies (because they have different VAT numbers). The button is not declared as branch_allowed, so when clicked, it checks whether all the companies of the branch hierarchy are in the options => they're not => error. We can fix this by simply making the buttons branch_allowed. Followup on: https://github.com/odoo/enterprise/commit/34ba0609e984496f0dcc862f0d7a46c6721beab9 task-5416330 Forward-Port-Of: odoo/enterprise#105961
This update fixes an issue where the system incorrectly identified companies in certain localization modules (Brazil and Ecuador). Now, Brazilian partners with a CNPJ and Ecuadorian partners with a RUC are correctly recognized as companies. For other countries, a partner is considered a company if a VAT is provided.
Original PR description
`is_company` was not correctly computed in some localization modules. This commit adds a compute method for: - l10n_br*: Company if identification type is CNPJ - l10n_ec*: Company if identification type is RUC For foreign partners (country ≠ BR/EC), a partner is considered a company if a VAT is provided. Follow-up of: https://github.com/odoo/enterprise/pull/86089 Task-5947797 Forward-Port-Of: odoo/enterprise#108599 Forward-Port-Of: odoo/enterprise#107674
This update corrects a potential data issue where OCR processing of CVs could incorrectly overwrite existing contact information (like company or user details) within the system. The fix adds safeguards to ensure OCR data is only applied when appropriate, preventing inaccurate data propagation. This ensures data integrity for applicant records.
Original PR description
When OCR processes a CV, it writes extracted name/email/phone onto the applicant, which then propagates to the linked res.partner via the email_from inverse. This causes data corruption in two cases: - The CV was forwarded: the OCR email belongs to the candidate but email_from is the forwarder's address. Writing OCR data would overwrite the forwarder's partner with the candidate's details. - The existing partner is a company contact (parent_id set) or is linked to a user account (user_ids set). Writing OCR data would overwrite user/business partner with the candidate's details. Both guards are applied and added tests that check the flows. task-5949635 Forward-Port-Of: odoo/enterprise#108128
This update fixes an issue where rental accessories added from the cart's suggested products wouldn't consistently apply the correct rental period. Now, when adding accessories from the cart, the system uses the existing cart's rental period, ensuring accessories are added correctly and preventing errors. This improves the user experience for rental product purchases.
Original PR description
Why this commit --- When adding a rental accessory product from the cart page suggested products, the…
Why this commit --- When adding a rental accessory product from the cart page suggested products, the [add_to_cart](https://github.com/odoo/enterprise/blob/19.0/website_sale_renting/controllers/cart.py#L52-L58) was triggered without the rental start and end dates(None was taken by default). As a result, the system uses [default rental duration](https://github.com/odoo/enterprise/blob/19.0/website_sale_renting/models/sale_order.py#L95-L99) for comparison and considers the accessory as having a different rental period then on the sale order and raised an error preventing it from being added to the cart. This issue did not occur when adding the same product from its product page, as the rental context was correctly provided there. After this Commit --- The rental start and end dates from the current sale order are passed when adding accessory products from the cart page suggested products. This ensures that rental period consistency checks succeed and the accessory can be added without raising an invalid operation error. Steps to Reproduce --- 1. Create two rental products A and B. 2. Configure product B as an accessory of product A. 3. Add product A to the cart with any rental period(except default). 4. From the cart page, attempt to add product B from suggested products. 5.Observe the error about mixing different rental periods. Here is the video demonstrating on how the error is reproduced : https://github.com/user-attachments/assets/3d5e6f96-cebd-4221-8592-1bdb6ae40ec7 Expected Result The accessory product is added to the cart using the same rental period as the existing cart's rental period. OPW: 5823691 Forward-Port-Of: odoo/enterprise#107343 Forward-Port-Of: odoo/enterprise#106426
This update corrects a discrepancy in payslip calculations for the private car daily allowance. The daily amount is now rounded to two decimal places to precisely match the 'Quantity × Amount' displayed on payslips. This ensures accurate and consistent payroll reporting for employees.
Original PR description
Round the computed daily private-car salary rule amount to 2 decimals so the displayed per-day value matches Quantity × Amount on payslips. References task-5917569 Forward-Port-Of: odoo/enterprise#108606 Forward-Port-Of: odoo/enterprise#106753
This update resolves an issue where the 'Publish & Send' button was inadvertently removed from the scheduling interface. The fix removes a previous change that added a context variable, which caused the button to disappear. This ensures users can correctly send their scheduled shifts.
Original PR description
## Issue Since commit https://github.com/odoo/enterprise/commit/a0f44c2bdb2, `planning_test_tour_no_email` is failing when trying to click on the (missing) `Publish & Send` button. ## Cause The…
## Issue
Since commit https://github.com/odoo/enterprise/commit/a0f44c2bdb2, `planning_test_tour_no_email` is failing when trying to click on the (missing) `Publish & Send` button.
## Cause
The commits adds the `my_planning_action` attribute to the context when opening the `Schedule by Resource`. This allowed to display the `I Take It!` button when opening an open shift, but it also removed the `Publish & Send` button, as its condition to be invisible consistently contains `context.get('my_planning_action')` [[1](https://github.com/odoo/enterprise/blob/6892fbda8717effdf3eac06eb6783f1c238ce789/planning/views/planning_views.xml#L11), [2](https://github.com/odoo/enterprise/blob/6892fbda8717effdf3eac06eb6783f1c238ce789/planning/views/planning_views.xml#L78-L79), [3](https://github.com/odoo/enterprise/blob/6892fbda8717effdf3eac06eb6783f1c238ce789/planning/views/planning_views.xml#L273-L274)].
## Fix
The objective is to fix the bug from previous commit https://github.com/odoo/enterprise/commit/a0f44c2bdb2 differently. Instead of adding the `my_planning_action` to the context, we remove the conditions on the `I Take It!` button.
runbot-241028
Forward-Port-Of: odoo/enterprise#108753
Forward-Port-Of: odoo/enterprise#108333This update fixes a bug that prevented the accurate calculation of employer costs in Switzerland. The change ensures that employer contributions are now correctly included in payroll calculations, aligning with Swiss regulations. This improves payroll accuracy and reporting.
Original PR description
The computation of the employer cost in Switzerland was wrong (always 0) because the rules didn't have the appears_on_employee_cost_dashboard flag set and were therefore not counted in the computation of the fiels. Furthermore we modify the override of the function used to compute the values of some fields, to add the correct computation of the employer cost. Task: 5354103 Forward-Port-Of: odoo/enterprise#106839
15 changes
Resolved issues and error corrections
This update corrects a bug preventing users from adding dependent salary rules after creating a main rule. The change ensures that all relevant rules are displayed when adding inputs to an employee's payroll, improving payroll configuration efficiency. This resolves a previous issue where dependent rules were hidden.
Original PR description
Problem ------------------ The salary inputs selection widget only displays the main salary rule, not the dependent rules, so when a new dependent rule is created after the main one was added to the…
Problem ------------------ The salary inputs selection widget only displays the main salary rule, not the dependent rules, so when a new dependent rule is created after the main one was added to the employee form, it is not possible to select the the new rule to display. Navigation: 1. Payroll > Configuration > Rules > New > Condition Based On: Salary Input > Input On: Employee > Save 2. Employees > Select Employee > Payroll > Add Inputs > Select Rule > Save 3. Configuration > Rules > New > Condition Based on: Salary Input > Input On: Employee > Depends On: Previous Rule > Save 4. Employees > Select Employee > Payroll > Add Inputs > New Rule is not available Objective ---------------------- Version 19.0 doesn't filter out existing rules, so it is possible to select the prerequisite rule again and add the new dependent rule, but later commits changed the search domain to filter out inputs that were already selected. Some of the changes should probably have been included in the 19.0 version. Need to back port the changes and edit the search domain to show dependent rules that have not been selected yet. Solution --------------------------- Option B from the task specifications to show the dependent salary rules when "Add Inputs" is clicked if it's not already displayed even if the prerequisite rule is displayed. Edited the payroll structure search domain to find rules that are not displayed and either do not have prerequisites OR have a prerequisite that is already displayed. Task: 5942461
Recent tests were failing due to a conflict between modules activating different currencies (EUR vs. USD). This update ensures the OCR consistently uses the default USD currency, resolving the test failures and improving overall test reliability. This ensures consistent test results and a more stable system.
Original PR description
When the tests are run with all modules installed and demo data, some of them fail. One of the other modules activates the EUR currency, which causes the OCR to select it instead of leaving the default USD currency. - Test `test_bank_account` fails because, when the `currency_id` field is set, it triggers a re-computation of `partner_bank_id` which will reset its value to `False`. Runbot build error [240759](https://runbot.odoo.com/odoo/runbot.build.error/240759). - Test `test_invoice_ocr_note_author` fails because it's not expected that the `currency_id` is modified and logged in the tracking message. Runbot build error [238512](https://runbot.odoo.com/odoo/runbot.build.error/238512) (only in saas-19.2 and up, but it is mentionned here as the fix is the same). To make the tests more reliable, we now ensure only the USD currency is active.
This update fixes a bug in the Swiss payroll calculation that resulted in employer costs being incorrectly displayed as zero. The change ensures that employer costs are now accurately calculated and reflected, aligning with Swiss tax regulations. This improves payroll accuracy and reporting for Swiss businesses.
Original PR description
The computation of the employer cost in Switzerland was wrong (always 0) because the rules didn't have the appears_on_employee_cost_dashboard flag set and were therefore not counted in the computation of the fiels. Furthermore we modify the override of the function used to compute the values of some fields, to add the correct computation of the employer cost. Task: 5354103
This update fixes a technical error that prevented managers without specific appraisal rights from scheduling meetings. The issue stemmed from access restrictions on related partner IDs. The fix simplifies the process by directly using employee work contact IDs, ensuring reliable meeting scheduling for all managers.
Original PR description
Steps to reproduce: - Create two employees: one as a manager and the other as a subordinate. - Ensure that the manager does not have any officer or appraisal rights. - Create an appraisal for the subordinate through the manager. - Confirm the appraisal and then click the Schedule Meeting button Issue: - The manager should schedule a meeting even though he does not have the rights, but a traceback error occurs due to access rights issues when trying to schedule a meeting. Reason: - The manager is unable to access the related_partner_id due to restrictions set by the officer/manager group, which results in a traceback error. Fix: - Replace the related_partner_id with the work_contact_id of the employee. Since related_partner_id is computed from work_contact_id, we can directly use work_contact_id task-5881127
This update resolves an issue where work entries weren't being generated when multiple resource calendar attendances were adjacent in time. The fix prevents the system from incorrectly combining consecutive attendances, ensuring that work entries are created as expected for credit time and other work entry types. This improves the accuracy of time tracking for employees.
Original PR description
When you have two resource calendar attendances that are stuck together, and you generate work entries, the second one doesn't appear: Bug is caused when having two attendances stuck together: In a resource.calendar, change the time of a resource.calendar.attendance to finish at 15.36 and create a new one that begins at 15.36 and finished at 16.36 with a work entry type of Credit time. Go and regenerate work entries and you can see that no work entries are generated for credit time. Fixed by adding keep_distinct in an interval to not fuse them together. Also added extra checks to another test to not pass with incorrect values. task-5894994
This update fixes a bug that prevented payment advice reports from functioning correctly when employees had multiple bank accounts. The team verified all bank BICs and ensured the system now accurately generates payment advice reports even with invalid data for non-primary bank accounts. This ensures accurate financial reporting for our users.
Original PR description
steps to reproduce: - install `l10n_in_hr_payroll` - create an employee, with multiple bank accounts - add invalid BIC in one of the bank accounts with isn't primary - notice that you will still be able create the advice report with invalid data. issue: - after the support of multiple bank accounts, the payment advice methods were not adapted with it. fix: - checked all the banks and their BIC. task-5890497
This update resolves an issue where action buttons on the work entry Gantt view would cause errors when no employees were selected. The fix hides these buttons automatically when there are no employees, preventing unexpected errors and improving user experience.
Original PR description
On gantt view of work entries when user multi-selects entries, action buttons appears Ex. Set, Reset etc. When their are no employees in the column, on clicking these action buttons gives traceback. Ex:- `TypeError: Cannot read properties of undefined (reading '0')` or `KeyError: 'employee_id'` This fix will hide these buttons when there are no employees present. task-[5445718](https://www.odoo.com/odoo/project/1251/tasks/5445718)
This update resolves a potential issue during Odoo database upgrades. Previously, removing a payroll rule could cause upgrade scripts to fail. This change ensures that upgrade scripts continue to function correctly even if a rule has been deleted, improving the reliability of database updates.
Original PR description
This method is used in various places, including when upgrading a database. When doing so, it is done in a post upgrade script. If later one of the updated rules is removed, the pre-script removing it will run before the post script trying to update it, causing the migration to fail as the update method tries to browse a falsy value. This updates the `update_properties_definition_domain` method so that it ignores falsy values when browsing, allowing previous upgrade scripts to run even if the referred rule has been since deleted.
This update fixes the XML templates used for Dutch tax reporting (SBR and ICP) to align with the latest 2026 version of the Dutch taxonomy. This ensures accurate reporting for our Dutch customers, complying with local tax regulations. The change was made to maintain compliance and avoid potential reporting errors.
Original PR description
Fix the xml SBR and SBR ICP file template for the 2026 version of dutch taxonomy Documentation: https://www.sbr-nl.nl/werken-met-sbr/taxonomie/documentatie-nederlandse-taxonomie task-5974129
This update resolves an issue where the VAT Book download was only generating for the primary company, not related branches with the same CUIT. The fix ensures that VAT Books are correctly generated for all selected companies with the same tax identification number, improving reporting accuracy for Argentine businesses.
Original PR description
#### Issues: VAT Book should download for all selected companies with same CUIT as the current one. #### Step to reproduce: - In a company in Argentina ("Parent Company") - Create a branch "Child…
#### Issues:
VAT Book should download for all selected companies with same CUIT as the current one.
#### Step to reproduce:
- In a company in Argentina ("Parent Company")
- Create a branch "Child Company A" with no CUID
- Create a branch "Child Company B" with a different CUID than parent
- Go to "Child Company A"
- Either:
- i. Select both "Parent Company" and "Child Company A" but not "Child Company B"
- ii. Select all 3 "Parent Company", "Child Company A" and "Child Company B"
- In Accounting > Report > Tax Return :
- Download the VAT Book (wheel > "VAT book(ZIP)")
#### Current behavior:
i. Get Invalid Operation
ii. Download the VAT Book for "Parent Company" only
#### Expected behavior:
- Download the VAT Book for both "Parent Company" and "Child Company A"
A previous call to get_options provide the client with the info about which selected companies have the same CUIT as the current company. Therefore companies in the options are the correct ones.
opw-5385585
Forward-Port-Of: odoo/enterprise#101898This update corrects a bug in the Belgian VAT reporting feature that caused key fields ('Ask Restitution' and 'Client Nihil') to be missing from the generated PDF reports. The change restored a necessary wrapper to ensure the correct fields are included, resolving an issue impacting report accuracy for Belgian users. This ensures accurate VAT return generation.
Original PR description
This commit https://github.com/odoo/enterprise/commit/e8d2084369d58717c2294e023cbdfd60f713c334 removed the `pdf_options_header` wrapper. 18.3-:…
This commit https://github.com/odoo/enterprise/commit/e8d2084369d58717c2294e023cbdfd60f713c334 removed the `pdf_options_header` wrapper.
18.3-:
https://github.com/odoo/enterprise/blob/ce67bf6fb4f694c25785580fe3ed290bcb8c92b5/account_reports/data/pdf_export_templates.xml#L151-L154
18.4+:
https://github.com/odoo/enterprise/blob/e3746aba3c334a628a15a4263ddfa08876d2a288/account_reports/data/pdf_export_templates.xml#L159-L160
This broke `l10n_be_reports` which uses `(//div[hasclass('row')])[last()]` to inject BE-specific fields:
https://github.com/odoo/enterprise/blob/e3746aba3c334a628a15a4263ddfa08876d2a288/l10n_be_reports/data/tax_report.xml#L9-L24
Without the wrapper, `[last()]` targets the conditional `aml_ir_filters` row instead, making BE fields invisible.
Steps to reproduce:
1. Create a Belgian company
2. Navigate to Accounting → Reporting → Tax Return
3. Create a VAT Return and submit it
4. Check the generated PDF in the attachment
=> The "Ask Restitution" and "Client Nihil" fields are missing from the PDF header.
Ticket [link](https://www.odoo.com/odoo/action-4043/5509725)
opw-5509725
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/enterprise#107519This update fixes an error in how payroll rates were calculated for employees on attendance-based contracts. Previously, rates were incorrectly based on actual work hours recorded, not the employee's planned schedule. Now, rates are accurately determined using the employee's working schedule, ensuring correct compensation for attendance-based employees.
Original PR description
Step to Reproduce: - install UAE Payroll localization and attendance - create employee and running employee contract and give basic salary, housing, transportation and other allowance. - work entry…
Step to Reproduce: - install UAE Payroll localization and attendance - create employee and running employee contract and give basic salary, housing, transportation and other allowance. - work entry source should be attendance - create a payslip and compute sheet. Issue: - The values for payslip lines are not as expected. - The rate per hour for basic salary , housing, transportation and other allowances was being calculated based on employee's attendance work entries, not the planned working schedule. Reason: - When using attendance-based contracts, the hourly rates for basic salary, housing, transportation, and other allowances should be calculated based on the working schedule's hours per day, if a working schedule is available. Solution: - Instead of sum_worked_hours which takes working hours of employee's work entries, use total_number_of_days multiplied by the hours per day from the working schedule. task-5270185 Forward-Port-Of: odoo/enterprise#108637 Forward-Port-Of: odoo/enterprise#103282
This update fixes an issue where deleting a partially signed offer would incorrectly delete the associated employee. The change ensures the employee record is only deleted when the offer is archived and the employee has no other active offers. This prevents data loss and maintains accurate employee records.
Original PR description
Version – saas-18.4 ### Issue: When an applicant has both a partially signed offer and a fully signed offer, deleting the partially signed one also deletes the employee that was created from the fully signed offer. ### Steps to Reproduce: - Create two offers for an applicant. - Fully sign the first offer and partially sign the second one. - Delete the partially signed offer. The employee created from the fully signed offer is also deleted. ### Cause: Due to this issue, the employee record is incorrectly deleted from the system, which is not expected behavior. ### Fix: Improved the employee deletion logic by deleting the employee only when: - the employee is archived, and - they do not have any other offers besides the one being deleted. ### Impact: The employee will no longer be deleted when another partially signed offer for the same applicant is removed. --- Task – 5347109 Forward-Port-Of: odoo/enterprise#100991
This update resolves an issue preventing the SAF-T report from correctly identifying suppliers for fixed assets. The fix ensures that supplier information is accurately retrieved by expanding the data source to include depreciation lines, addressing a problem caused by bills being posted in a previous period.
Original PR description
**Steps to reproduce:** - Install l10n_ro_saft - Switch to a Romanian company (e.g. RO Company) - Create an asset model: * Method: Straight Line * Duration: 12 Months - Configure a "Fixed Assets"…
**Steps to reproduce:** - Install l10n_ro_saft - Switch to a Romanian company (e.g. RO Company) - Create an asset model: * Method: Straight Line * Duration: 12 Months - Configure a "Fixed Assets" account: * Automate Asset: Create and validate * Asset Model: [the asset model created above] - Create a bill: * Vendor: [create a new vendor] * Bill Date: [last month] * Invoice Line: [A line with the fixed asset account] - Confirm the bill - Go to "Accounting / Reporting / Audit Reports / General Ledger" - Select the current month (The fixed asset account should be present) - In the cog menu, select "SAF-T (D406 Asset Declaration)" **Issue:** A traceback is raised while trying to display the name of a supplier. **Cause:** To display the supplier name of an asset, a dict having the id of the customer or supplier as key (i.e. partner_detail_map) is used. This dict is build by getting the list of all partners linked to a posted journal item on an asset (or liability) account in the period of the report. In this case, it's the current month. However, the created bill has been posted the month before. So no journal item is found for the vendor that has been created just for the bill and therefore there is no key for him in the dict, which leads to the error when trying to get the id of the supplier of the asset in the dict. **Solution:** Instead of just fetching the posted entries linked to a receivable or payable account in order to get the list of the potential customers and suppliers, we also fetch the depreciation lines that are linked to an asset account and can still be in draft. opw-5499918 Forward-Port-Of: odoo/enterprise#105987
This update fixes an issue where check printing in the Philippines wasn't accurately reflecting payments after withholding taxes. Now, the check amount will correctly display the net payment amount, ensuring accurate financial reporting for Philippine businesses. A new test case has been added to verify this change.
Original PR description
In Philippines' check localization module, the amount on check should be based on the net amount after deducing withholding amount for payments if the payment is with taxes that are set as withholding on payment. This commit fixes the check print's values to reflect the net amount. Minimal test case is also added to safeguard the new behavior. [Task-5928813](https://www.odoo.com/odoo/all-tasks/5928813) Forward-Port-Of: odoo/enterprise#108611
2 changes
Resolved issues and error corrections
This update ensures Odoo's Dutch tax reporting files (SBR and ICP) are aligned with the latest 2026 version of the Dutch taxonomy. This is crucial for accurate and compliant financial reporting in the Netherlands, avoiding potential issues with tax authorities.
Original PR description
Fix the xml SBR and SBR ICP file template for the 2026 version of dutch taxonomy Documentation: https://www.sbr-nl.nl/werken-met-sbr/taxonomie/documentatie-nederlandse-taxonomie task-5974129
This update fixes a silent error in the Point of Sale module that prevented users from generating invoices when an untrusted bank account was associated with a customer. Now, a popup will clearly display the error, such as 'untrusted bank account,' guiding the user to correct the issue and complete the invoice process. This enhancement ensures smoother transactions and prevents potential data discrepancies.
Original PR description
Steps to reproduce: - Add untrusted bank account to the database's selected company's contact - Finalize an order in point of sale through register - While in register, go to orders and click on the invoice button for the finalized order Current behavior: - There is no indication of why you can't generate an invoice Expected behavior: - There should be a popup to the user identifying the error (e.g. untrusted bank account) This addresses a side effect of: https://github.com/odoo/odoo/pull/248108 opw-5946239
1 change
Resolved issues and error corrections
This update resolves a warning generated during testing related to fake PDF content. The change replaces these fake files with a minimal PDF file, ensuring consistent test results and preventing potential issues with the PyPDF library. This improves the reliability of our testing process.
Original PR description
While creating attachments/documents for testing, using a "fake PDF content" generates warning from PyPDF 5.4.0 (even with `strict=False`) when the said PDF is eventually parsed. This commit replaces those "fake PDF content" by reading the "minimal" PDF file provided for testing purposes in `base`. runbot-231278