Daily updates from Odoo
Friday, February 27, 2026
59 changes · saas-19.1
Resolved issues and error corrections
This update resolves an issue where the tax report export button wouldn't work correctly when companies had different VAT numbers and branches. The fix ensures the button recognizes and processes all companies within the branch hierarchy, allowing users to export reports accurately. This improves the functionality of the tax reporting feature.
Original PR description
To reproduce the issue: - Create a company with a branch - Give the company and its branch different VAT numbers - Make both companies active in the company selector - Open the tax report - Click on gear icon - Click on the XML(l10n_lu_reports)/Export SAWT & QAP(l10n_ph_reports) button ===> The following error is raised: "Please select the main company and its branches in the company selector to proceed." This is because the tax report's options only consider one of the two companies (because they have different VAT numbers). The button is not declared as branch_allowed, so when clicked, it checks whether all the companies of the branch hierarchy are in the options => they're not => error. We can fix this by simply making the buttons branch_allowed. Followup on: https://github.com/odoo/enterprise/commit/34ba0609e984496f0dcc862f0d7a46c6721beab9 task-5416330 Forward-Port-Of: odoo/enterprise#105961
This update resolves a build error in the payroll accounting module related to how warning tests are run. The previous test incorrectly counted employees, failing when multiple employees triggered the same warning. The fix now accurately checks for the number of times an invalid employee ID appears in the warning data, ensuring the test functions correctly.
Original PR description
> To be FW'ed till `saas~19.1` only. issue: - the test written in commit 0653104 checks the employees' count in warning from `warning_data` dictionary - which will not work in case of multiple employees fulfilling that warning as the warning searches models' data, instead of just test data. fix: - instead of relying on `warning_data['count']` for invalid employee, checked how many times does the invalid employee's ID appear in the `warning_data`. runbot-240910 task-5958862 Forward-Port-Of: odoo/enterprise#108242
This update resolves a technical error that prevented the generation of Dutch tax reports. The issue stemmed from a misunderstanding of how data was being processed, specifically related to a boolean flag within the report's data structure. This fix ensures accurate report generation for Dutch users.
Original PR description
After this [commit](https://github.com/odoo/enterprise/commit/402ec47),…
After this [commit](https://github.com/odoo/enterprise/commit/402ec47), [ec_sales_list_tag_ids](https://github.com/odoo/enterprise/blob/c6b8727b9c926a4f817249b94cfc24dcbd66147f/l10n_nl_reports/models/account_return.py#L21) is built by flattening the values of `ec_sales_list_tags_info` using `chain(*values())`.
The tag IDs are fetched from[ _get_tax_tags_for_nl_sales_report()](https://github.com/odoo/enterprise/blob/c6b8727b9c926a4f817249b94cfc24dcbd66147f/l10n_nl_reports/models/account_sales_report.py#L75), which returns a dictionary containing:
- a flag (`use_taxes_instead_of_tags = False`)
```.py
(Pdb) ec_sales_list_tags_info
{'goods': [67], 'services': [71], 'triangular': [69], 'use_taxes_instead_of_tags': False}
```
When flattening the dictionary values, `chain` expects all values to be iterable. While the boolean flag is not iterable,
which results in a `TypeError: 'bool' object is not iterable`.
```.py
Traceback (most recent call last):
File "/home/odoo/src/odoo/19.0/odoo/service/server.py", line 1510, in preload_registries
registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'], reinit_modules=config['reinit'])
File "/home/odoo/src/odoo/19.0/odoo/tools/func.py", line 88, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/19.0/odoo/orm/registry.py", line 199, in new
load_modules(
File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 493, in load_modules
migrations.migrate_module(package, 'end')
File "/home/odoo/src/odoo/19.0/odoo/modules/migration.py", line 220, in migrate_module
exec_script(self.cr, installed_version, pyfile, pkg.name, stage, stageformat[stage] % version)
File "/home/odoo/src/odoo/19.0/odoo/modules/migration.py", line 257, in exec_script
mod.migrate(cr, installed_version)
File "/tmp/tmpzg7oi478/migrations/account_reports/saas~18.3.1.0/end-account-returns.py", line 341, in migrate
generate_or_refresh_all_returns(company)
File "/home/odoo/src/enterprise/19.0/account_reports/models/account_return.py", line 232, in _generate_or_refresh_all_returns
self._generate_all_returns(fiscal_country.code, company, domestic_tax_unit)
File "/home/odoo/src/enterprise/19.0/l10n_nl_reports/models/account_return.py", line 22, in _generate_all_returns
ec_sales_list_tag_ids = list(chain(*ec_sales_list_tags_info.values()))
TypeError: 'bool' object is not iterable
```
In this fix, the boolean flag is removed before chaining since only tag ID lists are needed and the flag causes an error.
Forward-Port-Of: odoo/enterprise#107213This update ensures that opening notes are consistently saved to the system's session data, regardless of whether the cash payment method is enabled. Previously, this functionality was missing when the cash method wasn't configured, leading to potential data loss. This change improves the reliability of POS note recording for all users.
Original PR description
Before this commit: -------------- - When the cash method was not available for config, opening notes values were not being stored in session data. After this commit: -------------- - Opening notes values will be stored in session data even when the cash method is not available for config. task-5474822 Forward-Port-Of: odoo/odoo#249953 Forward-Port-Of: odoo/odoo#243956
This update fixes an issue where the 'Packages' report combined all package details onto a single page, causing confusion and potential mislabeling. Now, each package's information is printed on a separate page, allowing for clear and accurate handling during packing and logistics.
Original PR description
Issue before this PR: ========================= - Currently, when printing a `Packages` report that contains `multiple packages` all `Package with Content` reports are printed as a `single continuous…
Issue before this PR: ========================= - Currently, when printing a `Packages` report that contains `multiple packages` all `Package with Content` reports are printed as a `single continuous document` without any line or page separation between packages. - This leads to issues because each `Package with Content` report is meant to be printed individually and physically attached to its corresponding package during packing and logistics operations. It creates `confusion and a risk of mislabeling`, as users must `manually interpret and separate package boundaries` when handling printed documents. Steps to Reproduce: ========================= 1. Install the `Inventory` app. 2. Go to Configuration → Settings and enable the `Packages` option. 3. Create a new transfer with multiple product lines and click `Mark as Todo`. 4. In Detailed Operations, assign `different packages` to at least two different product lines and `Validate` the transfer. 5. Open the `Actions` menu, select `Print → Packages`. 6. Open the generated PDF. All packages are printed on the same page, without any page or line separation. **Packages report before this PR:** <img width="500" height="300" alt="combined" src="https://github.com/user-attachments/assets/6a6b8cb5-bcf3-488e-b95a-7670db8fc6ad" /> Cause of the issue:- ========================= In the file `report_package_barcode.xml`, a `t-foreach` loop is used to iterate over the packages included in the report. However, the report template does not define any `page break or visual separation` between iterations. As a result, each package is rendered consecutively in a single, continuous page instead of being split into separate pages. After this PR:- ========================= This PR ensures that, when printing a `Packages` report containing `multiple packages`, each `Package with Content` starts on a new page. This clear separation allows users to easily identify and handle `individual package details`, reducing confusion and the risk of mislabeling, while preserving the existing report layout and content. **Packages report after this PR:** <img width="491" height="500" alt="breaked (1)" src="https://github.com/user-attachments/assets/d87a52e5-8b54-49d4-911a-2e07e487c0d8" /> TaskID-5025192 Forward-Port-Of: odoo/odoo#241762
This update corrects a bug where archived subtasks were unintentionally copied when duplicating a task. Previously, the system didn't check if a subtask was inactive before duplication, leading to unnecessary data duplication. Now, archived subtasks are excluded from the duplication process, streamlining task management.
Original PR description
Currently, when duplicating a task that contains `archived subtasks`, the archived subtasks are also duplicated. **Steps to reproduce:** - Install the `project` module. - Open any `project` and create a task with a subtask. - `Archive` the subtask. - `Duplicate` the parent task. **Observation:** The duplicated task contains a copy of the archived subtask, even though it is inactive. **Root Cause:** At [1], subtasks are duplicated without checking their active status. As a result, archived (`active=False`) subtasks are also copied during duplication. **Fix:** This commit ensures that archived subtasks are not copied when duplicating a task. [1]: https://github.com/odoo/odoo/blob/531b887aec92c2fbf57495992be9fbc32d9ea20e/addons/project/models/project_task.py#L822 opw-5926009 Forward-Port-Of: odoo/odoo#250901 Forward-Port-Of: odoo/odoo#248167
This update fixes an issue where payment advice reports weren't properly handling employees with multiple bank accounts. The fix ensures that invalid bank information (BICs) in non-primary accounts no longer allows the creation of incorrect payment advice reports, improving data accuracy and compliance.
Original PR description
steps to reproduce: - install `l10n_in_hr_payroll` - create an employee, with multiple bank accounts - add invalid BIC in one of the bank accounts with isn't primary - notice that you will still be able create the advice report with invalid data. issue: - after the support of multiple bank accounts, the payment advice methods were not adapted with it. fix: - checked all the banks and their BIC. task-5890497 Forward-Port-Of: odoo/enterprise#107283
This update fixes an issue where input fields would overflow due to inconsistent sizing calculations across different browsers, particularly Safari and Firefox. The change dynamically adjusts for padding and borders, ensuring correct sizing and preventing visual glitches for users.
Original PR description
Before this PR, `autoresizeInput` used a fixed buffer of `5px` to compensate for input borders. This caused incorrect sizing when inputs had thicker borders, leading to overflow issues. Safari 16 and…
Before this PR, `autoresizeInput` used a fixed buffer of `5px` to compensate for input borders. This caused incorrect sizing when inputs had thicker borders, leading to overflow issues. Safari 16 and earlier versions did not include padding and border in `scrollWidth`. To work around this, browser detection via regex was used to add a hardcoded extra value. A similar issue appeared in Firefox 145, where scrollWidth also excluded padding and border, causing inputs to overflow again. After this PR, The buffer is no longer hardcoded. The border width is now calculated dynamically and applied correctly to the final width. Browser sniffing has been removed entirely. Instead, the logic detects at runtime whether scrollWidth includes padding; if not, the missing padding is added to the computed width. This makes the behavior consistent across browsers and prevents overflow without relying on user agent checks. task-[5412025](https://www.odoo.com/odoo/project/1519/tasks/5412025) Forward-Port-Of: odoo/odoo#250723 Forward-Port-Of: odoo/odoo#241315
This update prevents incorrect data from being written to applicant records when CVs are processed via OCR. Specifically, it corrects data corruption that occurred when forwarding emails or linking applicants to existing business partners. This ensures accurate applicant information within the system.
Original PR description
When OCR processes a CV, it writes extracted name/email/phone onto the applicant, which then propagates to the linked res.partner via the email_from inverse. This causes data corruption in two cases: - The CV was forwarded: the OCR email belongs to the candidate but email_from is the forwarder's address. Writing OCR data would overwrite the forwarder's partner with the candidate's details. - The existing partner is a company contact (parent_id set) or is linked to a user account (user_ids set). Writing OCR data would overwrite user/business partner with the candidate's details. Both guards are applied and added tests that check the flows. task-5949635 Forward-Port-Of: odoo/enterprise#108128
This update resolves a bug where image sizes were being unintentionally reduced during rotation within the HTML editor. The fix ensures that padding around images is correctly accounted for, maintaining the intended image size and appearance. This improves the user experience when working with images in website content.
Original PR description
**Current behavior before PR:** Steps to reproduce: - In website, drag and drop a `text - image` snippet. - Click on image, click on Transform button. - Try to rotate the image. - You will notice that the size of the image is reduced a bit. This issue happens because in `image_transformation.js`, `convertPixelWidthToPercentage` converts image width from `px` to percentage. In this case image's parentElement has padding, causing reduction in image's size. **Desired behavior after PR is merged:** This PR ensures that `paddingLeft` and `paddingRight` of image's parentElement is ignored from calculation so that image size doesn't get changed. task-5884679 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246508
This update enhances how Odoo recognizes structured bank transactions from Belgium (VCS-OGM). Previously, transactions without a leading '+' or '*' were not correctly identified as structured. Now, Odoo can properly process transactions formatted as 'xxx/xxxx/xxxxx', ensuring accurate financial reporting and record-keeping.
Original PR description
The aim of this commit is handling the case where the Belgian VCS-OGM is not starting with + or *. Before this commit, transactions without one of these 2 characters wasn't marked as structured. With this commit, we do handle this format as well: xxx/xxxx/xxxxx task-5403947 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250665
This update addresses several technical issues within the Hoot component of Odoo, enhancing its reliability and performance. Specifically, it corrects a problem with how blob responses are handled, resolves an issue with test results, and limits a potentially problematic configuration option. These changes ensure smoother operation and data integrity.
Original PR description
### [FIX] web: Hoot - backport fixes This commit backports the following fixes that have been applied in further versions: - add correct mime type to XHR blob responses [1]; - fix missing diff from failed test results [2]; - wrap 'raw' value option in a dictionnary to limit unintended use, use 'raw' as a default for text-based matchers [3]. [1] 9156bf1 [2] 2216a0b [3] 3080362 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250929
This update resolves an issue where action buttons on the work entry Gantt view would cause errors when no employees were assigned. The fix now automatically hides these buttons when there are no employees present, preventing unexpected errors and improving the user experience.
Original PR description
On gantt view of work entries when user multi-selects entries, action buttons appears Ex. Set, Reset etc. When their are no employees in the column, on clicking these action buttons gives traceback. Ex:- `TypeError: Cannot read properties of undefined (reading '0')` or `KeyError: 'employee_id'` This fix will hide these buttons when there are no employees present. task-[5445718](https://www.odoo.com/odoo/project/1251/tasks/5445718) Forward-Port-Of: odoo/enterprise#105957
This update corrects a minor issue in the Attendance module where duplicate field names were appearing in the attendance list view. Specifically, the 'in_location' and 'out_location' fields had redundant names. This change ensures a cleaner and more user-friendly experience when managing attendance data.
Original PR description
Steps to reproduce: -------------------------------------- 1. Install the Attendance module 2. Go to the attendance list view 3. Click on the optional fields tray Observation: -------------------------------------- Duplicate field name Longitude (In) Issue: -------------------------------------- For the `in_location` field, a duplicate string was added in the list view Solution: -------------------------------------- Changed string to `Location (In)` for `in_location` field and changed string to `Location (Out)` for `out_location` field Before: <img width="348" height="511" alt="image" src="https://github.com/user-attachments/assets/109ff380-df4f-4dc6-ad01-a955d85436c7" /> After: <img width="330" height="503" alt="image" src="https://github.com/user-attachments/assets/894e6045-ec34-4296-8aff-f0e7bee32d9f" /> opw-5909500 Forward-Port-Of: odoo/odoo#249404
This update ensures that Point of Sale orders always use the correct date from the server, regardless of the date displayed on the POS device. Previously, incorrect date settings on the POS could lead to inaccurate order timestamps. This change improves data accuracy and reliability for all Point of Sale transactions.
Original PR description
Before this commit, if the PoS device had a wrong date, the orders created while being online would have a wrong date_order. This commit prioritizes the server date for the order that is currently being processed when the PoS is online. opw-5884498 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248897
This update resolves a technical glitch in the product catalog search panel that was causing the system to crash. The fix addressed a race condition in how data was loaded, preventing errors when users searched for products. This ensures the search functionality operates reliably.
Original PR description
- `PurchaseStockProductCatalogSearchModel._fetchSections()` was calling `super._fetchSections()` without `await`, causing `sectionsPromise` to resolve immediately before sections finished loading.…
- `PurchaseStockProductCatalogSearchModel._fetchSections()` was calling `super._fetchSections()` without `await`, causing `sectionsPromise` to resolve immediately before sections finished loading. This made `expandDefaultValue()`, `expandValues()`, and `updateActiveValues()` run with empty sections in `onWillStart`, leaving `state.expanded` and `state.active` uninitialized and causing a crash when the template accessed `state.expanded[section.id][valueId]`.
```
UncaughtPromiseError > OwlError
Uncaught Promise > An error occured in the owl lifecycle (see this Error's "cause" property)
Occured on 127.0.0.19:8069 on 2026-02-24 10:16:04 GMT
OwlError: An error occured in the owl lifecycle (see this Error's "cause" property)
Error: An error occured in the owl lifecycle (see this Error's "cause" property)
at handleError (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:762:101)
at App.handleError (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:1420:29)
at Fiber._render (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:787:19)
at Fiber.render (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:785:6)
at ComponentNode.initiateRender (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:855:47)
Caused by: TypeError: Cannot read properties of undefined (reading '1')
at PurchaseSuggestCatalogSearchPanel.template (eval at compile (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:1375:421), <anonymous>:25:69)
at App.callTemplate (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:1011:129)
at PurchaseSuggestCatalogSearchPanel.template (eval at compile (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:1375:421), <anonymous>:85:15)
at PurchaseSuggestCatalogSearchPanel.template (eval at compile (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:1375:421), <anonymous>:138:34)
at PurchaseSuggestCatalogSearchPanel.template (eval at compile (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:1375:421), <anonymous>:19:29)
at Fiber._render (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:786:96)
at Fiber.render (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:785:6)
at ComponentNode.initiateRender (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:855:47)
```
- `purchase_stock.ProductCatalogSearchPanelContent` had a broken xpath: a `<t t-if>` element inside `<xpath position="attributes">`. OWL's `modifyAttributes()` silently skips non-`<attribute>` children, so the conditional class was never applied. Replaced with a proper `t-att-class` ternary binding.
Forward-Port-Of: odoo/odoo#250810This update prevents employees from checking in through the attendance app when location tracking is enabled and a location cannot be determined. This ensures accurate attendance records and avoids incorrect check-in data, improving the reliability of our time tracking system.
Original PR description
When a user is trying to check in on the attendance app with the setting Device tracking enabled and the location cannot be determined, it should raise an error to prevent the check-in without a valid location. Task: 5486178 Forward-Port-Of: odoo/odoo#249753
This update resolves a potential issue during Odoo database upgrades. Previously, removing a payroll rule could cause upgrade scripts to fail. This change ensures upgrade scripts continue to function correctly even if a referenced rule has been deleted, improving the reliability of database updates.
Original PR description
This method is used in various places, including when upgrading a database. When doing so, it is done in a post upgrade script. If later one of the updated rules is removed, the pre-script removing it will run before the post script trying to update it, causing the migration to fail as the update method tries to browse a falsy value. This updates the `update_properties_definition_domain` method so that it ignores falsy values when browsing, allowing previous upgrade scripts to run even if the referred rule has been since deleted. Forward-Port-Of: odoo/enterprise#102964
This update fixes a critical error in the calculation of employer costs for Swiss payroll. Previously, employer costs were incorrectly displayed as zero due to a missing flag. The update now accurately computes and displays these costs, ensuring accurate financial reporting and compliance for Swiss businesses using Odoo Enterprise.
Original PR description
The computation of the employer cost in Switzerland was wrong (always 0) because the rules didn't have the appears_on_employee_cost_dashboard flag set and were therefore not counted in the computation of the fiels. Furthermore we modify the override of the function used to compute the values of some fields, to add the correct computation of the employer cost. Task: 5354103 Forward-Port-Of: odoo/enterprise#106839
This update fixes a technical error preventing managers without specific permissions from scheduling meetings related to appraisals. The fix replaces a restricted data field with a simpler one, ensuring managers can now correctly schedule meetings as intended. This improves the user experience for all managers.
Original PR description
Steps to reproduce: - Create two employees: one as a manager and the other as a subordinate. - Ensure that the manager does not have any officer or appraisal rights. - Create an appraisal for the subordinate through the manager. - Confirm the appraisal and then click the Schedule Meeting button Issue: - The manager should schedule a meeting even though he does not have the rights, but a traceback error occurs due to access rights issues when trying to schedule a meeting. Reason: - The manager is unable to access the related_partner_id due to restrictions set by the officer/manager group, which results in a traceback error. Fix: - Replace the related_partner_id with the work_contact_id of the employee. Since related_partner_id is computed from work_contact_id, we can directly use work_contact_id task-5881127 Forward-Port-Of: odoo/enterprise#106106
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 error in the UAE Payroll localization module that incorrectly calculated pay rates for employees on attendance-based contracts. Previously, rates were based on actual work hours, but now they accurately reflect the planned working schedule, ensuring correct payroll processing for this contract type.
Original PR description
Step to Reproduce: - install UAE Payroll localization and attendance - create employee and running employee contract and give basic salary, housing, transportation and other allowance. - work entry…
Step to Reproduce: - install UAE Payroll localization and attendance - create employee and running employee contract and give basic salary, housing, transportation and other allowance. - work entry source should be attendance - create a payslip and compute sheet. Issue: - The values for payslip lines are not as expected. - The rate per hour for basic salary , housing, transportation and other allowances was being calculated based on employee's attendance work entries, not the planned working schedule. Reason: - When using attendance-based contracts, the hourly rates for basic salary, housing, transportation, and other allowances should be calculated based on the working schedule's hours per day, if a working schedule is available. Solution: - Instead of sum_worked_hours which takes working hours of employee's work entries, use total_number_of_days multiplied by the hours per day from the working schedule. task-5270185 Forward-Port-Of: odoo/enterprise#108637 Forward-Port-Of: odoo/enterprise#103282
This update fixes an issue 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 update fixes an issue where deleting a partially signed offer would incorrectly delete the associated employee. The fix ensures the employee record remains intact unless the offer is fully archived and the employee has no other active offers. This prevents data loss and maintains accurate employee records.
Original PR description
Version – saas-18.4 ### Issue: When an applicant has both a partially signed offer and a fully signed offer, deleting the partially signed one also deletes the employee that was created from the…
Version – saas-18.4 ### Issue: When an applicant has both a partially signed offer and a fully signed offer, deleting the partially signed one also deletes the employee that was created from the fully signed offer. ### Steps to Reproduce: - Create two offers for an applicant. - Fully sign the first offer and partially sign the second one. - Delete the partially signed offer. The employee created from the fully signed offer is also deleted. ### Cause: Due to this issue, the employee record is incorrectly deleted from the system, which is not expected behavior. ### Fix: Improved the employee deletion logic by deleting the employee only when: - the employee is archived, and - they do not have any other offers besides the one being deleted. ### Impact: The employee will no longer be deleted when another partially signed offer for the same applicant is removed. --- Task – 5347109 Forward-Port-Of: odoo/enterprise#108634 Forward-Port-Of: odoo/enterprise#100991
This update ensures overtime calculations are correct when creating or modifying time off requests. Specifically, the system now automatically recomputes overtime when a time off record is created or changed, even if an existing attendance record exists, improving the accuracy of payroll processing.
Original PR description
If you don't have time off app, the option Timing - when Employee is off, should not be available. Creating a time off on a day when there is already an attendance record should automatically recompute the overtime if this rule is on the employee. Forward-Port-Of: odoo/odoo#240940
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 fixes an issue where dependent salary rules weren't appearing in the employee input selection. The change ensures that all relevant rules, including dependent ones, are displayed when adding inputs, streamlining payroll configuration for users. This prevents errors and ensures accurate payroll calculations.
Original PR description
Problem ------------------ The salary inputs selection widget only displays the main salary rule, not the dependent rules, so when a new dependent rule is created after the main one was added to the…
Problem ------------------ The salary inputs selection widget only displays the main salary rule, not the dependent rules, so when a new dependent rule is created after the main one was added to the employee form, it is not possible to select the the new rule to display. Navigation: 1. Payroll > Configuration > Rules > New > Condition Based On: Salary Input > Input On: Employee > Save 2. Employees > Select Employee > Payroll > Add Inputs > Select Rule > Save 3. Configuration > Rules > New > Condition Based on: Salary Input > Input On: Employee > Depends On: Previous Rule > Save 4. Employees > Select Employee > Payroll > Add Inputs > New Rule is not available Objective ---------------------- Version 19.0 doesn't filter out existing rules, so it is possible to select the prerequisite rule again and add the new dependent rule, but later commits changed the search domain to filter out inputs that were already selected. Some of the changes should probably have been included in the 19.0 version. Need to back port the changes and edit the search domain to show dependent rules that have not been selected yet. Solution --------------------------- Option B from the task specifications to show the dependent salary rules when "Add Inputs" is clicked if it's not already displayed even if the prerequisite rule is displayed. Edited the payroll structure search domain to find rules that are not displayed and either do not have prerequisites OR have a prerequisite that is already displayed. Task: 5942461 Forward-Port-Of: odoo/enterprise#107719
This update optimizes how Odoo's Point of Sale system synchronizes data using IndexedDB. Previously, large datasets like loyalty cards could cause slow synchronization, leading to delays when adding items to a customer's cart. This change significantly improves the speed and responsiveness of the Point of Sale experience.
Original PR description
Before this commit, if a model had a large number of records, for example, loyalty card, the synchronization of IndexedDB could be slow, leading to performance issues when adding products to the cart. opw-5232087 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250799 Forward-Port-Of: odoo/odoo#241373
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 resolves an issue where the correct currency wasn't consistently applied when transferring CODA transactions between multiple journals with the same IBAN but different currencies. The fix ensures that transactions are accurately routed to the appropriate journal based on its currency, improving financial reporting accuracy. This was a critical fix impacting multi-currency accounting.
Original PR description
When having multiple journals with the same IBAN, but different currencies, upon fetching and dispatching the CODA into the right journals, the currency of the journal was not correctly taken into account as the condition was incorrect. This commit fixes this condition which was introduced in [^1] such that the right journal, with the right currency is correctly chosen. [^1]: 4fda4fb5353ed9c14dbc023ab7d07fabd3c06e98 opw-5723017 Forward-Port-Of: odoo/enterprise#108677
This update resolves an issue preventing the SAF-T report from correctly displaying supplier names for fixed assets. The fix ensures that the report accurately identifies suppliers by incorporating depreciation lines alongside journal entries, addressing a discrepancy caused by bills being posted in a previous month.
Original PR description
**Steps to reproduce:** - Install l10n_ro_saft - Switch to a Romanian company (e.g. RO Company) - Create an asset model: * Method: Straight Line * Duration: 12 Months - Configure a "Fixed Assets"…
**Steps to reproduce:** - Install l10n_ro_saft - Switch to a Romanian company (e.g. RO Company) - Create an asset model: * Method: Straight Line * Duration: 12 Months - Configure a "Fixed Assets" account: * Automate Asset: Create and validate * Asset Model: [the asset model created above] - Create a bill: * Vendor: [create a new vendor] * Bill Date: [last month] * Invoice Line: [A line with the fixed asset account] - Confirm the bill - Go to "Accounting / Reporting / Audit Reports / General Ledger" - Select the current month (The fixed asset account should be present) - In the cog menu, select "SAF-T (D406 Asset Declaration)" **Issue:** A traceback is raised while trying to display the name of a supplier. **Cause:** To display the supplier name of an asset, a dict having the id of the customer or supplier as key (i.e. partner_detail_map) is used. This dict is build by getting the list of all partners linked to a posted journal item on an asset (or liability) account in the period of the report. In this case, it's the current month. However, the created bill has been posted the month before. So no journal item is found for the vendor that has been created just for the bill and therefore there is no key for him in the dict, which leads to the error when trying to get the id of the supplier of the asset in the dict. **Solution:** Instead of just fetching the posted entries linked to a receivable or payable account in order to get the list of the potential customers and suppliers, we also fetch the depreciation lines that are linked to an asset account and can still be in draft. opw-5499918 Forward-Port-Of: odoo/enterprise#108734 Forward-Port-Of: odoo/enterprise#105987
This update resolves an issue where AVCO valuations were incorrectly defaulting to a product's initial price when stock move dates were earlier than the product's creation date. The fix ensures that actual stock movements always take precedence in AVCO calculations, providing more accurate inventory valuation.
Original PR description
**Issue**: If the date of some stock moves is anterior to the creation date of the product in the database, the associated valuation is replaced by the initial standard price of the product. **Steps…
**Issue**: If the date of some stock moves is anterior to the creation date of the product in the database, the associated valuation is replaced by the initial standard price of the product. **Steps to reproduce**: - Create a new product with a standard price of 0 and AVCO cost method - Create a PO for that product with a unit cost of 1,000,000, confirm it and validate the receipt - Go to Accounting > Review > Inventory > Inventory Valuation -> Observe that the valuation correctly takes the purchase into account - Go back to the receipt, unlock it and change the effective date to one week in the past - Go back to Inventory Valuation -> Observe that the valuation no longer takes the purchase into account - Change the valuation date to yesterday -> Observe that the valuation takes it into account again **Cause**: When a product is created, a `product.value` record is instantiated with today’s date: https://github.com/odoo/odoo/blob/bbaf38aa99143be4679cf951c5c0f1a1c8ecf716/addons/stock_account/models/product.py#L174 https://github.com/odoo/odoo/blob/bbaf38aa99143be4679cf951c5c0f1a1c8ecf716/addons/stock_account/models/product.py#L202 In the AVCO computation, a manually set product value (`product.value`) takes precedence over move values when it is anterior, either here: https://github.com/odoo/odoo/blob/bbaf38aa99143be4679cf951c5c0f1a1c8ecf716/addons/stock_account/models/product.py#L309-L312 or here: https://github.com/odoo/odoo/blob/bbaf38aa99143be4679cf951c5c0f1a1c8ecf716/addons/stock_account/models/product.py#L334-L338 Since the stock move date is set one week in the past, the initial product value (0.0) takes precedence over the move valuation. When the valuation date is moved forward to yesterday, this initial product value is ignored and the move value is correctly applied again. **Solution**: Setting the initial `product.value` date to the product creation date is arbitrary, as it makes inventory valuation depend on when the product was encoded rather than on real stock history. Instead, set the date of the first `product.value` to the earliest possible epoch, ensuring that any real stock move always takes precedence in AVCO valuation. opw-5882080 Forward-Port-Of: odoo/odoo#247407
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 fixes an error in how holiday pay recovery is calculated for employees in Belgium with non-standard working schedules. Previously, the calculation used a default 38-hour week, leading to inaccurate deductions. The fix now uses the employee's actual weekly hours, ensuring correct holiday pay recovery amounts are applied.
Original PR description
**Steps to Reproduce:** 1 - create an employee in Belgium company with hourly rate 20.62 and 40h/week working schedule 2 - Set 10 paid time off to this employee 3 - Set 2000 euros in recovery amount…
**Steps to Reproduce:** 1 - create an employee in Belgium company with hourly rate 20.62 and 40h/week working schedule 2 - Set 10 paid time off to this employee 3 - Set 2000 euros in recovery amount holiday n-1 4 - Set 10 days in recovery day holiday n-1 5 - Employee takes 5 paid time off in February and 5 in December 6 - Do one payslip for this employee for February and validate it 7 - Do one payslip for this employee for December Current behaviour : - the holiday n-1 amount for February = 824.80 - the holiday n-1 amount for December = 742.32 Expected behaviour : - the holiday n-1 amount for December should be 20.62 (hourly_rate) * 5 (days) * 8 (hours) = 824.80 **Reason** - The daily recovery amount was calculated using hardcoded standard working hours (38h/week) instead of the employee's actual schedule (40h/week), causing an incorrect deduction rate for non-standard schedules. **Solution** - Replace the hardcoded reference with the actual hours per week from the employee's resource calendar to ensure the correct hourly rate is applied. Forward-Port-Of: odoo/enterprise#108784 Forward-Port-Of: odoo/enterprise#106205
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
This update enhances the accuracy of payment reference validation by checking against the bank account's country. Previously, a single check applied to all countries could lead to incorrect validations. Now, the system prioritizes country-specific rules, falling back to a standard check only when a country isn't supported, ensuring more reliable payment processing.
Original PR description
Currently, when initiating a payment, we check if the reference is a structured one by using `is_valid_structured_reference` which checks the validity of the structure accross all supported countries. This can lead to issues when it matches formats accepted by other countries but not the one of the bank account. With this commit, we replace this check by a call to a new function that checks the structure validity according to the country of the bank account, with a fallback to the generic check (ISO 11649) if the country is not supported. opw-5387269 Forward-Port-Of: odoo/odoo#249380 Forward-Port-Of: odoo/odoo#248194
This update enhances the accuracy of payment reference checks by tailoring validation rules to the bank account's country. Previously, a single check applied to all countries could lead to incorrect validation. Now, the system verifies the reference format against the specific country of the bank account, with a fallback to a standard check for unsupported countries.
Original PR description
Currently, when initiating a payment, we check if the reference is a structured one by using `is_valid_structured_reference` which checks the validity of the structure accross all supported countries. This can lead to issues when it matches formats accepted by other countries but not the one of the bank account. With this commit, we replace this check by a call to a new function that checks the structure validity according to the country of the bank account, with a fallback to the generic check (ISO 11649) if the country is not supported. opw-5387269 Forward-Port-Of: odoo/enterprise#107870 Forward-Port-Of: odoo/enterprise#107116
This update fixes an issue where a POS order could incorrectly apply a pricelist even if it wasn't the customer's standard price list. Previously, loading a pricelist from a paid order would override the correct selection. This change ensures that only available pricelists are applied, improving order accuracy and preventing pricing errors.
Original PR description
When changing the customer on a POS order, if the customer's pricelist is not in the list of available pricelists for the POS, but the pricelist was loaded due to loading a paid order, the POS would still set that pricelist on the order. opw-5461556 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248904 Forward-Port-Of: odoo/odoo#247029
This update fixes an issue where POS receipts incorrectly showed the standard 21% tax label, even when a fiscal position (like 6%) was applied. The change ensures that the POS receipt accurately reflects the tax group based on the selected fiscal position, improving accuracy and compliance.
Original PR description
Steps: - Install l10n_be_pos_restaurant. - Create a restaurant POS configuration with presets. - Assign a fiscal position to one preset that replaces 21% tax with 6%. - Open a POS session and process an order using that preset. Issue: - The POS receipt still displays the 21% tax's tax group label, even though the 6% tax is correctly applied. Cause: - Fiscal position was not taken into account when computing the tax group label for POS receipt orderlines. Fix: - Apply the fiscal position when determining the POS receipt tax group label. Task-5899938 Forward-Port-Of: odoo/odoo#250832 Forward-Port-Of: odoo/odoo#248571
This update corrects a previous fix that unintentionally increased the size of the message actions dropdown in the meeting chat. The change ensures the chat bubble remains appropriately sized and provides a better user experience. This resolves a visual issue impacting meeting conversations.
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/249880 PR above made a fix where inline message actions were taking way too much space in meeting chat, making chat bubble too small. This fixed the issue by setting the padding of inline message actions, but due to a typo it also set the same padding in dropdown menu. This commit fixes the issue by properly limiting the fix of PR above to inline message actions. Before / After <img width="342" height="228" alt="Screenshot 2026-02-26 at 18 46 45" src="https://github.com/user-attachments/assets/1e6b4f13-24c0-43d7-8837-046bc04cd85b" /> <img width="353" height="255" alt="Screenshot 2026-02-26 at 18 46 30" src="https://github.com/user-attachments/assets/59e912b7-fe1f-4aa1-89ce-ef2c6dd88743" />
This update clarifies how combo products are displayed in Odoo. Previously, 'free' items within combos were confusing users. Now, the backend shows 'item' and the POS frontend displays 'included' to accurately reflect that these products are part of the combo price.
Original PR description
Description of the issue/feature this PR addresses: combo choice products are not free products. They are included in the combo product price. Therefore it creates misunderstanding for our users Current behavior before PR: Desired behavior after PR is merged: Change the "free" string into "item" in the backend and into "included" in pos frontend to align with the display in self --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245279
This update fixes an issue where invoicing POS orders from closed sessions incorrectly duplicated stock valuation reversals, leading to accounting errors. The change ensures that stock valuation reversals accurately neutralize invoices, maintaining correct inventory tracking. This resolves a bug related to changes in how stock valuation is handled.
Original PR description
When invoicing a pos order from a closed session, we create a reversal move to "neutralize" the invoice. If the order contained storable products, the part of the reversal move that should neutralize the stock valuation was wrong. It would instead debit the same account two times. Steps to reproduce: ------------------- * Create a storable product with a cost price different than 0 and a category with automated inventory valuation * Create a pos order with that product, validate it and close the session * Invoice the order from the backend > Observation: The reversal move lines that should neutralize the stock valuation credit and debit the same account as the invoice. Why the fix: ------------ After the `stock.valuation.layer` was removed, the value of the stock move are now directly stored on the `stock.move`. But they are not signed so we need to rely on `is_out` to determine if we should inverse the value or not. opw-5359646 Forward-Port-Of: odoo/odoo#247863
This update resolves an issue preventing child companies from utilizing the parent proxy user for EDI invoicing. The problem stemmed from a missed update during a recent software update, causing errors when attempting to send invoices from the child company. This ensures seamless integration for clients using the account proxy feature.
Original PR description
This fix implements the same change made in PR #209120 to allow a child company to use the parent proxy user. It seems the record rules modification was missed during the FW, causing issues for clients using this feature in 18.2+ Steps to reproduce: - Create company A and a child company B sharing the same fiscal and VAT information - Register company A in the SDI (creating a proxy user) - Go to company B and try to send an invoice. You will get an error because Odoo will try to create a new proxy user as the parent proxy is currently inaccessible due to record rule constraints. Ticket [link](https://www.odoo.com/odoo/project.task/5927104) opw-5927104 Forward-Port-Of: odoo/odoo#250780 Forward-Port-Of: odoo/odoo#249821
This update corrects a visual bug where product attributes with a single custom value were incorrectly displayed in product specifications and single value lists. The fix prevents redundant display of these attributes, ensuring a cleaner and more accurate presentation of product information on the website. This improves the user experience for customers browsing products.
Original PR description
### Issue: Due to this bug, an attribute with a single custom value will be shown in specifications and single value attributes. #### Steps to reproduce: 1- Create a product. Add a `Free text`…
### Issue: Due to this bug, an attribute with a single custom value will be shown in specifications and single value attributes. #### Steps to reproduce: 1- Create a product. Add a `Free text` attribute. 2- Navigate to product page on the website. 3- From website editor, style tab, switch `specification` style. 4- With specification style set to `None`, you can see this attribute in single value attributes list. 5- With other 2 styles you can see this attributes in specifications. Expected: In both steps 4 and 5, this attributes shouldn't be displayed there because it is already displayed in main attributes where you can set the value. Initially fix was to filter `ProductTemplateAttributeLine` in `_prepare_single_value_for_display`, however it would cause empty specification sections. To avoid that we also need to filter out single custom value attributes in `_prepare_categories_for_display`. opw-5484721 Forward-Port-Of: odoo/odoo#250755 Forward-Port-Of: odoo/odoo#244234
This update fixes a calculation error in the Swiss tax report (l10n_ch) that was introduced during a recent tax revamp. Previously, the ‘Supplies provided abroad’ line incorrectly displayed a negative value. The fix involves a simple formula change from ‘221’ to ‘-221’, ensuring accurate tax reporting for Swiss businesses.
Original PR description
**Steps to Reproduce:** 1. Create a database in version 19 and install the `l10n_ch` module. 2. Create a journal entry using tax grid `221`. 3. Open the Tax Report and check the line `Supplies…
**Steps to Reproduce:** 1. Create a database in version 19 and install the `l10n_ch` module. 2. Create a journal entry using tax grid `221`. 3. Open the Tax Report and check the line `Supplies provided abroad`. 4. The value appears negative instead of positive. - This issue occurred due to the major tax revamp introduced in version 19 [commit](https://github.com/odoo/odoo/commit/17a6117ed88c29b5bc4db0c872bcdbc109a7d98b#diff-3441c5d05315ec0562923797f973eae66488452a6772d23e198998c1890aa06c) - To resolve this issue, the formula has been modified from `221` to `-221`. **Before fix:** <img width="1919" height="963" alt="image" src="https://github.com/user-attachments/assets/cea87440-9e7b-4d5e-80d9-6a3d745e5d71" /> **After fix:** <img width="1919" height="963" alt="image" src="https://github.com/user-attachments/assets/f69e3a62-ec6a-4a24-a0cc-b44fab16eefa" /> OPW: 5945876 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#250568
This update restores the warning message displayed when users attempt to cancel paid or posted orders in the Point of Sale system. Previously, this warning was removed, causing users to unknowingly cancel orders. The fix ensures the warning appears when appropriate, preventing accidental order cancellations.
Original PR description
From 18.2, the warning to prevent users to cancel paid or posted orders from backend was no longer displayed. It's caused because it was handled in the write() method from pos.order model. But, since a recent change, we call write() method only on draft orders. So, if there is no draft orders selected, the warning doesn't appear. task: 5959917 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250205 Forward-Port-Of: odoo/odoo#250074
This update optimizes how Odoo handles locale data, reducing unnecessary file searches. Previously, the system repeatedly checked for locale files even when the data wasn't being used, leading to slower performance. This change improves efficiency and reduces resource consumption.
Original PR description
`babel.Locale.parse` checks if a locale is valid by calling `os.path.exists` on the resolved filename for the locale (this is done in `babel.localedata.exists`). Babel does have a locale cache which it checks, but currently that cache is only populated when the locale is actually loaded[^1], therefore in cases where we instantiate a significant number of locales but never actually need to load locale data (e.g. formatting a significant number of datetimes, in qweb, using only non-localised patterns) this results in severe FS traffic for no reason. [^1]: python-babel/babel#1254 has been submitted to fix this issue Forward-Port-Of: odoo/odoo#250888 Forward-Port-Of: odoo/odoo#249795
This update corrects a bug where timesheets weren't automatically marked as billable when linked to a project or task. The fix ensures that timesheet entries correctly reflect the associated project or task, accurately tracking billable hours for clients. This improves the accuracy of invoicing and reporting.
Original PR description
Steps to reproduce: - Open Timesheet Assistant - Add new Timesheet - Choose a project or task so so_line of timesheet become True - is_billable is still False Source of the bug: - compute_is_billable was missing depends decorator task-5956059
This update fixes a minor typo within the Helpdesk module's result page. The change ensures consistent naming conventions after a recent update to the core Odoo system. This resolves a potential display issue and maintains data accuracy.
Original PR description
Before this commit and since the merge of https://github.com/odoo/odoo/pull/156878, `date_published` has been replaced by epublished_date` field but the changes have not been made in website_helpdesk_slides module. This commit replaces `date_published` occurrences by `published_date`. task-[5945377](https://www.odoo.com/odoo/project/4105/tasks/5945377)
This update fixes an issue where text within monospace banners was misaligned due to the use of tabs. The code has been updated to replace tabs with four spaces, ensuring consistent character spacing and improved readability within these banners. This enhances the user experience when working with formatted text.
Original PR description
Tabs are aligned on 40px boundaries. This leads to misalignment of characters when using the monospace banner. This commit fixes this by replacing all tabs inside monospace banners by four spaces. Steps to reproduce: - Go to a "To do" note - Insert a monospace banner - Type some text on several lines - Type tab at the begin of some lines => Character columns were misaligned. task-5916747 Forward-Port-Of: odoo/odoo#248227
This update resolves a bug where tests were failing due to a module activating the EUR currency, causing unexpected behavior in the OCR process. The fix ensures the USD currency is consistently used, making the tests reliable and preventing disruptions. This improves the stability of the account invoice extraction feature.
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. Forward-Port-Of: odoo/enterprise#108770
This update fixes an issue where generated QR codes for point-of-sale invoices were incorrectly referencing the local development server instead of the customer's company website. The change ensures that QR codes accurately reflect the correct website domain, improving the customer experience and invoice accuracy. This was caused by a shift in how the base URL is determined within the system.
Original PR description
Steps to reproduce ------------------ 1. Make a website, associated with company 'A' 2. Add a `domain` on that website, e.g. 'test.domain.com' 3. Select company 'A', and create a PoS shop for it 4.…
Steps to reproduce ------------------ 1. Make a website, associated with company 'A' 2. Add a `domain` on that website, e.g. 'test.domain.com' 3. Select company 'A', and create a PoS shop for it 4. Enable 'Self-service invoicing' for that PoS shop, select 'QR code' 5. Open the shop, select a client and make an order -> The generated QR code point to the domain 'localhost:8069' and not to the company's website domain 'test.domain.com'. Why the issue ------------- In 1ee02f8a47d42d3ba3fd11ffcf8d9768ea17678e, we moved the `_base_url` from the session to the config. So now we call `self.get_base_url` on the config and not on the session anymore. However, `self` is an empty config created on the fly, and it's not the `session.config_id` config object used by that shop. The fix ------- In `_load_pos_data_read` of the config model, we call `get_base_url` on the `config` instance, which is garanteed to be the valid config of that shop. opw-5942057 Forward-Port-Of: odoo/odoo#249858
This update makes the Gantt chart's date selection more responsive, updating the displayed date range immediately as the user adjusts the picker. Previously, changes required clicking 'Apply'. This enhancement provides a smoother and more intuitive user experience when setting the chart's date scale.
Original PR description
- Previously, the Gantt scale selector only updated the displayed date range after the "Apply" button was clicked. This was because the template was bound to the component props rather than the local state. - This commit binds the date picker display to the local pickerValues state. Now, when a user selects a date in the picker, the UI updates immediately, while the actual data fetch remains deferred until "Apply" is clicked. Task: 5932671 Forward-Port-Of: odoo/enterprise#107380
This update corrects a previous issue where NSSF Tier 2 and Pension Contribution details were missing from payslips, even when correctly calculated and reported. The fix ensures that all relevant deductions are accurately displayed on the payslip, providing greater transparency and compliance for Kenyan payroll users.
Original PR description
Issue: - NSSF Tier 2 and Pension Contribution salary rules only appeared on the payslip and salary computation when remitted to NSSF. - When Tier 2 was remitted to insurance, NSSF Tier 2 deductions were missing from the payslip display, even though reporting was correct. - Similarly, Pension Contribution was missing from the payslip when pension was remitted to insurance instead of the pension authority. Fix: - Updated the NSSF Tier 2 salary rule condition to ensure it always appears in salary computation and payslip. - Updated the Pension Contribution salary rule to ensure it is always displayed on the payslip even when remitted to insurance. - Adapted the NSSF Report as well. task-5896380 Forward-Port-Of: odoo/enterprise#106173
This update improves the handling of HSN codes for Indian Point of Sale (POS) transactions. Now, the system checks for missing HSN codes during the POS closing process and prompts the user to complete them before generating the final report. This prevents inaccurate GST reporting and ensures compliance with Indian regulations.
Original PR description
Before this PR: - POS order validation did not enforce the presence of HSN/SAC codes on products. Products without HSN could be sold via POS, and missing HSN values were only detected downstream during GST reporting, after the POS closing entry was generated. After this PR: - HSN/SAC validation is deferred to POS session closing. During the close flow, POS order lines with GST taxes and missing HSN/SAC codes are detected, and the user is required to complete the missing values before the closing journal entry is generated. POS order validation remains unblocked. Why: For Indian localization, POS closing entries are reported in GSTR-1, Table 12 (B2C HSN Summary). Missing HSN/SAC values on POS order lines result in incomplete or incorrect GST reporting. Deferring validation to session closing ensures all required HSN values are captured and propagated into the closing entry, while preserving the POS sales workflow. Task Id: 5404786 Forward-Port-Of: odoo/odoo#241986
This update corrects a technical error where new changes to point-of-sale orders were incorrectly treated as new creations instead of updates. Additionally, a bug that repeatedly generated order tracking numbers during synchronization has been resolved. This ensures accurate order management within the self-order functionality.
Original PR description
Before this commit, all lines even updated one were using Command.CREATE instead of Command.UPDATE. This commit fix the issued. Also fix another issue which was recreating the order tracking number at each sync. Forward-Port-Of: odoo/odoo#251222
This update fixes an issue where invoices using BCE numbers weren't correctly recognized in the PEPPOL system. Previously, the system didn't verify that company registry information matched the expected BCE number, leading to invoice errors. This change ensures PEPPOL invoices are processed accurately.
Original PR description
We expect people to put BCE number in the company registry. But it is not enforced client-side, resulting in invoices in error. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251272 Forward-Port-Of: odoo/odoo#251168