Daily updates from Odoo
Wednesday, July 2, 2025
97 changes
38 changes
Resolved issues and error corrections
Invoice reports now show the standard invoice date and the Saudi confirmation date separately, reducing confusion when invoices are backdated. Issue dates are consistently shown using Saudi Arabia timezone, regardless of the customer’s location.
Original PR description
Description of the issue/feature this PR addresses: The invoice date was printed as l10n_sa_confirmation_date on the report, causing confusion for users issuing backdated invoices. Additionally, the issue date was being converted to the partner's timezone, leading to inconsistencies. Current behavior before PR: The invoice date appears as l10n_sa_confirmation_date on the report. The issue date is affected by the partner's timezone. Desired behavior after PR is merged: The report will display both the standard invoice date and l10n_sa_confirmation_date separately for clarity. The issue date will always be passed in SA timezone to the report to ensure consistency, regardless of the partner's country. task-4508551 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216684 Forward-Port-Of: odoo/odoo#214937
Argentina B invoices for final consumers now include the required tax breakdown even when VAT is 0.00. This helps businesses produce compliant customer invoices and avoids missing tax legend information on printed PDFs.
Original PR description
### **Description of the issue/feature this PR addresses:** When doing an Invoice B to exempts customer we have a problem the RG Legend new table is not showing: this because if the VAT Content or…
### **Description of the issue/feature this PR addresses:** When doing an Invoice B to exempts customer we have a problem the RG Legend new table is not showing: this because if the VAT Content or other taxes sum is 0.0 (we are not showing any information if sums 0.0) After checking with ARCA Online PDF sxampels, and some feedback of Argentinen users, we found out that the Legend should be always present. event if the totals of theTax Breakdown are shown with 0.0 ### **Steps to reproduce** Go to an Argentina Company Create a new invoice for "Final Consumer" with document type "Invoice B" Create a product line with tax 0 (could use either VAT Exempt, VAT 0, VAT Not Taxed) Print the PDF ### **Current behavior before PR:** The PDF is NOT showing the Tax Breakdown table  ### **Desired behavior after PR is merged:** The PDF is showing the Tax Breakdown with the line VAT Content 0.0  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Manual Forward-Port-Of: https://github.com/odoo/odoo/pull/207367 Forward-Port-Of: odoo/odoo#214866
The employee time off calendar report once again opens with the intended default filters. This helps managers and HR users see the expected leave information without manually reapplying filters.
Original PR description
- `hr_holidays` promenade removed the default filters added in [task-4672501](https://www.odoo.com/odoo/project.task/4672501) - this PR adds them back in. task: 4815435 Forward-Port-Of: odoo/odoo#211212
This fix prevents an error from appearing in Point of Sale when a self-order is paid while the related POS configuration is open. It avoids processing empty synchronization data, making ticket printing and session updates more reliable for staff.
Original PR description
The issue is not reproducible in saas-18.2 however since the method _read_pos_record is introduced in saas 18.2 the issue could arise in this version. Step to reproduce in saas-18.3: - Make an order in self order mode - Pay it, while the linked pos config is open - A traceback will be shown in the pos config Issue: When printing the ticket on the pos config, notify_synchronisation function is called with no records in the session model. _post_read_pos_data will be called with empty data array. Fix: Prevent calling _post_read_pos_data with empty records. 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#216229
This fixes an issue where installing Timesheets caused the Employees kanban view to show two delete buttons. Employees now see a cleaner, less confusing interface with only one delete option.
Original PR description
Description of the issue/feature this PR addresses: In this PR, we removed the duplicated delete button from the hr employee kanban view when the timesheet app is installed. Root Cause: We missed to inherit the hr employee kanban view within the hr timehseet. Current behavior before PR:  Desired behavior after PR is merged:  Related task: 4843996 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212917
Automated web tours now handle page reloads correctly when they start or resume. This prevents false errors during guided testing flows and makes tour execution more reliable for teams validating business processes.
Original PR description
When a tour starts (or resumes), the first step of the macro may not be executed even though the page is already reloaded (e.g. client_actions.js => reload). In this case, the value of allowUnload was false and triggered an error. This was fixed by setting allowUnload to true, and then recalculating the value of allowUnload at each step. 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
This fixes Malaysia e-invoicing so credit notes can still be reported to MyInvois even when the original invoice was not previously sent there, such as invoices created before MyInvois adoption. It also aligns the reported issue date with MyInvois requirements by using today's UTC date.
Original PR description
So far, we have enforced that credit notes must be linked to an invoice that has been sent to MyInvois. In real life, this is too strict. Users could be issuing credit notes for invoices created before MyInvois was used, in which case these must still be reported to MyInvois even though the original invoice isn't on the platform. This also fixes a small issue with the issue date, which was set to the invoice date up until now but on their platform they explicitly ask for today in UTC timezone. task-4889022 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216988 Forward-Port-Of: odoo/odoo#215347
This fixes an issue where allocation records opened from a time off type could all show the same remaining balance for one employee. Users will now see accurate allocation information instead of misleading duplicate balances.
Original PR description
### Steps to reproduce: - Create a Time off type - Create allocations for some employees with the created type - Navigate to an allocation for a specific employee - Click on the time off type in the allocation form - Click on the smart button 'Allocations' - Notice each record showing the same time off type (X remaining out of Y) ### Cause: This is happening because when going through the allocation of a specific employee we add him in the context 'employee_id' so we compute the display name of the leave type and set it for each record as the same value as we compute leaves depending on the contextual employee. ### Fix: We are preventing the computation of the display name by forcing the employee_id in the context to force when we are using the smart button for allocations in the time off type form view opw-4841096 Forward-Port-Of: odoo/odoo#216699 Forward-Port-Of: odoo/odoo#215454
Fixed an issue where delivery orders could calculate the wrong quantity for components in nested kit bills of materials when rounding was involved. This helps ensure inventory movements match the quantities shown in the BoM overview and prevents overstated component usage.
Original PR description
## How to reproduce - Create 3 products: "FNS" / "CMP 1" / "CMP 2", the three of them with an UoM of 2 digits precision - Create Kit BoM for 1 Unit of "FNS" using 10 Units of "CMP 1" - Create Kit BoM…
## How to reproduce
- Create 3 products: "FNS" / "CMP 1" / "CMP 2", the three of them with an UoM of 2 digits precision
- Create Kit BoM for 1 Unit of "FNS" using 10 Units of "CMP 1"
- Create Kit BoM for 5000 Units of "CMP 1" using 50 of "CMP 2"
- Check "FNS" BoM Overview:
- "CMP 2" quantity shows the correct 0.10 Units (1 * 10 / 5000 * 50) (ok)
- Create Delivery order for 1 Unit of FNS
- "CMP 2" quantity is 0.50 Units (KO)
OPW-4804958
---
### BoM Overview
### BoM exploded
---
### Test result without fix:
```
2025-06-25 00:00:00,000 28629 ERROR oes_test_17 odoo.addons.mrp.tests.test_bom: FAIL: TestBoM.test_02_explode_rounding
Traceback (most recent call last):
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/addons/mrp/tests/test_bom.py", line 63, in test_02_explode_rounding
self.assertEqual(lines[0][1]['qty'], 0.10)
AssertionError: 0.5 != 0.1
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#216709
Forward-Port-Of: odoo/odoo#215821This update corrects how POS printers are linked to point-of-sale configurations. It helps ensure printer settings are associated with the right POS setup, reducing configuration issues for stores.
Original PR description
Before this commit, the Many2many field used an incorrect model name 'pos.printer' instead of the correct 'pos.config' This commit fixes the relation to ensure proper association between printers and POS configurations --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216563
This fix ensures that when the HR Contracts module is uninstalled, HR menu items are returned to their correct original locations. It prevents confusing or misplaced navigation for users after module removal, with minimal impact on day-to-day use.
Original PR description
This PR adds an uninstall_hook to restore the correct parent menus under the hr module that were overridden by this module. Task: 4818020 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213957
When no hourly time off types are configured, the time off request form now automatically selects an available time off type. This prevents confusion or blocked requests when employees create time off from the calendar in day or week views.
Original PR description
Steps To Reproduce: - Archive all Hourly timeoffs - Now raise a new timeoff from calendar from days/week Fix: - When there are no "Hourly Time Off" types configured in the company, pre-select an available time off type task-4702467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209451
The system now blocks E-way bill generation when the related document is not in an allowed state, such as cancelled. This helps businesses avoid creating invalid compliance documents and ensures E-way bills are generated only for finalized, valid records.
Original PR description
In this commit: --- - Introduced a validation to raise a `UserError` when attempting to generate an E-way bill if the document is not in a valid state (e.g.- `cancelled`). - This ensures E-way bills are only generated when the document is in the correct state (e.g.- `posted`) --- Forward-Port-Of: odoo/odoo#216167 Forward-Port-Of: odoo/odoo#206867
This fixes the boxed invoice PDF layout so the totals table has a consistent border after spacing was added. The change restores a cleaner, more professional report appearance for printed documents.
Original PR description
**Description:** Due to a recent [commit](https://github.com/odoo/odoo/commit/12ef230df58122fbdac0b4c1b4781c535b8516ba), a margin-top was added to the total table for the report type-pdf.…
**Description:** Due to a recent [commit](https://github.com/odoo/odoo/commit/12ef230df58122fbdac0b4c1b4781c535b8516ba), a margin-top was added to the total table for the report type-pdf. Previously,in the box layout, this table did not have a top border because it appeared visually connected to the preceding table — they seemed seamlessly joined. However, after the margin was added,the table now appears visually disconnected, making the absence of a top border look inconsistent and awkward. Steps to reproduce: - install account module - select box external layout - create invoice - print report as pdf Before commit:  After commit:  opw - [4873157](https://www.odoo.com/odoo/project/70/tasks/4873157) upg - [2839564](https://upgrade.odoo.com/odoo/upgrade.request/2839564) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214803
Pinned message notifications in Live Chat now display the livechat username when one is available, instead of showing both the regular name and livechat name. This removes duplicate-looking names and makes chat history clearer for operators and visitors.
Original PR description
**Current behavior before PR:** When a user pinned a message in livechat, both the regular username and the livechat username were shown, resulting in a duplicate display. This happened because the notification message used `username` directly, while `livechat_username` was separately injected in the template, leading to redundancy ([here](https://github.com/odoo/odoo/blob/f4c42ee65c8ec0511e1d5fd6063680328da365e8/addons/mail/static/src/core/common/notification_message.xml#L10C33-L10C34)). **Desired behavior after PR is merged:** Pinned notification message now show the livechat username if available. **Task**-4715349 before / after   --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204829
This update fixes nightly checks around CRM and event counters and makes event-to-CRM lead handling faster in common scenarios. It helps keep automated monitoring stable while reducing unnecessary background work during event registration processing.
Original PR description
Forward-Port-Of: odoo/odoo#216798
Embedded live chat calls now support picture-in-picture controls correctly. This helps visitors and agents keep video conversations visible while continuing to use the website or chat interface.
Original PR description
Forward-Port-Of: odoo/odoo#214956
This fix adjusts a font size used in the HTML editor’s automated tests to avoid inconsistent rounding on the test platform. It helps keep quality checks stable without changing how users edit or view content.
Original PR description
It looks like, on runbot specifically, the previously chosen size unfortunately resulted in a size near the 0.5px mark. Because of that, sometimes it would be rounded down and sometimes up. Hopefully changing to another font size won't have the same issue. If it does then we'll need to manually choose either to always round down or up. Forward-Port-Of: odoo/odoo#216611
The time-off form now avoids showing an overlap warning when an employee edits dates that still remain within the original approved period. This reduces confusing alerts for HR users and employees while keeping real conflict checks in place.
Original PR description
### Steps to reproduce: - Create a time-off with dates from X to Y. - Attempt to modify the start or end date to a value that still falls within the original X–Y range. ### Fix: - Updated the condition to correctly retrieve the current record's ID using .ids ,since .ids can also include the origin ID. Task-4819538 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211795
Guest visitors on public Discuss pages can now open the invite people action from the sidebar without encountering an error. The change prevents the page from trying to focus a search field that is not available for guests, improving reliability for public conversations.
Original PR description
Before this commit, when opening the invite people action from the sidebar in discuss public page as a guest you would get a traceback. This happens because the component has a useEffect that focuses the search input, but that element is not present as a non partner. This commit fixes the issue by adding a guard in the useEffect. task-4904119 Forward-Port-Of: odoo/odoo#216327
Dropdown labels in the HTML builder now shorten visually when they are too long, instead of taking up excessive space. This keeps nearby controls usable and improves the editing experience for pages with lengthy option names.
Original PR description
This PR allows dropdown labels to truncate within the `html_builder` environment. Prior to this PR, an `auto` value was assigned to the `flex-basis` property meaning it would take as much space as its content, meaning that if the label is very long, siblings wouldn't have enough space to grow. With this PR, we remove this `flex-basis` value an rely on the other `flex` values already defined, as well as the `min-width`. task-4910410 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Expenses screen no longer shows two New buttons in the Kanban view on small screens. This reduces confusion for users creating expense records and keeps the upload control placement consistent across list and Kanban views.
Original PR description
This commit avoids a duplicated "New" button definition and being displayed in the Expenses Kanban view on small screen. It also moves the hidden input used for upload next to the button calling it in both List and Kanban views (for coherence). Steps to reproduce (in small screen): - Open Expenses app => double "New" button : one displayed, one in the dropdown --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216799
The mail message composer now keeps a proper height even before users type anything. This avoids a visual jump in Chromium-based browsers, making message writing feel smoother and more polished.
Original PR description
Before this commit, composer height was too small when it had no content. This lead to composer changing height when typing some characters which looks off. This bug is specific to Chromium browsers and seems to be new since Chrome 138.0. The code expected that textarea had unchanged scrollheight when textarea has height 0 and fits its content in at most 1 line, but this seems to have changed with Chrome 138.0. This commit fixes the issue by cheating when composer is empty: the fake textarea artificially adds a character so that the computation for height when empty works as if it has 1 character, thus the computed height is the same when there are few characters in composer. Forward-Port-Of: odoo/odoo#216743
This fix prevents an error from appearing on the preparation display when an order is marked done shortly after it arrives in debug mode. It adds a safety check so the screen no longer tries to use order data that has already been removed, improving reliability for point-of-sale kitchen workflows.
Original PR description
Steps to reproduce: - Open a preparation display in debug mode - Make an order that will appear on the preparation display - Click on the done button before 5 seconds - Traceback will appear 5 seconds after the order was received Issue: When receiving an order useDelayedValueChange is called in the setup of the Orderline component. This method will try to access the props after a timeout. When the preparation orders are deleted in debug mode, the states are deleted from the front end. Since the props of orderline are the preparation state linked to it a traceback arises. Fix: A check is added to check if the state record exists. Forward-Port-Of: odoo/enterprise#88136
Swedish SIE4 transaction imports now ignore extra object-list details that are not needed for accounting entries. This prevents those details from being mistaken for transaction balances, reducing import errors and improving data accuracy.
Original PR description
The aim of this commit is ignoring the whole object list when we import transactions. The object list is represented by the elements between `{}` [[1]]. As we don't need these elements, we do ignore them to avoid a potential issue where we identify an element from this object list as the transaction's balance.
opw-4868415
[1]: https://sie.se/wp-content/uploads/2020/05/SIE_filformat_ver_4B_ENGLISH.pdf
Forward-Port-Of: odoo/enterprise#88892
Forward-Port-Of: odoo/enterprise#88784Belgian payroll termination holiday reports now use the payslip dates rather than contract dates to determine the exercise and holiday period. This helps ensure employees receive reports with the correct holiday-related information when a contract ends.
Original PR description
The exercise and the holiday period should be based on the payslip instead of the contract. We use the values of the report report_termination_holidays_n and report_termination_holidays_n1 which contains the correct values. Forward-Port-Of: odoo/enterprise#88737
Employees in Mexico with only variable pay, such as commissions or bonuses, can now have payslips generated without an error. The fix ensures the employer social security contribution calculation handles wages outside expected ranges correctly, improving payroll reliability for affected employees.
Original PR description
BUG An error is raised when trying to generate a payslip for an employee with only variable income (e.g., commissions/bonuses, no fixed base salary) FIX The rule's find_index function needs to return 0 instead of None in case the daily_wage does not fall within any of the measure ranges Task: 4723413 Forward-Port-Of: odoo/enterprise#89041 Forward-Port-Of: odoo/enterprise#85756
This fixes the conditions used to apply payroll subsidies in the Mexican payroll module. It helps ensure employee payslips calculate the subsidy only when appropriate, reducing payroll errors and correction work.
Original PR description
task-4690544 Forward-Port-Of: odoo/enterprise#84780
Users who work with Helpdesk and Inventory but do not have Sales access can now create repair-related tickets without seeing an access error. The change avoids checking a restricted sales field when the user is not allowed to view it, keeping the workflow available for the right teams.
Original PR description
### Before this PR If an user has only inventory, helpdesk group and it does not have "sales" permission , the error "you have not access on this field sale_order_id" appear. It appears because on helpdesk_sale that field is restricted to two specific groups. In the same module that fields is popped out during copy , but in the prepare of helpdesk_repair is accessed without checking permission ### After this PR The field is not accessed if it has no permission Forward-Port-Of: odoo/enterprise#86514
Fixed an issue in the VoIP mobile keypad where the cursor could jump and place the first typed number at the end of the input. This makes entering phone numbers on mobile more reliable and avoids dialing mistakes caused by misplaced digits.
Original PR description
This commit fixes a bug that caused the cursor in the keypad input to be displaced when typing on mobile. So, the first entered number was always to the end. This happens because the `on-touchend` event was calling another event (click) which may involve some changes in the UI that caused this. Steps to produce the bug: 1. Open VoIP wizard from mobile. 2. try to add numbers to the keypad. 3. You will see that the first number is always at the end. Forward-Port-Of: odoo/enterprise#89151
CSV bank statement imports now avoid failing when automatic matching encounters an issue, because matching is handled in the background after import. The reconciliation process also prevents multiple statement lines from being matched to the same already-used entry, reducing import errors and incorrect matches.
Original PR description
When doing an import of a csv in the bank rec widget, it could happens that the try_auto_reconcile throw an error which will lead in the rollback of the import. By triggering the schedule action auto_reconcile_bank_statement_line we will do the try_auto_reconcile in the back ground which will speed up the import process When importing, we pass a batch of statement lines to the try_auto_reconcile function, which identifies possible reconciliation candidates for each line. The issue arises because we iterate through each statement line and assign its potential candidate without checking for conflicts: if two statement lines map to the same candidate, we don’t verify whether that candidate has already been reconciled with a different line. opw-4888045,4890008 Forward-Port-Of: odoo/enterprise#88529
This fixes a small internal mistake in the Avalara tax integration where the system tried to call a non-existent follow-up step. The change prevents unnecessary or incorrect processing paths, with no expected visible impact for standard users.
Original PR description
This is a typo from the most recent refactor [1]. The commit hook is specific to US avatax, there is no corresponding super().commit_external_taxes so this can be removed all together. This didn't break any tests because (at least with the standard code), super()._uncommit_external_taxes is an empty method that does nothing. [1] https://github.com/odoo/enterprise/pull/82623
The Partner Ledger partner filter now includes companies even when they are linked to a parent company. This helps users find and filter the correct business partners more reliably in accounting reports.
Original PR description
Steps to reproduce - create a company - add a contact to this company - go to its contact form and transform this contact from Individual to Company - go to the Partner Ledger - open Partner filtering dropdown list Current behavior - show company and individual with no parent Expected behavior - show individual with no parents and all the companies - Company with parent company seems to be the expected behavior since 2016. If there is one, the Parent company appear in the contact form as defined [there](https://github.com/odoo/odoo/blob/9b03d99fd0174bd67c8ea30e5fd2c26fb2ad2467/odoo/addons/base/views/res_partner_views.xml#L168) opw-4729020 Forward-Port-Of: odoo/enterprise#87017
The Spanish Mod 349 BOE export now includes required rectifications when an invoice is fully cancelled by a credit note in a later period. It also prevents draft-reset invoices and credit notes from being wrongly included, improving compliance and report accuracy.
Original PR description
How to reproduce the issue: With l10n_es on an ES company: - Create an invoice from two months ago with a value of 1000. - Fully credit note this invoice on the current month. - On the mod 349 report, download the BOE report. The BOE report does not contains the rectification despite being mandatory as per: https://www.boe.es/buscar/doc.php?id=BOE-A-2010-5098 (look at the examples in CUMPLIMENTACIÓN DEL REGISTRO DE RECTIFICACIONES). This commit also fixes an issue where invoice reverted to draft where included in the boe report: - Create an invoice of 100 in January, credit note 50 in May. - Reset to draft both the invoice and the credit note. - Create another invoice of 888 in February, credit note 444 in May. - Generate the BOE report. The invoice reverted to draft is included in the boe report. opw-4653025 Forward-Port-Of: odoo/enterprise#88625 Forward-Port-Of: odoo/enterprise#86127
Users can now connect an online bank account even when Odoo Fin reports a currency that differs from existing journal or bank account entries. Instead of blocking setup with an error, Odoo skips updating the currency and lets synchronization continue.
Original PR description
This commit avoids blocking users when connecting a journal to an online account that has a predefined currency. Previously, if the journal or its default bank account had entries in a different currency than the one sent by Odoo Fin, the process would fail with an error, preventing completion. Now, the system silently ignores the currency mismatch error and skips setting the currency, allowing the synchronization to proceed. opw-4751616 Forward-Port-Of: odoo/enterprise#89042 Forward-Port-Of: odoo/enterprise#88654
Rental orders using material resources now correctly recognize already planned shifts. This prevents the order from showing “To Plan” when the required material planning has already been completed.
Original PR description
_*= sale_planning, sale_renting_planning Steps to Reproduce: - Install the `sale_renting_planning` module. - Create a rental product with the `Plan Service` enabled and the resource type set to…
_*= sale_planning, sale_renting_planning Steps to Reproduce: - Install the `sale_renting_planning` module. - Create a rental product with the `Plan Service` enabled and the resource type set to `Material`. - Create a SO for the newly created product and confirm it. - Observe the state button the shift is already planned but it incorrectly displays `To Plan`. Issue: - Confirming the SO the shift is already planned but the state button still displays `To Plan`. this issue occurs when the resource type is `Material` However it works correctly when the resource type is `User`. Cause: - When we are calculating the planned hours the domain `'resource_type', '!=', 'material'` is passed causes resources type of Material so it will be excluded from the calculation. Fix: - In this commit removed the condition that excluded resources of type Material so that they are included when calculating the planned hours. This ensures the state button shows the correct status. task-3978597 Forward-Port-Of: odoo/enterprise#75861
Helpdesk tickets will no longer be closed when automated email scanners check links in customer emails. Only an actual customer opening the close link in the expected way will close the ticket, reducing accidental closures and support confusion.
Original PR description
Currently some customers with email scanners will have their ticket closed soon after it's opened. Steps to reproduce ----- 1. Enable "Closure by Customers" on the helpdesk team 2. Create a new ticket 3. Send a HEAD request to the "Close ticket" link in the received email, using `curl -I <url>` 4. The ticket gets closed Cause ----- Some email scanners send HEAD requests to links contained in emails, which is incorrectly interpreted as a user action. Fix ----- Implement a check so that only GET requests to the route will close the ticket. opw-4837167 Forward-Port-Of: odoo/enterprise#89026 Forward-Port-Of: odoo/enterprise#88547
This fix ensures that when a user enables form access for a selected model in Website Studio, the setting is properly saved. It prevents forms from losing access configuration after saving and returning to edit mode, reducing setup errors for website forms.
Original PR description
In [1] miscellaneous fixes about website forms in ´website_studio´ were put in place, but the actual flag about giving access to the given model was not actually set. This commit adds the missing statement. Steps to reproduce: - Install `website_studio` - Drop a Form - Select "More models" as Action - Pick a model - Save - Edit and select form => Access form was not enabled. [1]: https://github.com/odoo/enterprise/commit/89fc1023c146a83809f8cfa202177fe44a1aa25a task-4367641
14 changes
Resolved issues and error corrections
The Kenyan NHIF/SHIF payroll report now uses the selected month correctly, so payslips appear in the right reporting period. This prevents reports from showing records from the wrong month and removes confusing explanatory text from the selection screen.
Original PR description
- load payslip according to the Month value, currently, may payslip appears on june selection - remove the line 'the selection will cover ...' task-4775801 Forward-Port-Of: odoo/enterprise#88996 Forward-Port-Of: odoo/enterprise#85609
This fix ensures Chilean electronic factoring documents always show the assigned amount in Chilean pesos, even when the original invoice uses another currency. It prevents incorrect official XML values and helps companies avoid reporting errors when submitting factoring documents to the tax authority.
Original PR description
In this bug, when a currency other than CLP is selected in invoicing, the generated aec has MontoCesion tag with the rate of selected currency, while it must always be in CLP. To reproduce the bug: 1- Create a database with invoice app and a Chilean company 2- Create an invoice with document type of 34 3- Choose a different currency than CLP 3- Click on `Send Now to SII` and Create AEC 4- Click on Yield Entry smart button 5- Download generated AEC xml file 6- You can see the value of MontoCesion is in selected currency which is wrong opw-4830957 Forward-Port-Of: odoo/enterprise#88175
This fixes an issue where the journal shortcut could disappear after creating a draft accounting entry for one payslip in a batch. Payroll users can now keep access to the related journal entry even when other payslips in the same batch are not yet finalized.
Original PR description
**Steps:** - Install the hr_payroll_account module - Navigate to the payroll menu and open a batch payslip. - Select a batch containing two or more payslips and create a draft entry for any single…
**Steps:** - Install the hr_payroll_account module - Navigate to the payroll menu and open a batch payslip. - Select a batch containing two or more payslips and create a draft entry for any single payslip in the batch. --- **Description of the issue/feature this PR addresses:** When a draft entry is created for a single payslip within a batch, the journal smart button becomes invisible. --- **Cause:** The issue occurs during the account move creation process. When generating an account move for a batch payslip, the process checks the status of all payslips in the batch. If any payslip is not in the done state, the account move is not created, resulting in the journal smart button not appearing. --- **Fix:** This PR adjusts the account move creation logic to allow account moves to be created for batch payslips, ensuring the journal smart button remains visible even if some payslips are not in the done state. task-4440533 Forward-Port-Of: odoo/enterprise#76681
Point of Sale users connected to UrbanPiper will no longer see the same online/offline store status notification again after reloading the POS. This reduces repeated interruptions and improves the checkout experience for restaurants using delivery platforms.
Original PR description
Steps: ==== - Configured UrbanPiper credentials in `pos.config` and selected platform providers (e.g., Ubereats, Justeat). - On session start, a pop-up confirms the store is online on enabled platforms. - Reload the pos Issue : ==== - The same pop-up appeared again on POS reload, leading to a poor user experience. Fix: ==== - Removed duplicate call from `pos.store` that triggered provider status notifications unnecessarily. - Enhances user experience by preventing repeated popups on session reload. task-4879125 Forward-Port-Of: odoo/enterprise#88027
The scheduled payroll data update has been adjusted to run once per week instead of more frequently. This reduces unnecessary background processing while keeping payroll reference data refreshed on a regular schedule.
Original PR description
Forward-Port-Of: odoo/enterprise#88564 Forward-Port-Of: odoo/enterprise#88492
Fixed an issue in barcode receipt processing where changing the unit of measure updated the completed quantity but left the reserved quantity unchanged. This keeps inventory demand and received quantities aligned, reducing confusion and preventing inaccurate stock handling.
Original PR description
Steps to reproduce:
- Create a storable product “P1”:
- UoM: Unit
- Create a receipt for 200 units of P1
- Mark it as To Do
- Go to the barcode module and start processing the receipt
- Edit the quantity:
- Set it to 2 and change the UoM to Dozen
- Save
Problem
The quantity done is correctly set to 2 dozens, But the reserved quantity remains 200
Solution:
When the UoM is changed, compute and update the reserved quantity accordingly
OPW-4716104
Forward-Port-Of: odoo/enterprise#87766
Forward-Port-Of: odoo/enterprise#85004The Swedish SIE4 import now ignores transaction object details that are not needed for bookkeeping entries. This prevents those extra details from being mistaken for transaction balances, reducing the risk of incorrect imported accounting data.
Original PR description
The aim of this commit is ignoring the whole object list when we import transactions. The object list is represented by the elements between `{}` [[1]]. As we don't need these elements, we do ignore them to avoid a potential issue where we identify an element from this object list as the transaction's balance.
opw-4868415
[1]: https://sie.se/wp-content/uploads/2020/05/SIE_filformat_ver_4B_ENGLISH.pdf
Forward-Port-Of: odoo/enterprise#88892
Forward-Port-Of: odoo/enterprise#88784A test setup issue in Document Sign was corrected so signer email details are populated properly during automated checks. This prevents false test failures in builds without demo data and helps keep document signing releases reliable.
Original PR description
This commit fixes a ValidationError triggered during sign request creation tests due to missing signer emails in "no demo" builds. The root cause was incorrect data passed into the test helper create_sign_request_1_role: the user record (res.users) was passed instead of its corresponding partner (res.partner). Since the sign.request.item expects a valid partner_id, this led to signer_email being computed as False, violating the constraint that requires all signers to have valid email addresses. This change ensures the proper partner_id (user.partner_id) is passed when creating the request item, allowing the email computation and constraint to behave as expected. This fix unblocks TestSignedDocument.test_gc_clear_bin build_error-224070 Forward-Port-Of: odoo/enterprise#88508
Odoo Studio now removes accidental spaces at the end of selection values before saving them. This prevents confusing duplicate-looking options and makes reused values more reliable across configurations.
Original PR description
Before this commit it was possible to create selection values with trailing spaces. This could be very misleading when reusing these values somewhere else. After this commit, such values are trimmed before saving. opw-4877276 Forward-Port-Of: odoo/enterprise#88838 Forward-Port-Of: odoo/enterprise#88255
This fixes an error that could prevent payslips from being generated for Mexican employees who only have variable income, such as commissions or bonuses. Payroll processing is more reliable for these employee cases, reducing manual intervention and payroll delays.
Original PR description
BUG An error is raised when trying to generate a payslip for an employee with only variable income (e.g., commissions/bonuses, no fixed base salary) FIX The rule's find_index function needs to return 0 instead of None in case the daily_wage does not fall within any of the measure ranges Task: 4723413 Forward-Port-Of: odoo/enterprise#89041 Forward-Port-Of: odoo/enterprise#85756
Users working in inventory and helpdesk without sales permissions no longer hit an error when creating repair-related tickets. The change avoids reading sales order information unless the user has the right access, keeping the workflow available for non-sales teams.
Original PR description
### Before this PR If an user has only inventory, helpdesk group and it does not have "sales" permission , the error "you have not access on this field sale_order_id" appear. It appears because on helpdesk_sale that field is restricted to two specific groups. In the same module that fields is popped out during copy , but in the prepare of helpdesk_repair is accessed without checking permission ### After this PR The field is not accessed if it has no permission Forward-Port-Of: odoo/enterprise#86514
Barcode receipts for purchase orders that include subcontracted products now correctly leave unreceived items open instead of marking the whole delivery as received. This prevents inventory and purchasing records from showing products as received before they actually arrive.
Original PR description
Issue ----- In barcode processing reception of subcontracted products doesn't create a back order for the remaining products. Steps to reproduce ----- - Create 2 products, one subcontracted and one…
Issue ----- In barcode processing reception of subcontracted products doesn't create a back order for the remaining products. Steps to reproduce ----- - Create 2 products, one subcontracted and one storable - Create a purchase order for the 2 products & confirm it - Go to barcode and open the delivery - Only validate the reception of the subcontracted product --> No backorder is created for the remaining product, it is considered received Cause ----- Commit db8b33e changed the compute of the move's picked status to not update for subcontracted moves. So the move line has picked set to True but not the move itself. When we validate the operation in barcode, we go through this pre hook https://github.com/odoo/odoo/blob/1d256123da587d625c0527ca3a18cd82e7161df5/addons/stock/models/stock_picking.py#L1193 Since the move has a quantity but picked is still False, the full picking is being picked at once https://github.com/odoo/odoo/blob/1d256123da587d625c0527ca3a18cd82e7161df5/addons/stock/models/stock_picking.py#L1206-L1207 ----- Ticket: opw-4726229 Forward-Port-Of: odoo/enterprise#88925 Forward-Port-Of: odoo/enterprise#86979
Users can now connect a bank journal to an online account even when existing entries use a different currency than the one provided by Odoo Fin. Instead of blocking setup with an error, the system leaves the existing currency unchanged and lets synchronization continue.
Original PR description
This commit avoids blocking users when connecting a journal to an online account that has a predefined currency. Previously, if the journal or its default bank account had entries in a different currency than the one sent by Odoo Fin, the process would fail with an error, preventing completion. Now, the system silently ignores the currency mismatch error and skips setting the currency, allowing the synchronization to proceed. opw-4751616 Forward-Port-Of: odoo/enterprise#89042 Forward-Port-Of: odoo/enterprise#88654
Rental orders using material resources now count their planned time correctly. This prevents already-planned material shifts from incorrectly showing as still needing to be planned, giving teams a more accurate order status.
Original PR description
_*= sale_planning, sale_renting_planning Steps to Reproduce: - Install the `sale_renting_planning` module. - Create a rental product with the `Plan Service` enabled and the resource type set to…
_*= sale_planning, sale_renting_planning Steps to Reproduce: - Install the `sale_renting_planning` module. - Create a rental product with the `Plan Service` enabled and the resource type set to `Material`. - Create a SO for the newly created product and confirm it. - Observe the state button the shift is already planned but it incorrectly displays `To Plan`. Issue: - Confirming the SO the shift is already planned but the state button still displays `To Plan`. this issue occurs when the resource type is `Material` However it works correctly when the resource type is `User`. Cause: - When we are calculating the planned hours the domain `'resource_type', '!=', 'material'` is passed causes resources type of Material so it will be excluded from the calculation. Fix: - In this commit removed the condition that excluded resources of type Material so that they are included when calculating the planned hours. This ensures the state button shows the correct status. task-3978597 Forward-Port-Of: odoo/enterprise#75861
17 changes
Resolved issues and error corrections
Users who work with inventory and helpdesk but do not have sales permissions can now create repair-related tickets without seeing an access error. The change avoids checking a sales field when the user is not allowed to view it, keeping the workflow available while respecting permissions.
Original PR description
### Before this PR If an user has only inventory, helpdesk group and it does not have "sales" permission , the error "you have not access on this field sale_order_id" appear. It appears because on helpdesk_sale that field is restricted to two specific groups. In the same module that fields is popped out during copy , but in the prepare of helpdesk_repair is accessed without checking permission ### After this PR The field is not accessed if it has no permission Forward-Port-Of: odoo/enterprise#86514
The employee form now shows Hong Kong-specific rental information only where relevant and restores the MPF payroll section layout. This prevents confusion for employees in other countries and ensures Hong Kong payroll details can be viewed correctly.
Original PR description
Fixes some issues with the employee view following recent updates. - the field l10n_hk_rental_id was visible to other countries - the whole mpf section was kept in a group, which broke the whole view
The Partner Ledger partner filter now includes company contacts even when they have a parent company. This helps users find and select the correct business partners when reviewing partner ledger reports.
Original PR description
Steps to reproduce - create a company - add a contact to this company - go to its contact form and transform this contact from Individual to Company - go to the Partner Ledger - open Partner filtering dropdown list Current behavior - show company and individual with no parent Expected behavior - show individual with no parents and all the companies - Company with parent company seems to be the expected behavior since 2016. If there is one, the Parent company appear in the contact form as defined [there](https://github.com/odoo/odoo/blob/9b03d99fd0174bd67c8ea30e5fd2c26fb2ad2467/odoo/addons/base/views/res_partner_views.xml#L168) opw-4729020 Forward-Port-Of: odoo/enterprise#87017
Connecting a journal to an online bank account will no longer fail when Odoo Fin provides a preset currency that conflicts with existing journal or bank account entries. Instead, the currency update is skipped so users can complete the synchronization without being blocked.
Original PR description
This commit avoids blocking users when connecting a journal to an online account that has a predefined currency. Previously, if the journal or its default bank account had entries in a different currency than the one sent by Odoo Fin, the process would fail with an error, preventing completion. Now, the system silently ignores the currency mismatch error and skips setting the currency, allowing the synchronization to proceed. opw-4751616 Forward-Port-Of: odoo/enterprise#89042 Forward-Port-Of: odoo/enterprise#88654
The Spanish Mod 349 BOE export now includes mandatory rectification entries when an earlier invoice is fully cancelled by a credit note. It also prevents draft or reverted invoices from being incorrectly included, improving tax report accuracy and compliance.
Original PR description
How to reproduce the issue: With l10n_es on an ES company: - Create an invoice from two months ago with a value of 1000. - Fully credit note this invoice on the current month. - On the mod 349 report, download the BOE report. The BOE report does not contains the rectification despite being mandatory as per: https://www.boe.es/buscar/doc.php?id=BOE-A-2010-5098 (look at the examples in CUMPLIMENTACIÓN DEL REGISTRO DE RECTIFICACIONES). This commit also fixes an issue where invoice reverted to draft where included in the boe report: - Create an invoice of 100 in January, credit note 50 in May. - Reset to draft both the invoice and the credit note. - Create another invoice of 888 in February, credit note 444 in May. - Generate the BOE report. The invoice reverted to draft is included in the boe report. opw-4653025 Forward-Port-Of: odoo/enterprise#88625 Forward-Port-Of: odoo/enterprise#86127
Rental orders using material resources now count their planned hours correctly. This prevents already-planned rental shifts from being shown as still needing planning, giving sales and planning teams a more accurate order status.
Original PR description
_*= sale_planning, sale_renting_planning Steps to Reproduce: - Install the `sale_renting_planning` module. - Create a rental product with the `Plan Service` enabled and the resource type set to…
_*= sale_planning, sale_renting_planning Steps to Reproduce: - Install the `sale_renting_planning` module. - Create a rental product with the `Plan Service` enabled and the resource type set to `Material`. - Create a SO for the newly created product and confirm it. - Observe the state button the shift is already planned but it incorrectly displays `To Plan`. Issue: - Confirming the SO the shift is already planned but the state button still displays `To Plan`. this issue occurs when the resource type is `Material` However it works correctly when the resource type is `User`. Cause: - When we are calculating the planned hours the domain `'resource_type', '!=', 'material'` is passed causes resources type of Material so it will be excluded from the calculation. Fix: - In this commit removed the condition that excluded resources of type Material so that they are included when calculating the planned hours. This ensures the state button shows the correct status. task-3978597 Forward-Port-Of: odoo/enterprise#75861
The Appraisals app now hides the configuration button for users who do not have permission to access it. This prevents confusion and keeps users from seeing options they cannot use.
Original PR description
This PR aims to hide the configuration button, if the user has no access in appraisal app task-4825879
The Documents app now uses Odoo's own dropdown menu for the New button instead of an older Bootstrap component. This prevents memory usage from growing when users repeatedly open the menu, improving stability in Documents and spreadsheet creation flows.
Original PR description
…ropdown Before this commit, the Documents control panel was still using a Bootstrap dropdown. This caused a memory leak, as the dropdown wasn't properly destroyed when the control panel itself was…
…ropdown Before this commit, the Documents control panel was still using a Bootstrap dropdown. This caused a memory leak, as the dropdown wasn't properly destroyed when the control panel itself was removed. The issue was identified while working on spreadsheet tests, where the Documents control panel was used to create a new spreadsheet. However, the memory leak is also reproducible in production code. To observe it: - Open the document app - Click on the New button in the control panel - Inspect elementsMap in bootstrap/data.js You'll notice that elementsMap keeps growing as you repeat the action. Possible fix (not chosen): Manually destroy the Bootstrap dropdown Drawbacks: - There's no clean hook to do it. For example, willUnmount might be too late if the dropdown is conditionally rendered via t-if, and already removed from the DOM. - We aim to avoid Bootstrap JS in Odoo's backend, partly due to issues like this. Final solution (chosen in this commit): Replace the Bootstrap dropdown with the native Odoo dropdown component. Graph with the impact on the memory usage in the tests: <img width="1435" alt="image" src="https://github.com/user-attachments/assets/ae01222f-393b-474b-a1e7-6d6961270fc7" />
This fix makes the Belgian payroll accounting eco voucher test reliable when only the relevant test module is installed, not just in full test environments. It helps prevent false build failures and keeps release validation more dependable.
Original PR description
Before this commit this test test_eco_vouchers was only working with all modules installed (classic runbot build) but was failing in singleapp mode (with just test_l10n_be_hr_payroll_account).
With this commit this test works as expected in both of them. (and with/)
Caused by:
```py
reference_year = fields.Selection(
selection='_get_years', string='Reference Year', required=True,
default=lambda x: str(fields.Date.today().year + 1 if fields.Date.today().month > 5 else fields.Date.today().year))
....
def _get_years(self):
today = fields.Date.today()
current_reference_year = today.year + 1 if today.month > 5 else today.year
return [(str(i), i) for i in range(current_reference_year, current_reference_year - 5, -1)]
```
A solution was to use freezetime
runbot error linked: https://runbot.odoo.com/odoo/runbot.build.error/226389
Forward-Port-Of: odoo/enterprise#86887Helpdesk tickets will no longer be closed when automated email scanners check links in customer emails. This prevents tickets from being marked closed without a real customer action, keeping support workflows accurate.
Original PR description
Currently some customers with email scanners will have their ticket closed soon after it's opened. Steps to reproduce ----- 1. Enable "Closure by Customers" on the helpdesk team 2. Create a new ticket 3. Send a HEAD request to the "Close ticket" link in the received email, using `curl -I <url>` 4. The ticket gets closed Cause ----- Some email scanners send HEAD requests to links contained in emails, which is incorrectly interpreted as a user action. Fix ----- Implement a check so that only GET requests to the route will close the ticket. opw-4837167 Forward-Port-Of: odoo/enterprise#89026 Forward-Port-Of: odoo/enterprise#88547
This fix updates automated tests so they behave correctly whether the timesheet grid feature is installed or not. It helps keep project planning and timesheet-related quality checks reliable without changing day-to-day user workflows.
Original PR description
After this commit https://github.com/odoo/enterprise/pull/74528/commits/c0af404c2b3e08ec92243f4c070f915833b4a538 some tests are failing when we don't have timesheet_grid module installed as the allocated hours will get recomputed so the behavior will be different. To fix this we moved all of the tests that test allocated hours value to timesheet_grid and adapted another test to check whether we have the timesheet_grid module installed or not and upon this check we change the value that we are checking. runbot-115003 Forward-Port-Of: odoo/enterprise#88429 Forward-Port-Of: odoo/enterprise#81643
Urban Piper receipt headers now show the delivery identifier clearly when printed. This prevents confusion during order handoff and delivery tracking by making the identifier readable on physical receipts.
Original PR description
- When printing urban piper receipt the delivery identifier was not correctly rendered in the receipt header. - This is caused by the `text-muted` class on the element, which is causing the text to be too light to be correctly printed. task-id: 4881459 Forward-Port-Of: odoo/enterprise#88763 Forward-Port-Of: odoo/enterprise#88113
Installing Sales Planning no longer fails if the standard Hours unit of measure was previously deleted. The module now restores that required unit when needed and prevents it from being removed while Sales Planning depends on it.
Original PR description
Steps to reproduce: --- - Install `sale_management` module - Enable `Units of Measure & Packagings` - Delete `Hours` in Units & Packagings - Install `sale_planning` module Traceback: --- ```…
Steps to reproduce:
---
- Install `sale_management` module
- Enable `Units of Measure & Packagings`
- Delete `Hours` in Units & Packagings
- Install `sale_planning` module
Traceback:
---
```
ValueError: External ID not found in the system: uom.product_uom_hour
ParseError: while parsing /home/odoo/src/enterprise/saas-18.2/sale_planning/views/planning_role_views.xml:26, somewhere inside <record id="planning_role_view_tree_inherit_sale_planning" model="ir.ui.view">
<field name="name">planning.role.list.inherit.sale.planning</field>
<field name="model">planning.role</field>
<field name="inherit_id" ref="planning.planning_role_view_tree"/>
<field name="arch" type="xml">
<field name="resource_ids" position="after">
<field name="product_ids" widget="many2many_tags" placeholder="e.g. Cleaning Services" domain="[('planning_role_id', '=', False), ('type', '=', 'service'), ('sale_ok', '=', True)]" context="{ 'default_type': 'service', 'default_planning_enabled': True, 'default_planning_role_id': id, 'default_uom_id': %(uom.product_uom_hour)d, }"/>
</field>
</field>
</record>
```
The error occurred at [1] because the user deleted `Hours` from `Units & Packagings` before attempting to install the other module.
This commit resolves the issue by calling the `ensure_uom_hours` method before updating the `Hours` unit of measure in the data file. This method ensures the UoM is recreated if it no longer exists in the database.
[1]- https://github.com/odoo/enterprise/blob/adfa1ff2ee56b8d43666cd7c2565d6e9430aae48/sale_planning/views/planning_role_views.xml#L38
sentry-6595283261
Forward-Port-Of: odoo/enterprise#89046
Forward-Port-Of: odoo/enterprise#85286Updated payroll test demo data to use a Belgium-specific time off type. This prevents access errors when opening employee records in the Belgian payroll accounting test setup.
Original PR description
This commit fixes an issue in the demo data. A time off allocation was done using a time off type that is not in Belgium. This caused access error when trying to access the employee. This commit fixes the issue by changing the time off type to a belgian one. task-4896664 Forward-Port-Of: odoo/enterprise#88604
Printed payslips now display title-style salary rule lines with the correct formatting. This makes payroll documents clearer and more professional when generated for employees or records.
Original PR description
### Steps to reproduce: - Generate and print a payslip after marking a salary rule line as a title. ### Fix: - Added conditional styles and classes to fix the issue. task-4780481 Forward-Port-Of: odoo/enterprise#85607
Fixed an issue in barcode inventory counts where scanning the same product after removing a line could create repeated sublines. This keeps stock counting screens clearer and helps users avoid confusion or potential counting mistakes.
Original PR description
### Steps to reproduce: - Create a storable product with 1 unit in stock and a barcode: XXX - Go to the barcode app > Inventory Count - Scan XXX > One line is created 1/1. - Diminish the quantity to…
### Steps to reproduce:
- Create a storable product with 1 unit in stock and a barcode: XXX
- Go to the barcode app > Inventory Count
- Scan XXX
> One line is created 1/1.
- Diminish the quantity to 0 > Remove the line
- Scan XXX
#### > The line appear with multiple sublines
#### > If you repeat the two last steps even more sublines will appear
### Cause of the issue:
Scaning XXX will create a line with a subline for each quant present in the lazyBarcodeCache:
https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/models/barcode_quant_model.js#L345 https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/models/barcode_quant_model.js#L359-L381 However, the quants present in the cache are currently stored in a list and they are pushed to the list by the `setCache` method even if they are already present:
https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/lazy_barcode_cache.js#L54-L62 This is problematic in the present flow since multiple actions set the cahche and hence add the "new" version of the already present quant rather than updating its current value.
To be more precise, in the present workflow, the `setCache` method is called once during the the first barcode scan:
https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/lazy_barcode_cache.js#L324-L325 And twice at each line deletion (once per `refreshCache` call, one during the save and one during the `trigger('refresh')`): https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/models/barcode_model.js#L823-L825 https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/models/barcode_model.js#L468-L471
opw-4787229
Forward-Port-Of: odoo/enterprise#88861
Forward-Port-Of: odoo/enterprise#87073Adds automated checks to confirm that date-based rentals count the full rental period correctly, such as January 1 to January 2 counting as two days. This helps prevent pricing or availability mistakes from returning in future updates.
Original PR description
Adds a tour that ensure date-based rental durations are set correctly, i.e. renting from 2025-01-01 to 2025-01-02 should result in a rental period of 2 days. This should prevent commits like 574e111 (reverted by 5982e11) from introducing faulty logic. Forward-Port-Of: odoo/enterprise#88950 Forward-Port-Of: odoo/enterprise#88264
28 changes
Resolved issues and error corrections
This fixes an issue where manually adjusted extra hours on an employee attendance could be reset when another attendance was created. The system now avoids recalculating automatically approved extra hours when they appear to have been manually changed, helping payroll and attendance records better reflect user edits.
Original PR description
**Steps to reproduce** - Set "Extra Hours Validation" to "Automatically approved" - Create an attendance for an employee - Change the "Extra Hours" to a different value - Create another attendance…
**Steps to reproduce** - Set "Extra Hours Validation" to "Automatically approved" - Create an attendance for an employee - Change the "Extra Hours" to a different value - Create another attendance for this employee (not necessarily on the same day) - See that the "Extra hours" of the previous attendance has been recomputed, resetting the value entered by the user. **Cause** When creating an attendance for an employee, we recompute the `validated_overtime_hours` for the other attendances of this employee https://github.com/odoo/odoo/blob/cac96f5d3c391ea0d52da2e3433e7eabe07e8fb0/addons/hr_attendance/models/hr_attendance.py#L426 In case of attendances with no validation, this field is synced with the `overtime_hours` https://github.com/odoo/odoo/blob/cac96f5d3c391ea0d52da2e3433e7eabe07e8fb0/addons/hr_attendance/models/hr_attendance.py#L156 **Solution** We may still want to recompute the `validated_overtime_hours` of automatically approved attendances, since it is their default state, unlike manually approved attendances. If the `validated_overtime_hours` field is different from `overtime_hours`, it means it has been modified. In that case, we avoid recomputing it. This doesn't guarantee a manually set value will never be overriden by a change in its dependencies, but it reduces the likelihood. opw-4639230
This fix ensures website pages can open correctly even when the related content record uses a negative ID, a case present on Odoo.com. It prevents backend website view crashes by recognizing these IDs consistently when reading page data.
Original PR description
Steps to reproduce: 1. Install website_blog 2. Create a blog post with a negative ID (you'll need to change it via SQL) -> such kind of record is something we have on Odoo.com 3. Go to that blog post in the backend website view => Crash We have several places where the main-object data is parsed from the HTML, it did not consider the negative ID possibility. In master, an unified way to parse the main-object will be made. task-jke Forward-Port-Of: odoo/odoo#216573
This fix makes the sales signature validation test wait until the signature area is ready before continuing. It helps prevent false test failures where the system incorrectly reports that a signature is missing because the signing box had not fully loaded yet.
Original PR description
In commit, we make sure that the signature is present in the modal before reaching the step where we click on "accept & sign". If the canvas is not yet loaded at this step, then there is an error message "Signature is missing". 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
This fix ensures invoice payment references are consistently handled as text instead of an empty false value. It prevents a test failure and helps keep Peru stock reporting workflows stable when payment references are missing.
Original PR description
steps to reproduce: 1. install l10n_pe_reports_stock module 2. run the test `test_payment_reference_autocomplete_invoice` This commit ensures that the payment_reference field is always a string, because it returs false when it is None, which causes an assertion error build_error-75601 Forward-Port-Of: odoo/odoo#215873
Restaurant point-of-sale preparation printers now print cancelled kitchen order tickets when items are reduced or removed while other items are added. This helps kitchen staff see both new orders and cancellations, reducing missed changes and service errors.
Original PR description
Steps to reproduce: -------------------------- - Install POS restaurant & configure a preparation printer. - Open a session, order item A with some quantity from table X. - Again open table X & remove some qty of item A and add some qty of item B. - Order the changes. - On the preparation printer the cancelled KOT for item A won't appear. Issue: -------- - No receipt printed for the items which are cancelled. Cause: --------- - We have conditioned the printing in a way that if we found something new or if mode is updated rest prints won't be printed. Fix: ----- - Now we will have 2 receipts one for the new ordered items and the another with cancelled items. Task: 4805293
Website form fields that use contextual values now correctly keep their configured default values when edited and saved. This prevents editors from losing intended defaults on pages like Contact Us or recruitment forms, while still showing the right contextual value to visitors.
Original PR description
Scenario: - go to the /contactus page - edit the subject field and set a default value then save Result: the default value is not saved. Reason: in 13.0, field default value had priority over…
Scenario: - go to the /contactus page - edit the subject field and set a default value then save Result: the default value is not saved. Reason: in 13.0, field default value had priority over data-for so an issue was solved by b637a5e32f767b62736241042f88fa0cecf9f10b that if you saved a form, the data-for would become the default for all the uses of that form (so eg. a job position would be set for all job positions). In 8d0a63f35519090a74fcefedf482fea5f6eedd97 the priority was changed so data-for has higher priority than the default value, that made the prior fix unnecessary (just a nice to have, to not save the data-for as default that would be overridden by another data-for). The fix was reintroduced by ca433f38dbfe379dc9e0b823c7862eaec1a7ed9d but it removes default value if there is a data-for. Fix: remove the filling and removing of value: the data-for is not shown in the editor (allowing us to set default) but has the priority when rendering the field in non-editable mode. This is mirroring what is already done for data-fill-with. Side note: this commit also remove useless data-fill-with="undefined" attributes that are added when editing field. They shouldn't cause any issue unless someone add a "undefined" field in the prefilled fields. opw-4794903 Forward-Port-Of: odoo/odoo#216642 Forward-Port-Of: odoo/odoo#211083
This fix strengthens automated testing for electronic invoice files by ensuring XML namespace details match the expected format. It helps catch incorrect invoice formats earlier, reducing the risk of compliance or interoperability issues in localized e-invoicing flows.
Original PR description
At the moment, the `assertXmlTreeEqual` test method doesn't check that the namespaces in the generated XML match the ones in the expected XML. This is a 'feature', but in practice it prevents us from ensuring that our generated XMLs are correct. From now on, we also check namespace equality. Enterprise PR: https://github.com/odoo/enterprise/pull/87950 task-none
This fixes an issue in Point of Sale where custom payment method types added by another module did not appear in the selection list. Businesses using customized payment workflows can now add their own payment options more reliably.
Original PR description
* Create a new module try to inherit _get_payment_method_type but new selection not add in the selection list * Using lambda in selection will work 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
Credit notes created from vendor bills now carry negative landed cost amounts, so inventory value is reduced instead of increased. This prevents refunds from accidentally applying landed costs a second time and overstating stock value.
Original PR description
Before this PR, creating a landed cost in the following scenario incorrectly increased the stock valuation instead of reducing it: - Create a Purchase Order with a valuated product and a landed cost…
Before this PR, creating a landed cost in the following scenario incorrectly increased the stock valuation instead of reducing it: - Create a Purchase Order with a valuated product and a landed cost product in the order lines. - Validate the receipt of the PO. - Create the vendor bill from the PO and confirm it. - Create a landed cost from the vendor bill by clicking "CREATE LANDED COSTS" and selecting the receipt in the landed cost. - Validate the landed cost. - Create a credit note from the vendor bill. - Create a landed cost from the credit note by clicking "CREATE LANDED COSTS" and selecting the same receipt. - Validate the landed cost. In this scenario, the refund amount is treated as a positive landed cost, causing the stock valuation to increase again. This can lead to the landed cost being applied twice by mistake, overstating inventory value. After this PR, the landed cost line amounts for credit notes are correctly set as negative, which reduces the stock valuation instead of increasing it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr OPW #4844792 @qrtl QT5401 Forward-Port-Of: odoo/odoo#216378 Forward-Port-Of: odoo/odoo#212669
Checkout now filters available delivery methods by the appropriate company, preventing errors when some delivery methods belong to another company and others are shared or linked to the website company. This helps customers complete orders reliably in multi-company website setups.
Original PR description
Description of the issue/feature this PR addresses: Error during checkout when using delivery methods with mixed company assignments. Current behavior before PR: If you create a delivery method assigned to company X, and then create another without a company (i.e., assigned to the website company or left empty), the checkout process fails when trying to select a delivery method. Steps to reproduce: 1. Create a delivery method and assign it to company X. 2. Create another delivery method with no company or assign it to the website's company. 3. Go to the website and try to place an order. 4. The checkout will fail when selecting the delivery method. Desired behavior after PR is merged: Checkout handles delivery methods consistently, even when companies are mixed or missing. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216662 Forward-Port-Of: odoo/odoo#216515
The Time Off Balance report no longer applies a default period filter that could hide valid remaining days or hours. This prevents misleading balances when employees have allocations spanning different years, giving managers and HR teams a clearer view of available time off.
Original PR description
**Issue** In the "Balance" report, the number of days/hours left is incorrect when a period filter is applied. **Cause** The report groups all allocations for a certain time off type and returns a…
**Issue** In the "Balance" report, the number of days/hours left is incorrect when a period filter is applied. **Cause** The report groups all allocations for a certain time off type and returns a single `hr.leave.employee.type.report` which uses the start date of the record with the lowest id. The "Period" filter, using the start date of the records, will therefore not make sense. **Change** Remove the default period filter as trying to display a balance by period introduces too many complications. **Steps to reproduce** - Have an employee with 0 allocations. - Create an allocationfor this employee with a start and end date in the previous year for a certain time off type. - Create another allocation for this employee with a start and end date in the current year for the same time off type. - Time Off > Reporting > Balance - Bug: with the default filter (Period: current year), the "Number of days" and "Number of hours" left for that time off type shows nothing. However, when applying a filter for the previous year, both allocations are counted. opw-4715547
This fixes an issue where uninstalling the HR Contract module could leave HR menu items under the wrong parent menu. The module now restores the expected HR menu structure during uninstall, reducing confusion for users and administrators.
Original PR description
This PR adds an uninstall_hook to restore the correct parent menus under the hr module that were overridden by this module. Task: 4818020 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213954
This fixes an issue in Point of Sale where using quick-add amounts followed by another digit could leave the payment amount unchanged or turn it into an incorrect decimal value. Cashiers can now enter payment amounts more reliably, reducing checkout mistakes and manual corrections.
Original PR description
Steps to reproduce: =================== - Add a product to the orderline from the product screen - Click payment - Select any payment method - Enter the amount manually - Press `+20`, then press `2`, OR press `+20`, then press `6` Issue: ====== - In the case of `+20` and `2`, the expected result is `202`, but we get `20` - In the case of `+20` and `6`, the expected result is `206`, but we get `20.01` Cause: ====== - `formatCurrency` is used for the buffer, but the buffer should not depend on the currency Fix: ==== - Remove the usage of `formatCurrency` and treat the buffer as a string Task: 4850543 Forward-Port-Of: odoo/odoo#213294
The employee Resume section now allows scrolling when long experience descriptions are entered. This keeps the Add button accessible, preventing users from getting stuck when rich or table-based content takes up too much space.
Original PR description
**Steps to Reproduce :** 1. Install HR module. 2. Open an employee record. 3. Navigate to the Resume section. 4. Add an Experience entry. 5. Enter long description (using a table with multiple columns). 6. After that "ADD" button becomes no longer visible or usable. **Issue :** When a long description is added (especially with table content), It pushes the "ADD" button out of view, making it inaccessible. **Causes:** The container does not handle overflow properly, so elements extend beyond the visible area without scrollbars. **Solution:** Apply `overflow: auto !important;` to the affected container to allow scrolling when content overflows. This ensures the "ADD" button remains accessible. opw-4778793 **Before fix:**  **After fix:** 
Invoices linked to Saudi down payments now show a clear validation message if the down payment has not first been submitted to ZATCA. This prevents crashes during invoice posting and helps businesses follow Saudi e-invoicing compliance steps correctly.
Original PR description
Description of the issue/feature this PR addresses: This PR fixes a crash that occurs when posting an invoice linked to a down payment that has not yet been submitted to ZATCA. The issue is caused by a missing l10n_sa_confirmation_datetime on the referenced prepayment move. Current behavior before PR: When the prepayment invoice is not ZATCA-posted, its l10n_sa_confirmation_datetime is False, causing a crash during UBL generation for the final invoice. No clear error is shown to the user. Desired behavior after PR is merged: The system will raise a clear ValidationError, notifying the user that the related prepayment must be successfully submitted to ZATCA before continuing. This prevents silent failures and ensures proper compliance. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves Hoot, Odoo's internal unit testing framework, with better performance, fewer crashes, and more reliable test interactions. It also simplifies older testing helpers and improves the test debugging experience, helping developers maintain quality with lower risk to customer-facing features.
Original PR description
## Pull Request HOOT (PRHOOT) 34 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Enterprise: https://github.com/odoo/enterprise/pull/88949 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes keyboard navigation more reliable when users move the cursor up or down in editor content that includes file boxes. It prevents erratic cursor jumps and removes an unnecessary hidden placeholder left behind during content insertion, improving editing consistency.
Original PR description
### Approach: - Addressed an issue where cursor navigation using ArrowUp/ArrowDown resulted in unexpected behavior when the cursor was inside an .o_file_box or was expected to move into it. - The fix…
### Approach: - Addressed an issue where cursor navigation using ArrowUp/ArrowDown resulted in unexpected behavior when the cursor was inside an .o_file_box or was expected to move into it. - The fix uses horizontal position of the current caret and vertical position of neighboring line to resolve a target position using caretPositionFromPoint or caretRangeFromPoint, ensuring accurate and consistent cursor movement. ### Description of the issue/feature this PR addresses: - Pressing ArrowUp/ArrowDown caused erratic cursor behavior when navigating within or around a `file_box`. ### Desired behavior after PR is merged: - Cursor navigation behaves as expected when moving inside a `file_box`. - An empty text node was previously inserted into the DOM to preserve the caret position during content manipulation. This placeholder has been removed after the content is inserted. task-4671755 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes a bus module test more stable by ensuring websocket test changes apply only to the current worker instance. It reduces false test failures in automated validation, helping keep development and release pipelines more dependable.
Original PR description
This commit fixes the `subscribe to presence channels according to store data` test. Some of the websocket worker functions are debounced meaning some old worker functions can be called after the test ends. Since `_patchWebsocketWorker` with cleanup patches the prototype of the worker, patches can be executed from old workers which is an issue. This commit ensures only the actual instance is patched. fixes runbot-226354 Forward-Port-Of: odoo/odoo#216810
This update prevents an error when a subscription sales order has no previous invoice date. The system now uses today’s date as a fallback, helping subscription stock movements continue without interruption.
Original PR description
The Issue: Prior to this commit, When the sale order last_invoice_date is False, a traceback is thrown The Fix: To resolve this, We get the last_invoice_date or todays date opw-4403557
Users who only have permission to view shared PDF documents will no longer see the option to split PDFs. This prevents an error and keeps available actions aligned with each user's access rights.
Original PR description
When a user with only view permissions attempts to split a PDF, an error occurs: Unexpected token '<', "<!doctype "... is not valid JSON **Steps to Reproduce:** - Go to Documents. - Choose a PDF file. - Click on Share and select Internal Users with Viewer permission. - Copy the generated link. - Open the link in another window as a non-manager user. - Click on split PDF then split The fix consists in hiding the pdf split functionality for users without edit permission. opw-4354451
Customer statement emails now use the sender and reply-to addresses configured on the email template. This ensures businesses can control which address customers see and reply to, instead of unintentionally using the current user's email address.
Original PR description
Steps to reproduce:
Go to Settings> Email templates
Open the template Customer statements
Change the value in email from or reply to
Go to Accounting > Customers > Customers
Open a customer
Send a customer statement
Issue:
The address in use is not the same as we specified in the customer template
Cause:
if no email_from is provided, we will use the current partner's use's email address https://github.com/odoo/odoo/blob/cc0aaff5f93d5332c60d5bd8097173326a0a12b3/addons/mail/models/mail_thread.py#L2863-L2864
We don't check if the template has any email_from address defined
Note:
As from this fix, if no address is defined, by default it will be the `{{ object._get_followup_responsible().email_formatted }}`
opw-4864155The UAE payroll rules now match the government end-of-service calculator by applying the full 30-day compensation only after an employee completes the sixth year of service. This helps ensure final settlement amounts are calculated correctly and consistently with official guidance.
Original PR description
- to algin with UAE goverment eos calculator, salary rule is update to concider full 30 compensation after completing the 6th year not the 5th. Task: 4756963
Fixes an issue where adding a second rental product could shift the selected rental end date for customers in UTC+ time zones. This keeps the customer's chosen rental period consistent in the website cart, reducing booking mistakes and checkout confusion.
Original PR description
## Version
18.0
saas-18.1
Fixed from saas-18.2 thanks to commit 951433846e18e77a3d468af1f005b5c8e224ef89
## Issue
If user's timezone is in UTC+X, rental period changes after adding 2nd rental product to cart.
## Steps to reproduce
- Go to Rental App:
- Via `Products` create 2 rental products (`Product A` and `Product B`):
- Under the `Rental prices` tab, add a new pricing with a `Daily` period;
- Publish the products.
- Go to website's shop:
- Look for `Product A`:
- Select a one-day period (same date for start and end dates);
- Add the item to cart.
- Look for `Product B`:
- Click `Add to cart` button and see the end date change for the next day.
opw-4744250This update corrects test reference files for electronic payment and invoicing documents so they now verify XML namespace information properly. It helps ensure localized EDI and ISO 20022 documents are validated more accurately, reducing the risk of unnoticed format issues in future changes.
Original PR description
Before, we weren't asserting XML namespaces when calling `assertXmlTreeEqual`. As a result, many expected XMLs in EDI tests had incorrect namespaces. Now that we change the test method to check namespaces, we also need to fix the expected XMLs. Community PR: https://github.com/odoo/odoo/pull/214764 task-none
EasyPost shipping labels now include the related Odoo delivery reference, making it easier to match physical shipments and carrier dashboard entries with the correct Odoo delivery. This reduces manual lookup work and helps users track shipments more reliably.
Original PR description
Issue ----- When using the Easypost delivery service, we don't pass the move reference to the carrier. This makes it hard for the user to match the deliveries found on the carrier dashboard with the…
Issue ----- When using the Easypost delivery service, we don't pass the move reference to the carrier. This makes it hard for the user to match the deliveries found on the carrier dashboard with the corresponding Odoo move. Steps to reproduce ----- - Set an Easypost delivery method up - Create a sale - Add delivery product & get a rate - Confirm the sale - Go to the linked delivery & confirm it --> The printed label has no reference field Discussion ----- As per EasyPost: > The reference field within the shipment body is used for transmissions of electronic data between the shipper and EasyPost, and typically does not get expressed anywhere on the physical label. To get data to the label, you need to leverage the "print_custom" fields outlined in the options section of the shipment. See also https://docs.easypost.com/docs/shipments/options Visual comparison ----- DPD UK labels, before and after the change:  USPS labels, before and after the change:  ----- Ticket: opw-4681615
Repeat website appointment bookings made with the same email and phone now reuse the existing visitor contact instead of creating duplicates. This keeps customer records cleaner while ensuring contacts created by internal users are not changed by website visitors.
Original PR description
**Steps to reproduce:** 1. Install appointment and website 2. Book two appointments on the website without logging in, using the same email and phone number **Issue:** - Two separate contacts are…
**Steps to reproduce:** 1. Install appointment and website 2. Book two appointments on the website without logging in, using the same email and phone number **Issue:** - Two separate contacts are created each having one appointment, instead of a single contact with two appointments. **Cause:** https://github.com/odoo/enterprise/blob/c27021bb5bf5994c3e9500d91c6977ee7b795150/appointment/controllers/appointment.py#L683 - The appointment booking logic does not check for existing customers Based on the email and phone from website visitors. **Solution:** - Search for an existing contact created by the visitor before creating a new one. **Behaviour before this commit:** - If a visitor create multiple appointments with same crediantials (email, phone) then multiple contacts are being created - Converted public user from internal user will always create new contact. **Behaviour after this commit:** - If a visitor create multiple appointments with same crediantials (email, phone) then only one contact will be created. - Contact created by internal users will not be modified by a visitor - Converted public user from internal user will always create newa contact. opw-4884363
Users who work with inventory and helpdesk, but do not have sales permissions, can now create repair-related tickets without seeing an access error. The change avoids checking a sales order field when the user is not allowed to access it, making the repair workflow smoother for those roles.
Original PR description
### Before this PR If an user has only inventory, helpdesk group and it does not have "sales" permission , the error "you have not access on this field sale_order_id" appear. It appears because on helpdesk_sale that field is restricted to two specific groups. In the same module that fields is popped out during copy , but in the prepare of helpdesk_repair is accessed without checking permission ### After this PR The field is not accessed if it has no permission Forward-Port-Of: odoo/enterprise#86514
This fix prevents an error when older online banking records do not yet have a provider type set. It helps migrations complete successfully and keeps payment link status checks from failing on missing provider information.
Original PR description
The issue occurs because the value of the provider_type field is null. As a result, when the system attempts to compute the value of the account_online_linked Boolean field — which depends on both…
The issue occurs because the value of the provider_type field is null. As a result, when the system attempts to compute
the value of the account_online_linked Boolean field — which depends on both provider_type and account_online_link.
The error occurred due to a null `provider_type`.
157, in _compute_account_online_linked
batch.account_online_linked = account_online_link
and 'payment' in account_online_link.provider_type
TypeError: argument of type 'bool' is not iterable
An error occurred during migration.
The issue originates [here](https://github.com/odoo/enterprise/commit/eb78dd3b9a3d78bb6aa4ffcf35cee82c8e78224c) due to a `null` value in the `provider_type` field.
actually the field [provider_type](https://github.com/odoo/enterprise/pull/44357/files) is introduce in the version 17.0 this is because to improves the online synchronization process by ensuring that the third-party provider (TPP) involved in each sync is now stored and displayed.
- The provider is now automatically recorded during each synchronization.
- It is shown in both the form view and the tree view for better visibility.
- Previously, this information was not displayed, making it difficult to trace which provider handled the sync.
This change enhances transparency, traceability, and helps in debugging or support scenarios.
The issue arises because the value of the provider_type field is not set manually by the customer, as the field is marked [readonly](https://github.com/odoo/enterprise/blob/e4f0d273780274202cd0fd653c6a74320530842b/account_online_synchronization/views/account_online_sync_views.xml#L28) in the view.
This means users cannot edit or input a value for provider_type through the UI.
Instead, the value of the provider_type field is automatically computed when a third-party payment gateway (such as SaltEdge, Plaid, etc.) is connected to the system.
This setup process establishes a link (account_online_link) between the Odoo bank account and the external provider, and during that process,
the provider_type is set based on the provider's metadata.
If the connection is not properly established, the provider_type field may remain unset (None).
so if the value of provider_type is null and the when we going to computed the value of boolean field i.e account_online_linked which depends on the provider_type field and record in account_online_link see [here](https://github.com/odoo/enterprise/blob/e4f0d273780274202cd0fd653c6a74320530842b/account_online_payment/models/account_batch_payment.py#L156)
then issue is occur so to handle this issue safely, I have added a condition: if the value of provider_type is null, the account_online_linked field will be set to False.
```sql
=> select id,provider_type from account_online_link;
id | provider_type
----+---------------
6 |
12 |
13 |
(3 rows)
=>
```
```sql
('account_batch_payment.menu_batch_payment_purchases', 332, 'Accounting > Vendors > Batch Payments', 474):
Traceback (most recent call last):
File "/tmp/tmp2ec381z7/migrations/base/tests/test_mock_crawl.py", line 271, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmp2ec381z7/migrations/base/tests/test_mock_crawl.py", line 284, in mock_action
return self.mock_act_window(action)
File "/tmp/tmp2ec381z7/migrations/base/tests/test_mock_crawl.py", line 444, in mock_act_window
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmp2ec381z7/migrations/base/tests/test_mock_crawl.py", line 475, in mock_view_form
[data] = record.read(fields_list)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 3843, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4074, in _read_format
vals[name] = convert(record[name], record, use_display_name)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 7061, in __getitem__
return self._fields[key].__get__(self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1303, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1485, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 427, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5280, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 110, in determine
return needle(*args)
File "/home/odoo/src/enterprise/18.0/account_online_payment/models/account_batch_payment.py", line 156, in _compute_account_online_linked
batch.account_online_linked = account_online_link and 'payment' in account_online_link.provider_type
TypeError: argument of type 'bool' is not iterable
```
OPW-4910519
UPG-2999613
TBG-2091