Daily updates from Odoo
Friday, February 27, 2026
161 changes
16 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 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 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 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 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 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
This update corrects a minor issue in the Attendance module where duplicate field names were appearing in the attendance list view. The changes ensure that the 'in_location' and 'out_location' fields display correctly, preventing confusion for users. This resolves a technical detail that didn't impact core functionality.
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
A technical error prevented managers without appraisal rights from scheduling meetings. This update corrects a flaw in how the system accesses employee information, ensuring managers can now successfully schedule meetings as intended. This resolves a potential disruption to workflow.
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
24 changes
Resolved issues and error corrections
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 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 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
A bug was preventing users from correctly saving approval rules within the web_studio interface. This was due to a mismatch in how boolean values were represented between Python and JavaScript. The update corrects this by using the appropriate method to convert Domain objects to strings, ensuring approval rules are saved reliably.
Original PR description
Steps to reproduce ================== - Install web_studio,sale_management - Open a form view in sale - Open studio - Click on the "Send by email" button - Add an approval rule - Add a domain by clicking on the filter icon - Use the not set operator - Confirm - Click on the filter icon again - Confirm => ValueError: malformed node or string on line 1: <ast.Name object at 0x79ff4c7b7f50> Cause of the issue ================== JSON.stringify was used to pass the domain as a string to the DomainSelectorDialog. This doesn't work for boolean as they don't have the same representation in JavaScript as opposed to Python. Solution ======== Use the Domain().toString function opw-5923585 Forward-Port-Of: odoo/enterprise#108595 Forward-Port-Of: odoo/enterprise#107432
This update fixes an issue preventing the deletion of archived employee versions. Previously, a validation error would occur if an archived version was deleted, even if other active versions existed. Now, archived versions can be safely deleted without causing errors, streamlining employee record management.
Original PR description
Version – saas-18.4 Issue: Deleting an archived version of an employee that has only a single version raises a `ValidationError` stating: `Employee %s must always have at least one active version.`…
Version – saas-18.4 Issue: Deleting an archived version of an employee that has only a single version raises a `ValidationError` stating: `Employee %s must always have at least one active version.` Steps to Reproduce: - Make an archived version of an employee which have exactly one version. - Try to delete that archived version - Validation Error will occur which states that `Employee %s must always have at least one active version.` Cause: The validation logic prevents deletion when the number of versions being deleted equals the total number of unarchived versions of the employee. Fix: Improved the ValidationError logic by ensuring that no error is raised when the version being deleted is archived. Impact: Archived employee versions can now be deleted without raising unnecessary errors. Task – 5347109 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250557 Forward-Port-Of: odoo/odoo#238344
This pull request corrects a minor typo in the Combo Configurator module, which ensures consistent and accurate display of product information. This resolves a potential confusion for sales staff and customers, improving the overall user experience. The fix was made to maintain data integrity and a professional presentation.
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#249973
This update resolves a bug where work entries weren't being generated when multiple resource calendar attendances were close together in time. The fix prevents attendances from being incorrectly combined, ensuring accurate work entry creation for employees. This improves the reliability of payroll and time tracking.
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 Forward-Port-Of: odoo/enterprise#105981
This update clarifies the event booking process for existing partners. When booking with a known email, the system now suggests both 'Sign In' and 'Create an Account' options. This ensures partners are guided to the most appropriate action, regardless of their portal access, improving the overall booking experience.
Original PR description
When booking with an email that belongs to an existing partner, a 'Sign in' link is shown to the booker. If the partner has no portal access, then it is not relevant as they could also need to create an account. Therefore, change the wording by adding 'or create an account'. This way, the use of the login page redirection is more complete. opw-5419532 Forward-Port-Of: odoo/odoo#250740 Forward-Port-Of: odoo/odoo#241445
This update fixes an issue where salary inputs configured for employees weren't appearing on their payslips. The fix ensures that any salary input enabled for a payslip is now correctly reflected, providing a more complete view of employee compensation. This improves data accuracy and reporting.
Original PR description
### Issue: When a salary input is already configured at the employee level and later enabled for payslip , it does not appear on the payslip. ### Fix: Fixed the domain to show the salary input in the payslip. ### Impact: Now the salary input if enabled for payslip can also be viewed in the payslip. --- task:5951414
This update quietly handles errors that occur during tour termination, specifically 'AssetsLoadingError', which represents lazy-loaded assets. Previously, these errors were handled differently, and this change ensures a smoother experience by consistently ignoring these types of failed requests after a tour ends. This improves stability and prevents minor errors from disrupting the user experience.
Original PR description
Similarly to commit https://github.com/odoo/odoo/commit/493bab4f460dd4069d5cb6805933b8088067ff17 hiding "failed to fetch" errors, this commit adds AssetsLoadingError as those represents "just" another category of failed assets request (i.e. lazy loaded) after tour termination. runbot-233826 Forward-Port-Of: odoo/odoo#250839 Forward-Port-Of: odoo/odoo#248003
This update resolves a warning generated during testing related to fake PDF content. The team replaced the problematic 'fake PDF content' with actual sample PDF files from the base directory, ensuring consistent and reliable test results. This improves the stability of the 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 Forward-Port-Of: odoo/enterprise#108779
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
18 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 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 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 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 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
This pull request corrects a minor typographical error within the Odoo sale module's configuration settings. This ensures consistent and accurate display of sale options for users, improving the overall user experience. The fix addresses a small, non-functional issue that could have caused confusion.
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#249973
This update clarifies the event booking process for existing partners. When booking, the system now suggests both 'Sign In' and 'Create an Account' options, ensuring partners have clear guidance regardless of their portal access. This improves the user experience and streamlines the registration process.
Original PR description
When booking with an email that belongs to an existing partner, a 'Sign in' link is shown to the booker. If the partner has no portal access, then it is not relevant as they could also need to create an account. Therefore, change the wording by adding 'or create an account'. This way, the use of the login page redirection is more complete. opw-5419532 Forward-Port-Of: odoo/odoo#250740 Forward-Port-Of: odoo/odoo#241445
This update fixes an issue where Point of Sale session messages were consistently displayed in English, regardless of the user's selected language. The fix ensures that all cash-related messages within POS sessions are now translated accurately based on the user's language preference, improving the user experience for international customers.
Original PR description
**Problem:** When opening or closing a POS session, chatter messages display untranslated English text regardless of the user's language setting. **Steps to reproduce:** 1. Set user language to any non-English language (e.g., Spanish) 2. Open a POS session and register cash in/out operations 3. Close the session 4. Check the chatter messages - labels appear in English **Current behavior:** Messages display in English: "Opening cash difference", "Opening cash expected", "Opening cash counted", "Closing difference", etc. **Expected behavior:** Messages should be translated according to the user's language setting. **Cause of the issue:** The hardcoded strings were not wrapped in the translation function `_()`, preventing them from being translated. **Fix:** Wrap the concatenated strings with `_()` to enable proper translation of all cash details messages. opw-5185310 Forward-Port-Of: odoo/odoo#244501
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 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 corrects a previous failed backport caused by attempting to use a field that hadn't been implemented in the 18.2 branch. The commit removes the reliance on this missing field, ensuring the backport now functions correctly. This resolves a technical issue preventing the update.
Original PR description
A previous backport was using a field that was not yet present in the 18.2 branch, which caused the backport to fail. This commit remove the use of the field. support: 5975960
This update fixes an issue where newly hired employees were incorrectly inheriting their private email address as their work email. The fix ensures that the employee's work email field is properly cleared during the contract creation process, preventing this duplication. This ensures accurate email data for new employees.
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
16 changes
Resolved issues and error corrections
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 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 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 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 fixes a technical issue related to how numeric values are handled in the web_studio interface and ensures consistent use of the new badge widget across the appointment module. It improves the reliability of data entry and aligns with recent changes to the core widget system, enhancing overall system stability.
Original PR description
### **This PR addresses:** Updating the `appointment` module to reflect the removal of the `selection_badge_icons` widget in core `web` and fixing property parsing in `web_studio`. This is a…
### **This PR addresses:** Updating the `appointment` module to reflect the removal of the `selection_badge_icons` widget in core `web` and fixing property parsing in `web_studio`. This is a mandatory follow-up to the migration of icon support and dropdown fallbacks into the standard `selection_badge` widget. ### **Key Changes:** * **Widget Migration:** Replaced all occurrences of `widget="selection_badge_icons"` with `widget="selection_badge"` in appointment question views. * **Studio Property Fix:** Updated `web_studio` property parsing to use `Number()` instead of `JSON.parse` for numeric values. This prevents errors when handling numeric strings with leading zeros (e.g., "032"). * **Test Alignment:** Updated the OWL tests to use the new `.o_field_selection_badge` class name for waiting and selectors, ensuring the test suite remains green. * **Compatibility:** Maintained the existing `icon_mapping` and `size` options, which are now natively supported by the core widget. **Task-5270283** **Related Community PR:** odoo/odoo#243855
This update fixes a technical error preventing managers without appraisal rights from scheduling meetings. The issue stemmed from access restrictions related to employee data. The fix simplifies the process by directly using the employee's work contact information instead of the problematic related partner ID.
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
A bug was preventing users from correctly saving approval rules with specific domain filters in the web studio. This was caused by a mismatch in how data was represented between Python and JavaScript. The fix ensures that domain filters are saved accurately, allowing users to properly configure email approvals.
Original PR description
Steps to reproduce ================== - Install web_studio,sale_management - Open a form view in sale - Open studio - Click on the "Send by email" button - Add an approval rule - Add a domain by clicking on the filter icon - Use the not set operator - Confirm - Click on the filter icon again - Confirm => ValueError: malformed node or string on line 1: <ast.Name object at 0x79ff4c7b7f50> Cause of the issue ================== JSON.stringify was used to pass the domain as a string to the DomainSelectorDialog. This doesn't work for boolean as they don't have the same representation in JavaScript as opposed to Python. Solution ======== Use the Domain().toString function opw-5923585 Forward-Port-Of: odoo/enterprise#108595 Forward-Port-Of: odoo/enterprise#107432
This update resolves an issue where payment reference data from the Codabox integration was incorrectly formatted, often with leading or trailing spaces. The change automatically removes these spaces before creating reco models, ensuring accurate data processing and preventing potential errors in financial reporting. This improves the reliability of bank statement imports.
Original PR description
Before this commit, when we do the creation of the automatic reco models, it was possible that the payment ref ended with a lot of empty spaces. To avoid that, we now strip the payment ref before the creation of the reco model. Data coming from codabox where wrongly formatted since the payment ref could have space at the end or the start and even in the middle. By using a split join we solve that issue. task-5926548 Forward-Port-Of: odoo/enterprise#107421
This update resolves an issue where test applications for new hires were failing due to missing applicant name information. The team has added required partner_name values to the test cases, ensuring data integrity and preventing errors during application creation. This improves the reliability of our recruitment testing process.
Original PR description
In the related community PR, we are making the partner_name as required. So need to give the partner_name values in the test cases while creating the `hr.applicant` to resolve the not null violations Community PR:- https://github.com/odoo/odoo/pull/203222 sentry-6409185730
This update corrects a display issue in the chat window where the agent's subtitle was not appearing correctly when the agent description was blank. The fix adds a default message to ensure the subtitle is always visible, improving the user experience. This resolves a previous display problem.
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#108948 Forward-Port-Of: odoo/enterprise#106949
This update fixes an issue where social security numbers were incorrectly displayed across different company views in Odoo. The change restricts SSN visibility to only appear within the specific country's company records, ensuring data privacy and compliance. This improves data accuracy and reduces potential reporting errors.
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 Forward-Port-Of: odoo/enterprise#108903
This update fixes a bug that prevented accurate payment advice reports when employees had multiple bank accounts. The team verified all bank accounts and BIC codes to ensure the system correctly generates reports, even with secondary bank information. 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 Forward-Port-Of: odoo/enterprise#109002 Forward-Port-Of: odoo/enterprise#107283
This update fixes a warning generated during testing of document attachments. The team replaced artificial PDF content with a standard, minimal PDF file used for testing, ensuring consistent and reliable test results. This resolves a technical issue that could have impacted the stability of the document processing features.
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 Forward-Port-Of: odoo/enterprise#108779
6 changes
Resolved issues and error corrections
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 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 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
5 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 ensures the cash drawer opens automatically when the cash details popup is opened in the Italian Point of Sale (POS) system. Previously, this functionality was missing, causing a discrepancy between the fiscal printer and cash drawer behavior. This fix resolves an issue where closing and reopening the PoS session was required to trigger the cash drawer opening.
Original PR description
When opening the cash details popup the cash drawer should be opened. It was not the case for the Italian fiscal printer. Steps to reproduce: ------------------- * Setup a Italian fiscal printer with cash drawer support * Open PoS * Open the cash details popup > Observation: The cash drawer does not open * Try to close the PoS session * Open the cash details popup > Observation: The cash drawer opens Why the fix: ------------ The cash drawer opening function was simply not called opw-5391094
This update fixes a data issue in the Danish demo company setup within Odoo. Specifically, the street number was missing, which was preventing proper functionality with Nemhandel (the Danish e-commerce payment system). This change ensures accurate data for testing and demonstration purposes.
Original PR description
This commit adds the street number to the DK demo company, because we need it for nemhandel. no-task
This update corrects a display issue in the website editor where the 'Custom URL' field incorrectly appeared on certain pages. The fix ensures this field only shows when the page URL contains a customizable slug, preventing confusion and ensuring accurate SEO settings. This improves the user experience for website administrators.
Original PR description
This PR hides the "Custom Url" field in the "Search Engine Optimization" when the URL of the current page do not contain any editable slug. Previously, this field could be filled when the URL did not contain any modifiable slug. However, the value was not take into account since the route of the page did not expect slug. Reproduce: With an admin user, activate the website editor on an appointment page. Clicking on "Optimize SEO" in the "Site" dropdown menu, a form containing the "Cutsom Url" field is displayed. This field should represent the current page's URL but with fillable field instead of the editable URL part. In this case, this is not correct as the URL is repeated before and after the fillable field, which does not represent the current URL. Also, the URL is not modified with the value entered in the fillable field. After the fix: The "Custom Url" field must not be displayed when URL does not contain a customisable slug. Task-5114394
This update resolves a bug that caused a 500 error in the portal when users attempted to edit company information without specifying a country. The fix handles the situation where a company record lacks a country association, preventing a calculation error that triggered the issue. This ensures a smoother experience for all users.
Original PR description
How to reproduce:
- Create a company with no country
- Set a contact's company to that company
- Grant portal access to that contact
- Login as that contact
- Go to the edit information tab
- Leave some of the required fields (Phone, Street & City) empty
- Click on save
The problem:
The page displays an error 500
Why:
When you try to submit the form with some required field missing, the page will try to evaluate this expression : 'int(country_id)''. But since this commit (https://github.com/odoo/odoo/commit/d6d6bee087fe2d3dc17974054353430c2662aecf), the post variable country_id is set to "False" if the partner has no country. 'int("False")' will then raise an error.
opw-5867975
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#2477619 changes
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
This update resolves a bug that occurred when users clicked the status bar on Follow-up Reports after excluding certain records. The issue stemmed from a missing data field within the system, preventing proper report rendering. This fix adds a check to ensure the necessary data is present before processing, improving report stability.
Original PR description
This traceback occurs when the user clicks on the `statusbar` of `followup reports` by excluding all `aml's`. To reproduce this issue:- 1) Install `Accounting` 2) Open the `Follow-up-report` from…
This traceback occurs when the user clicks on the `statusbar` of `followup reports`
by excluding all `aml's`.
To reproduce this issue:-
1) Install `Accounting`
2) Open the `Follow-up-report` from `dropdown menu` of
`Customer Invoices` in `accounting onboarding dashboard`.
3) Open any one record by removing the default filter
4) Enable the `Exclude from follow-ups` for all `aml's`
5) Now click on the `status bar`
Error:-
```
KeyError: 1
File "odoo/http.py", line 2256, in __call__
response = request._serve_db()
File "odoo/http.py", line 1832, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1852, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1830, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1837, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2062, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 742, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 38, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/web/models/models.py", line 76, in web_save
return self.with_context(bin_size=True).web_read(specification)
File "addons/web/models/models.py", line 129, in web_read
vals = many2one_data[values[field_name]]
```
When the user `Excludes` all the `Followups` and clicks on the `status-bar`,
the `web_read` method triggers with a record of `res.partner` having no `followup_line_id`.
Because of that, there will be no `many2one_data` as `extra_fields` are `{}`
values_list is also empty for the recursive call of many2one_data as `co_records` is also
having no recordsets.
Which leads to an exception from the below line (128).
https://github.com/odoo/odoo/blob/0d1399d06bd5ab30918b1a84abccb0f44504a508/addons/web/models/models.py#L116-L128
After applying this commit, it will resolve this issue by adding an extra check of "many2one_data" before assigning the value from many2one_data. Which makes the code more robust.
sentry-4982604710This update resolves a technical issue that prevented users from correctly attaching receipts to expense records. Specifically, a bug caused an error when a user canceled the attachment process. The fix ensures the system handles this cancellation gracefully, preventing a crash and improving the user experience.
Original PR description
A traceback is occurring when the user tries to attach a receipt in the expense To reproduce this issue: 1) Install `hr_expense` 2) Open any existing `my expense` record 3) Click on the `Attach Receipt` button and attach a file 4) Now again attach a file through the `Attach Receipt` button 5) This time click on `cancel` while attaching a file through `Attach Receipt` Error:- ``` IndexError: list index out of range ``` When the user clicks on the cancel button when trying to attach a file, it triggers an `orm` call with `attachments` as an empty list with respected `model` & `action`. Which leads to the above traceback in the backend. After applying this commit, will resolve this issue by checking the length of the file before triggering the form. Which makes code more robust. sentry-4705156379
This update resolves an issue where new sale orders were created without a specified Incoterm. The change ensures that the company's default Incoterm is automatically applied when a new sale order is created, streamlining the sales process and improving data consistency. This prevents manual entry of Incoterms and reduces potential errors.
Original PR description
Currently, when creating a new sale order Incoterm value remains empty. <b>Steps to reproduce:</b> 1) Install sales, stocks, and enable incoterms for sales in settings 2) Give the default Incoterms value in the settings 3) Try to create a new SO record <b>Issue:-</b> Even after providing the default incoterm value in the settings, The value of incoterm remains empty while creating the SO. <b>Solution:-</b> Give the company incoterm value as the default incoterm in the definition of incoterm in sale order. opw-4700346
This update fixes a bug that occurred when users entered a maximum appointment duration. The issue caused a system error due to an overly large number being processed. This change ensures the system can correctly handle maximum duration values without crashing, improving the user experience when scheduling appointments.
Original PR description
A traceback occurs when the user gives a maximum duration value while updating an appointment. To reproduce this issue: 1) Install appointment 2) Open an appointment record from the grant view of the calendar event 3) Give the maximum duration value 4) Click on preview Error:- ``` OverflowError: Python int too large to convert to C int ``` This is because when the user gives a maximum duration value, it calculates the time from the below. https://github.com/odoo/enterprise/blob/e74b05fa7a777053fd0e2cd5a265de365e1e434a/appointment/models/appointment_type.py#L623-L624 This leads to the above traceback because of the duration value sentry-5926537828
This update resolves an issue where creating a new appointment with the maximum allowed duration caused a system error. The fix prevents an 'OverflowError' by correctly handling large duration values, ensuring users can accurately set appointment lengths without disrupting the system. This improves the appointment scheduling process.
Original PR description
A traceback occurs when the user gives a maximum duration value while creating a new calendar event. To reproduce this issue: 1) Install appointment 2) Create a new appointment from the Gantt view 3) Give the maximum duration value Error:- ``` OverflowError: Python int too large to convert to C int ``` This is because when the user gives a maximum duration value it is used to calculate the time from the below. https://github.com/odoo/odoo/blob/a4c46f358401077a65106a6172b2a636755d41aa/addons/calendar/models/calendar_event.py#L369 This leads to the above traceback because of the duration value sentry-5926537828
This update resolves a bug that caused an error when users attempted to access the website after deleting all websites within the Odoo system. The fix ensures a minimum website requirement is maintained, preventing the 'ValueError: Expected singleton: website()' error. This improves website functionality for all users.
Original PR description
Currently, a traceback occurs when the user deletes all the websites and tries to open the website. To reproduce this issue: 1) Install the website 2) Delete the default website from external identifiers in settings/technical 3) Now delete all websites from website/configuration/websites 4) Tries to access or open the website Error:- ``` ValueError: Expected singleton: website() ``` Initially, there is a check for at least one website while uninstalling the websites, But after the below commit the code is changed only to check for the default website. But if the user deleted the external identifier of the default website and deleted all the websites it leads to a traceback. https://github.com/odoo/odoo/pull/113405/commits/60adaf5632ddfe3f68da369a2e9642ad639da37e After applying this commit, it will resolve this issue by ensuring at least one website is required. sentry-5900356108
This update corrects a technical issue that prevented users from uploading files without a name, resulting in a traceback error. By providing a default value, the system now handles this scenario gracefully, ensuring a smoother user experience.
Original PR description
Currently, a traceback may arise when the user uploads a file with no name. Error:- ``` TypeError: Web_Editor.add_data() missing 1 required positional argument: 'name' ``` When the value of the `name` we get from the RPC call is `undefined`, we get this traceback on the backend. If there is no `name`, this case is already handled in the python side https://github.com/odoo/odoo/blob/6838782baf222db4591edce5fe80f5af3a39810c/addons/web_editor/controllers/main.py#L261-L266 So by just giving the fallback value if there is no name, we can resolve this issue. sentry-5741581459
This update resolves a technical issue that caused a traceback when users removed the UOM from Sale Order Lines. The fix ensures the UOM is correctly handled during price calculations, preventing errors and improving data accuracy. This impacts the pricing of sales orders.
Original PR description
Currently, a traceback occurs when the user removes the UMO from the Sale Order Line. To reproduce this issue: 1) Install `sale` 2) Enable `UOM`, and `Pricelist` with advanced rules from sales…
Currently, a traceback occurs when the user removes the UMO from the Sale Order Line. To reproduce this issue: 1) Install `sale` 2) Enable `UOM`, and `Pricelist` with advanced rules from sales configuration 3) Create a new pricelist with a `price rule` of `discount` and make sure to change the `discount policy` to `without_discount` from the pricelist configuration 4) Now create a new `Quotation` with the pricelist 5) Remove the `UOM` from the Order Lines and update the Quantity Error:- ``` ValueError: Expected singleton: uom.uom() ``` When the user removes UOM from the SOL it triggers a compute method `_compute_discount` through which another method `_get_pricelist_price`. https://github.com/odoo/odoo/blob/d83bd4f8970e5495205cf2fa583d9343368b5d70/addons/sale/models/sale_order_line.py#L518-L522 In the second method, UMO is used to compute the price for the `pricelist item`, but in that `_compute_price`, `uom.ensure_one()` is used. Which leads to the above traceback. https://github.com/odoo/odoo/blob/d83bd4f8970e5495205cf2fa583d9343368b5d70/addons/product/models/product_pricelist_item.py#L362-L364 By applying this commit will resolve this issue by taking UOM from product, which is a required field in product. sentry-5537497781