Daily updates from Odoo
Navigate
Branch
Wednesday, July 2, 2025
72 changes
33 changes
New functionality added to Odoo
VoIP users can now access CRM leads directly from contact-related areas in the softphone, making it easier to connect calls with sales opportunities. The change also generalizes shared VoIP extension points so similar buttons can be reused across related apps.
Original PR description
This commit adds a button that connects the contacts to its leads via the VoIP module. It uses the same logic as "Applicant" button introduced before. Task-4855484 Community: https://github.com/odoo/odoo/pull/214031 Forward-Port-Of: odoo/enterprise#88960 Forward-Port-Of: odoo/enterprise#87294
Spreadsheet users can now create selection-based filters in addition to existing filter options. This makes it easier to narrow spreadsheet data using predefined choices, improving analysis and reporting workflows.
Original PR description
See community commit for details. Task: 3619413
Enhancements to existing features
WhatsApp conversations now include a “View Contact” action that opens the related contact profile directly. This helps users quickly access customer or operator details from a chat without navigating away manually.
Original PR description
For whatsapp conversations: Add a "View Contact" action that opens the whatsapp users partner form view. Community: https://github.com/odoo/odoo/pull/203079 task-4607618
Companies using Argentine electronic invoicing can now choose to show an “Operation Subject to Withholding” note on eligible invoice, credit note, and debit note PDFs. This helps businesses include the required withholding indication on type A and M documents when it applies, without forcing it for everyone.
Original PR description
In this PR: Add a company setting to show the legend 'Operation Subject to Withholding' on Invoice, Credit Note, and Debit Note PDFs of type A and M. Setting: Add Withholding Legend to Invoice PDF Field: l10n_ar_show_withholding_legend (per company) Shows the legend below the document letter when enabled. task-4837529
Bank statement reconciliation now avoids matching entries that include cash or credit card account lines when that would create invalid statement entries. This helps prevent reconciliation errors caused by multiple cash or bank accounts appearing on the same statement move.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/c0f8c5d17b9d78b640d744d8bfb6a2bb4002776a We changed a condition to have the possibility to match move with an account that allows the reconciliation but by doing so, we authorize moves with a cash line to be match. This will trigger a constraint since we cannot have multiple cash or bank accounts on the same statement move. To avoid that we add a condition that the type of the account can be reconcile but is not an asset_cash or liability_credit_card no task id Forward-Port-Of: odoo/enterprise#88659
Payroll pay runs can now generate payslips from selected employees as well as payroll versions, making the process easier when contract details are not selected directly. This improves payroll workflow flexibility while preserving automatic selection of valid contracts for the pay run period.
Original PR description
Problem ---------- Generation of payslip with valid_versions is not enough flexible With work entries, we have to generate payslips for employees. Objective ---------- Change the _get_valid_versions_domain to _get_valid_versions to get only ids Adapt the signature of generate_payslips to use employees or versions to generate payslips Solution ---------- Now the _get_valid_versions give the valid versions ids, so we can directly browse them or add them in a domain, the domain is not forced The generate_payslips can work with versions (first argument by default) and employees, if employee_ids are given, this will fetch valid versions for these employee depending on the pay run config directly. So via the front, we can call generate_payslips with a list of employees if we don't have versions directly. (it will automatically select all contracts valid in the range of payrun as before with contracts) task-4900019 Forward-Port-Of: odoo/enterprise#88768
Egypt and Saudi Arabia payroll setups now include default working calendars that better match local standard schedules. Demo companies, employee contracts, and payroll structures are aligned with these calendars, improving payroll configuration accuracy for those countries.
Original PR description
*: sa,eg - add a new calendar that match the std working schedule for those countries and assign it to thier demo comapny, employees contracts and payroll structure Task: 4724754
This change makes subscription stock tests choose the correct delivery record even when creation dates are not predictable. It helps keep automated checks stable and reduces false test failures without changing business workflows.
Original PR description
Linked to https://github.com/odoo/odoo/pull/171895. Test `simulate_period` was filtering only by date to get the last picking, but that was wrong. We should consider the two cases: 1st. Get the last picking created inside simulate_period(), independently of its date, as we cannot guarantee it will have the freezed date. 2nd. Only check for date in case picking was already created previously.
This update removes leftover development tasks from recent tax return improvements so the master branch stays aligned with Odoo's stable release policy. It affects accounting reports and Belgian VAT/Intrastat reporting cleanup, with minimal direct impact for day-to-day users.
Original PR description
Some leftover of the tax return misc improvements. Those were to be removed in master to not break the stable policy. See https://github.com/odoo/enterprise/pull/87351
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
Features or functions removed from Odoo
This update aligns Enterprise with related Community changes by removing references to an internal field that no longer exists. It also cleans up Helpdesk configuration by dropping an index setting that was ignored, reducing confusion without changing user-facing behavior.
Original PR description
#### [REM] base: remove complete_name from ir.model.fields Change tests because ir.model.fields.complete_name has been removed in community. #### [IMP] helpdesk: remove ignored index attribute Only trigram index is possible on translated fields. Since we add the warning in community version, remove ignored index attribute of helpdesk.sla.name https://github.com/odoo/odoo/pull/216355 https://github.com/odoo/upgrade/pull/7966
Code cleanup and technical improvements
The VoIP keypad search tests were reorganized into smaller, easier-to-maintain checks. This reduces the chance of unreliable automated test results and helps keep future VoIP changes safer to deliver.
Original PR description
This commit splits the "search for name" test into smaller tests for clarity and readability. It also removes the use of `edit` in test and uses `insertText` instead in order for the tests to be deterministic. This test was introduced in: https://github.com/odoo/enterprise/pull/87328 Forward-Port-Of: odoo/enterprise#89102
The timesheet grid code was reorganized to use safer, cleaner markup handling. This reduces internal security warnings in automated checks without changing the user-facing timesheet experience.
Original PR description
Use markup template and html functions to make the code cleaner and safer while no longer triggering ci/security flag.
The Helpdesk Forum ticket creation code was cleaned up to use safer standard formatting methods. This reduces false security alerts in automated checks without changing the user experience.
Original PR description
Use markup template and html functions to make the code cleaner and safer while no longer triggering ci/security flag.
This update removes an outdated search view setting across multiple Odoo Enterprise apps. The change helps keep the interface configuration consistent with the main Odoo platform and reduces maintenance overhead without changing day-to-day functionality.
Original PR description
Remove all the occurrences of expand attribute from search view. Community PR : https://github.com/odoo/odoo/pull/215362 task-4840720
Web Studio has been updated to work with recent platform service changes for field information loading and tree processing. This keeps report editing and view editing tools aligned with the latest Odoo framework without introducing new user-facing behavior.
Original PR description
In https://github.com/odoo/odoo/pull/216038: - the hook useLoadFieldInfo has been removed and a corresponding function loadFieldInfo has been added in the field service. - a new service tree_processor has been added Here we adapt web_studio to those changes.
Miscellaneous changes
Before this commut, the static props of delivery_button was not defined. This commit adds empty static props to the DeliveryButton component. Forward-Port-Of: odoo/enterprise#87714 Forward-Port-Of: odoo/enterprise#87511
Original PR description
Before this commut, the static props of delivery_button was not defined. This commit adds empty static props to the DeliveryButton component. Forward-Port-Of: odoo/enterprise#87714 Forward-Port-Of: odoo/enterprise#87511
39 changes
Security fixes and vulnerability patches
This update closes a permissions gap that could allow employees to change approved expense information when they should only be able to edit drafts. It helps protect approved expense records from unauthorized changes and strengthens expense approval controls.
Original PR description
The state changes right check was only done on specific method but it wasn't check at write level. Which allowed to bypass it. The record rule on hr_expense_user without a check on the state is in draft allow to change data on approved expense sheets. forward port : #189360
This fixes access control around salary contract pages so users can only view or interact with contracts they are allowed to access. It helps protect sensitive employee compensation information and reduces the risk of unauthorized exposure.
Original PR description
Backport: b642714d658d7180ab70ea171ad006e975c36449 task-4881974 Forward-Port-Of: odoo/enterprise#88776 Forward-Port-Of: odoo/enterprise#88489
Enhancements to existing features
The web interface framework was updated to a newer OWL release. This improves how translated text is handled, including accessibility labels that help assistive technologies present the interface correctly.
Original PR description
This brings two commits: - [FIX] parser: t-esc/t-out vs t-translation* - [IMP] compiler: make human-readable ARIA attributes translatable see https://github.com/odoo/owl/releases/tag/v2.8.0. Forward-Port-Of: odoo/odoo#216599
Uruguayan electronic invoices now send a valid item name consistently and place longer product details in the description field. This prevents duplicated product names on generated PDF reports and better matches DGI field limits.
Original PR description
This PR aims to improve the way we create NomItem and DscItem lines on the XML files we send to DGI in order to generate the PDF report. We have two fields to inform to DGI in an electronic invoice,…
This PR aims to improve the way we create NomItem and DscItem lines on the XML files we send to DGI in order to generate the PDF report. We have two fields to inform to DGI in an electronic invoice, NomItem which is mandatory an has a maximum of 80 characters to send, and DscItem that is optional an has a limit of 1000 chars. So we ensure NomItem is always sent, and the description will be filled like this: First, if the product name is longer than 80 chars, DscItem field will contain the characters that didn't fit in the NomItem field (characters from the 80th) Then it will contain the description of the product and the addenda content if it exists. Plus, I refactor the method _l10n_uy_edi_cfe_D_global_discount so it is also aligned with what I mentioned before. Another reason for this improvement is that, as the description of a product contains the product name at the beginning, we faced some issues when a user added a description on the fly in the line of the product, and then confirmed and printed the report. In this case, the name of the product was duplicated in the report. With this change, the description will only contain the the part of the product name that exceeds the 80th character. Example: 
Payroll calculations now include additional state-specific employer rates for Alabama, Colorado, and Washington. This helps ensure US payroll results better reflect current state obligations and reduces the need for manual payroll adjustments.
Original PR description
Added salary rules for state: - US: Alabama ESA rate - US: Colorado Support Surcharge rate - US: Colorado Solvency Surcharge rate - US: Washington EAF Rate task-4814709
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-2091Code cleanup and technical improvements
This update simplifies the internal unit test setup used across several Odoo Enterprise modules by replacing an older testing mechanism with a more maintainable approach. It is limited to tests, so it should reduce future maintenance effort without changing day-to-day product behavior for users.
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. Community: https://github.com/odoo/odoo/pull/216546
Documentation and clarification updates
This update records the contributor license agreement signature for GitHub user shawkialaddin. It helps ensure their future contributions can be accepted under the project's legal contribution requirements.
Original PR description
Description of the issue/feature this PR addresses: This PR contains the CLA signature for the GitHub user shawkialaddin. Current behavior before PR: CLA is not signed for this contributor. Desired behavior after PR is merged: CLA is properly registered, allowing contributions from this user.
This update adds an individual contributor agreement for mostafatwfiq. It helps keep contribution records complete and supports the project's legal compliance process.
Original PR description
Added mostafatwfiq.md to doc/cla/individual.
Miscellaneous changes
During odoo/enterprise#60393 some po files that had been deleted in odoo/odoo#172429 and odoo/odoo#172269 were re-added in. We remove them now as they are out of date + are not reachable to be translated/fixed without a PR.
Original PR description
During odoo/enterprise#60393 some po files that had been deleted in odoo/odoo#172429 and odoo/odoo#172269 were re-added in. We remove them now as they are out of date + are not reachable to be translated/fixed without a PR.
…eport Currently in bank reconciliation report we expect all the entries to have the balance encoded in journal currency However it may not be the case if an entry is posted in a misc journal set in another currency Steps to reproduce: - Create a new journal in another currency (€) than the company's ($) - Create a new journal entry using the journal main account - Go to the account dashboard > click on the 3 dots of the journal - Open the Reconciliation report Issue: The journal
Original PR description
…eport Currently in bank reconciliation report we expect all the entries to have the balance encoded in journal currency However it may not be the case if an entry is posted in a misc journal set in another currency Steps to reproduce: - Create a new journal in another currency (€) than the company's ($) - Create a new journal entry using the journal main account - Go to the account dashboard > click on the 3 dots of the journal - Open the Reconciliation report Issue: The journal entry amount is in company curreny (balance), but with the journal currency symbol (€) opw-4701349 Forward-Port-Of: odoo/enterprise#87313
**Issue:** When a resource is on leave for a particular day, and an open shift is created for that day, the open shift includes lunch time, which causes the total allocated hours to be incorrect. **Example:** - Shift duration: 1 week (27th to 31st January) - Resource on leave on 30th January - Move to the next week and copy the previous week's shift - New shift created: - Monday to Wednesday and Friday assigned - Open
Original PR description
**Issue:**
When a resource is on leave for a particular day, and an open shift is created for that day, the open shift includes lunch time, which causes the total allocated hours to be incorrect.
**Example:**
- Shift duration: 1 week (27th to 31st January)
- Resource on leave on 30th January
- Move to the next week and copy the previous week's shift
- New shift created:
- Monday to Wednesday and Friday assigned
- Open shift on Thursday (9 hours allocated)
However, 1 extra hour is added in the open shift.
**Steps to Reproduce:**
-Install the planning_holidays module.
- Create a shift for the week (27th to 31st January).
- Add leave for 6th February.
- Copy the previous week's shift.
- Check the allocated hours for 6th February.
task-4224781
Forward-Port-Of: odoo/enterprise#73478