Daily updates from Odoo
Monday, November 17, 2025
229 changes
21 changes
Enhancements to existing features
This update makes certain links in contract and payslip screens open the correct related record views. It improves navigation for HR users by sending them directly to the expected employee or contract information instead of an incorrect page.
Original PR description
The contract template form view is now written on the formview_action directly. This is a backport of https://github.com/odoo/enterprise/pull/97463 task-5082709
This change makes HR version records open in the most appropriate screen. Contract templates now open in the contract template view, while employee-related records open in the employee form with the right context, making navigation smoother and less confusing.
Original PR description
If the version record is a contract template, redirect to the version contract template view. Otherwise, redirect to the employee form view with the version_id in the context. This is a backport of https://github.com/odoo/enterprise/pull/97463 task-5082709 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
Resolved issues and error corrections
Fixed an issue in the website editor where adding an image to a grid could cause the page to keep loading indefinitely. This improves reliability when building pages, especially when using GIF or SVG images.
Original PR description
The action for adding an image was waiting on the `load` event on the image, but it may have already occurred, thus the promise would never resolve. With this commit, we do not wait if the img is already `complete`. Steps to reproduce (non-deterministic): - Open website builder - Click on a grid element (for example a "Banner" snippet) - Click on "Image" in "Add Elements" option - Add an image (it seems more likely to trigger the bug with a gif) - Bug: The dialog closes, and an infinite load follows task-5187071 opw-5167545
This update fixes product search in sales orders so users can find items by a supplier’s product name or code again. It restores context needed by the search logic after a previous cleanup removed it, improving day-to-day order entry speed and accuracy.
Original PR description
Commit 6e69b1d4a357bf236695a2ed5b09fd62de911872 cleaned up SO views and removed some context fields from the product_id and product_template_id fields which were in fact used in the `_search_display_name` override of the related models. This commit brings back those values to allow finding products by their seller product name or code. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235591
This update sends the database identifier to Odoo’s cloud service when SMS-related requests are made. It helps support teams more quickly identify the affected system and troubleshoot customer issues.
Original PR description
Send the db_uuid to IAP such that we can more easily debug and support our users in case of a problem. task-none Forward-Port-Of: odoo/odoo#235540 Forward-Port-Of: odoo/odoo#233912
When a lead is moved to a different sales team, its stage is now refreshed to match the stages allowed for that team. This prevents leads from staying in an outdated stage that may no longer be valid for the new team, helping keep CRM records accurate and consistent.
Original PR description
**Steps to reproduce:** - Install CRM and set the Leads configuration setting - Go to CRM > Configuration > Sales Teams - Create two Sales Teams - Go to CRM > Configuration > Stages - Create multiple stages specific to each team - Make the current user belong to both teams - Go to CRM > Leads - Create a new lead (stage is assigned here) - Change its Sales Team - Lead stage is not updated according to the team **Issue:** The `stage_id` of `crm.lead` is never updated after it is set. This means that changing the related team will not modify the possible stages of the lead (even if it should not be available to the current team). **Fix:** Check if the team of the lead is the same as the one of its current stage during `_compute_stage_id`. opw-4901009 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232136
The system now keeps the correct default document type when creating debit notes. This prevents the debit note wizard from accidentally replacing it with an invoice document type, making the default selection more reliable for users.
Original PR description
Restores code from v16 to define a default document type for debit notes on records with debit_origin_id. Previously, when using the wizard to generate a debit note, the default document type (related to debit notes) was being overwritten by the first document type associated with invoices. Although this behavior will be removed in v17, this fix is necessary to prevent overwriting the default value for now. Note: It's still possible to use the document type for invoices. Therefore, the change only affects the computation of the default value. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181106
This change removes an unnecessary database sequence created for each Point of Sale session once that session is closed. It helps keep the database cleaner and avoids accumulating unused sequences over time, which improves maintainability.
Original PR description
to avoid having too many postgres sequences, this make sure the sequence used by the pos session is cleaned up after being closed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235875 Forward-Port-Of: odoo/odoo#235500
This fix ensures the manufacturing work order’s cost is properly recorded when an operation is marked as done directly from the status widget. As a result, project profitability and gross margin calculations now include the expected labor cost in this workflow.
Original PR description
Backport of: 223ec6ac83ba2ec94f7ea394458aee0972bb8b44 **Original msg commit:** This commit fixes the problem of adding the hourly cost of the work center when marking an operation as done from the status widget. To reproduce the bug: 1- Create a work center with an hourly cost > 0. 2- Create an MO with 1 operation in that work center, expected time > 0. 3- Create and set a project on the MO. 4- Make sure that project has an analytic account. 5- Mark the operation as done from the status widget. (click on it and choose done, don't use the start button) 6- Go to the analytic account of the project and check the gross margin. = No cost of the workorder was added. Now, this commit takes into account the duration of the WO first when marking it as done directly from the status widget. opw-5170664 Forward-Port-Of: odoo/enterprise#99439
This fix ensures the POS shows the right message when communication with the Blackbox times out. It prevents users from seeing a misleading warning about the Fiscal Data Module, helping support teams and store operators understand the real issue faster.
Original PR description
Before this commit, in the case when there is a timeout communicating with the Blackbox in the POS, an incorrect error message was shown stating that "The IoT Box is connected but the Fiscal Data Module isn't". This message should only be shown when we receive a reply from the IoT box, but it tells us it cannot find the Blackbox. <img width="695" height="240" alt="image" src="https://github.com/user-attachments/assets/ec011f4a-42dd-4ffd-8741-350032897471" />
This change prevents grouped list views from crashing when sample data is shown alongside real group information. It makes list views handle sample records more consistently, so users can browse grouped data without errors in empty or partially empty views.
Original PR description
This commit reverts PR [1] which attempted to fix an issue with grouped list views with sample data. The issue occured when the web_read_group returned real groups that are all empty. When this…
This commit reverts PR [1] which attempted to fix an issue with grouped list views with sample data. The issue occured when the web_read_group returned real groups that are all empty. When this happened, the model kept and relied on the real groups information, in particular which groups are open ("folded" flag).
In kanban, this works fine because we use those real groups in the sample server, and populate them with sample records. However, we didn't do that for the list view, for an obscure reason. As a consequence, in list, we sometimes received sample groups that matched the real ones (same id, when grouped by many2one), so we re-used the real group information (i.e. the folded flag). We were then manipulating groups that we believed to be open, i.e. to have a `records` key, whereas the fake read group done by the sample server returned groups without that `records` key, leading to a crash.
PR [1] tried to fix web_read_group in the SampleServer, to take into account the `opening_info` and return a `__records` key for opened groups. However, the fix crashed if there were more open real groups than sample groups (i.e. 5).
This commit fixes the issue by generalizing the kanban logic to the list, i.e. by moving it to the RelationalModel. From now on, both kanban and list will use the real groups, and fill them with sample data if necessary.
In master, we'll go even further by allowing to manipulate those groups (e.g. edit, create new...) like we do in kanban.
[1] https://github.com/odoo/odoo/pull/226253
Issue reported on the feedback pad after migrating odoo.com to v19
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-prWhen a sales order’s pricelist is changed and prices are recalculated, optional products will now update correctly as well. This avoids showing outdated or incorrect prices on the order, helping users keep quotations and sales orders consistent.
Original PR description
### Steps to reproduce: - Create a sale order with a SOL and an optional product - Preview the sale order and add the optional product to the order - Go back to edit mode and change the pricelist -…
### Steps to reproduce: - Create a sale order with a SOL and an optional product - Preview the sale order and add the optional product to the order - Go back to edit mode and change the pricelist - Click on 'Update Prices' - Notice the optional product price won't change ### Cause: When updating the prices of the SOLs we filter some lines that we won't recompute. Upon this commit https://github.com/odoo-dev/odoo/commit/2d919694d5c9588e0644d5ba82b15b9d3f762373 we remove the optional products from the recordset that will get price recomputation. If sale_subscription is installed we will set the product's prices to 0 https://github.com/odoo/enterprise/blob/85e0689ba12442e22e83f3337749c7ad2eb9d7d8/sale_subscription/models/sale_order.py#L674 so the price of the 'Optional product' SOL will change but will be equal to 0 ### Fix: An exception for the filtering has been introduced as we will recompute the price of the optional products only if the pricelist is getting changed opw-5058609 Forward-Port-Of: odoo/odoo#234968 Forward-Port-Of: odoo/odoo#230053
This change corrects how payroll versions are chosen when creating payslips, so calculations now better match the payslip dates. It also removes an automatic date default that could lead to incorrect results, especially for manually created payslips.
Original PR description
Current version_id computation does not depend on payslip dates, which could very often lead to wrong calculations, in this PR we solve this by removing the cyclic dependency between dates and version compute by removing the default computation of the date_start, which is often wrong anyway in the case of a single manual payslip
The Job Page button on job cards now only appears when Online Posting is enabled. When it is available, the button correctly opens the job link, helping users avoid confusing or non-functional actions.
Original PR description
This commit fixes the visibility of the "Job Page" button on the job kanban view. The job page button is now invisible when the `Online Posting` setting is disabled and visible when it is enabled, and directs to the job link. task-5153230 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now remove the date from a draft payslip without triggering an error. This makes it safer to edit payslips in progress and helps prevent interruptions while correcting payroll data.
Original PR description
When removing the date in a draft payslip an exception was raised. This was fixed and a test was added to check the flow. Related to odoo/odoo#231247 task-5159666
This change prevents an error in payroll processing when a payslip date is empty or missing. It makes the system handle those cases safely instead of crashing, improving reliability for users and reducing interruptions.
Original PR description
The assertion was added to prevent the use of the _is_overlapping_period function with null or False dates. Which fixes an exception caused when a payslip's date was false/null. Related to odoo/enterprise#97013 task-5159666
This change fixes an issue in Malaysian e-invoicing where vendor credit notes could be rejected if the original bill had a custom reference. The system now uses the stored original invoice reference when generating the reversal document, helping submissions pass validation reliably.
Original PR description
Currently, customers get an error when trying to send the vendor credit note to MyInvoise if a reference has been set on the bill. ``` The validation failed with the following errors: The reference…
Currently, customers get an error when trying to send the vendor credit note to MyInvoise if a reference has been set on the bill. ``` The validation failed with the following errors: The reference document UUID [...] does not exist. The internal ID for DocumentUUID [...] does not match. ``` Steps to reproduce: - With an MY company setup - Create a bill and add a custom reference - Send Bill to MyInvois - Create credit note for the Bill - Send Credit note to MyInvoice Issue: Validation will fail because the reference does not match. In the reverse bill we always send the original bill name as original bill id, but also the reference could have been used. Analysis: A solution would be to send always the reference of the original vendor bill if present. However, the bill reference may be altered after submitting the e-invoice. A safer way is to retrieve the reference from the stored e-invoice. opw-5057050 Forward-Port-Of: odoo/odoo#234762 Forward-Port-Of: odoo/odoo#234199
This update refreshes a networking library used by the IoT box to help prevent unexpected disconnections. It should make connected devices more reliable and reduce interruptions for users relying on the IoT box.
Original PR description
This commit updates the PIP package websocket-client to 1.9.0 to fix disconnection issues. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235848 Forward-Port-Of: odoo/odoo#235748
Imported refund invoices for Italian e-invoicing now keep their refund status even when they match a purchase order. This prevents the document type from being changed incorrectly, reducing accounting errors during invoice import.
Original PR description
The `move_type` is changed after PO match. This PR fixes the case of import a refund that matches a PO so the `move_type` is not changed after matching. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235609 Forward-Port-Of: odoo/odoo#233907
Users can now mention every member of a group chat even when they are inside a thread. This fixes a limitation that previously only allowed mentioning oneself in that context, making threaded conversations more useful and consistent.
Original PR description
Before this commit, when inside a thread of a group chat, it would not be possible to mention channel members that are not inside said thread. Steps to reproduce: 1. Create group chat 2. Create a thread 3. Try to mention -> can only mention self This commit fixes the issue by: 1. In the `get_mention_suggestions_from_channel`: correctly adding in the store all partners inside the parent channel 2. In the suggestion service: taking the `channel_member_ids` from the `parent_channel_id` when present task-5233010 Forward-Port-Of: odoo/odoo#235793 Forward-Port-Of: odoo/odoo#234887
Documentation and clarification updates
This update adds Jonathan Osorio Alcala as an approved contributor under Vauxoo’s CLA record. It helps keep contributor licensing information current so code contributions can be processed smoothly.
Original PR description
Incorporate Jonathan Osorio Alcala (jonathanosalc) as Vauxoo's contributor. I confirm I have signed the CLA and read the PR guidelines at http://www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235181
9 changes
Resolved issues and error corrections
Fixed an issue where a public time off created in one company could incorrectly affect task working-time calculations in another company. This ensures task assignment timings are computed only with the relevant company's calendar, so users see accurate time-to-assign values.
Original PR description
__ ## Short functional explanation of the error Let's say we have 2 companies: company A and company B. We create a public time off of a few days starting before today and ending 2 days later in…
__ ## Short functional explanation of the error Let's say we have 2 companies: company A and company B. We create a public time off of a few days starting before today and ending 2 days later in company A, then switch back to company B. In company B, we create a project and a task, and assign this task. The working time to assign will stay at 0. ## Reproduction Steps 1. Switch to company A and create a timeoff starting before today and ending later. 2. Switch back to company B. Create a project, a stage and a task. 3. Enable the debugger. 4. The field Working Time to Assign is invisible by default, so open studio, click on View, and check Show Invisible Elements. 5. Click on the tab Extra info and on the block Working time to assign. Uncheck Invisible. 6. Close studio and assign someone to the task. Make sure that you do this operation at a different time than the one recorded for the last stage change. ### Expected behavior The hours under Working Time to Assign should compute the difference between the last time the task got its stage changed and the time of assignation ### Unexpected behavior Nothing happens ## Origin of the issue When computing the working time to assign, we also take into consideration leaves: if this happened during public holidays, we consider that it took no working time to get assigned. However, when a holiday is set in another company, the Working Time to Assign duration will be impacted, as the domain to retrieve the corresponding leaves is the following: https://github.com/odoo/odoo/blob/c7e965a61b7ce856c2daa8e2574cf4c60caf7a20/addons/resource/models/resource_calendar.py#L537-#L546 The company isn't taken into account in the domain, applying the holiday for every company. _________________________________________ opw-5222883 --- 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 prevents the system from replacing the default document type for debit notes with the invoice document type when creating a debit note. It ensures the correct default is shown during the process, while still allowing invoice document types to be selected if needed.
Original PR description
Restores code from v16 to define a default document type for debit notes on records with debit_origin_id. Previously, when using the wizard to generate a debit note, the default document type (related to debit notes) was being overwritten by the first document type associated with invoices. Although this behavior will be removed in v17, this fix is necessary to prevent overwriting the default value for now. Note: It's still possible to use the document type for invoices. Therefore, the change only affects the computation of the default value. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181106
This update prevents a crash that could happen when generating Belgian reports during migration for companies with a February 29 fiscal year end. The date calculation now adapts correctly to the real calendar year, so report processing completes reliably, including in leap-year scenarios.
Original PR description
``` File "/tmp/tmpm_3a__2e/migrations/account_reports/saas~18.3.1.0/end-account-returns.py", line 340, in migrate generate_or_refresh_all_returns(company) File…
```
File "/tmp/tmpm_3a__2e/migrations/account_reports/saas~18.3.1.0/end-account-returns.py", line 340, in migrate
generate_or_refresh_all_returns(company)
File "/home/odoo/src/enterprise/19.0/account_reports/models/account_return.py", line 228, in _generate_or_refresh_all_returns
self._generate_all_returns(fiscal_country.code, company, domestic_tax_unit)
File "/home/odoo/src/enterprise/19.0/l10n_be_reports/models/account_return.py", line 24, in _generate_all_returns
super()._generate_all_returns(country_code, main_company, tax_unit=tax_unit)
File "/home/odoo/src/enterprise/19.0/account_reports/models/account_return.py", line 281, in _generate_all_returns
report_type._try_create_returns_for_fiscal_year(main_company, tax_unit=tax_unit)
File "/home/odoo/src/enterprise/19.0/account_reports/models/account_return.py", line 353, in _try_create_returns_for_fiscal_year
period_date_from, period_date_to = self._get_period_boundaries(main_company, date_pointer)
File "/home/odoo/src/enterprise/19.0/account_reports/models/account_return.py", line 530, in _get_period_boundaries
start_day, start_month = self._get_start_date_elements(company_id)
File "/home/odoo/src/enterprise/19.0/l10n_be_reports/models/account_return.py", line 16, in _get_start_date_elements
fiscal_year_date = date(2025, int(main_company.fiscalyear_last_month), main_company.fiscalyear_last_day)
ValueError: day is out of range for month
```
```
(Pdb) main_company
res.company(3,)
(Pdb) main_company.fiscalyear_last_month
'2'
(Pdb) main_company.fiscalyear_last_day
29
(Pdb) date_from
datetime.date(2025, 3, 1)
```
- During the migration process the system calls [_generate_or_refresh_all_returns](https://github.com/odoo/upgrade/blob/e20a9e2edec4441b2c7aa5858db2a53fb2e9b215/migrations/account_reports/saas~18.3.1.0/end-account-returns.py#L340) which internally uses [_get_start_date_elements](https://github.com/odoo/enterprise/blob/ebdc2fe2ade72b1505dac5490b7df2a1d06fcb4b/l10n_be_reports/models/account_return.py#L14) to compute the fiscal year start date.
- The customer has configured fiscalyear_last_month = February and fiscalyear_last_day = 29 Because of this configuration, the method attempts to construct 29th February 2025, which is invalid since 2025 is not a leap year. The issue occurs because the method uses a hardcoded year [(2025)](https://github.com/odoo/enterprise/blob/ebdc2fe2ade72b1505dac5490b7df2a1d06fcb4b/l10n_be_reports/models/account_return.py#L16) instead of determining the year dynamically.
- I reviewed implementations in other localizations and found that this logic has [1](https://github.com/odoo/enterprise/blob/ebdc2fe2ade72b1505dac5490b7df2a1d06fcb4b/l10n_uk_reports/models/account_return.py#L33), [2](https://github.com/odoo/enterprise/blob/ebdc2fe2ade72b1505dac5490b7df2a1d06fcb4b/l10n_nz_reports/models/account_return.py#L8) already been corrected there to compute the appropriate start date dynamically.
- I’ve updated this localization to follow the improved implementation used in other countries, so the start-date calculation now works correctly in all cases, including leap years and any fiscal year settings the customer may configure.
opw-5249243This change ensures that when an Italian electronic invoice refund is imported and matched to a purchase order, its document type stays as a refund instead of being changed incorrectly. This helps keep accounting records accurate and prevents mismatched invoice handling.
Original PR description
The `move_type` is changed after PO match. This PR fixes the case of import a refund that matches a PO so the `move_type` is not changed after matching. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235609 Forward-Port-Of: odoo/odoo#233907
This update fixes page URLs so they work correctly when users type, copy, or paste certain Unicode characters. It prevents some pages from showing a 404 error, especially in browsers that normalize URLs differently.
Original PR description
Scenario: - create a page with url "가" (\N{HANGUL SYLLABLE GA}) then in safari: copy the url to open it in a new tab => a 404 error is shown in all browser: go to /가 writing it manually => a 404…
Scenario:
- create a page with url "가" (\N{HANGUL SYLLABLE GA})
then in safari: copy the url to open it in a new tab => a 404 error is shown
in all browser: go to /가 writing it manually => a 404 error is shown
Cause:
We decompose the unicode combination to remove diacritics, but never
recompose them, so we save the slug
\N{HANGUL CHOSEONG KIYEOK}\N{HANGUL JUNGSEONG A} (NFD normalization)
instead of \N{HANGUL SYLLABLE GA} (NFC normalization). Those appear
exactly the same, but when typing you would usually use the NFC one.
Comparing other software, they usually convert NFD to NFC but not the
other way.
When you use the address bar in safari, the URL is normalized with NFC
so you can't type or copy paste a NFKD path to get to it (and can only
get to it by link).
But the issue still exists for other browser where you will usually
manually type NFC and not NFKD.
This is not reproduced, but this could also have effect with search motor
that would normalize link content.
Fix:
When creating slug, normalize to NFC after the removal of diacritics.
opw-5184532
__pr note:__
the original ticket also reported about removal of diacritical mark in Vietnamese and Japanese, but this seems a more of a feature for master change since we have had "éléphant" becomes "elephant" since forever.
other services that allow unicode in path (such as wordpress, wix) seems to just keep the diacritics and normalize to NFC even if the input was in NFD.
for NFD / NFC explanation: https://docs.python.org/3/library/unicodedata.html#unicodedata.normalizeThis update corrects automated test failures in the tax reporting area. It ensures the recent tax report changes are validated properly, helping keep accounting reports reliable.
Original PR description
See https://github.com/odoo/enterprise/commit/5291d0249ba925182fb9e670f9b46b9e57bda00c Forward-Port-Of: odoo/enterprise#98891
When a sales order’s pricelist is updated, the prices of optional products will now be recalculated correctly. This prevents customers and sales teams from seeing outdated optional product prices after using the update-prices action.
Original PR description
### Steps to reproduce: - Create a sale order with a SOL and an optional product - Preview the sale order and add the optional product to the order - Go back to edit mode and change the pricelist -…
### Steps to reproduce: - Create a sale order with a SOL and an optional product - Preview the sale order and add the optional product to the order - Go back to edit mode and change the pricelist - Click on 'Update Prices' - Notice the optional product price won't change ### Cause: When updating the prices of the SOLs we filter some lines that we won't recompute. Upon this commit https://github.com/odoo-dev/odoo/commit/2d919694d5c9588e0644d5ba82b15b9d3f762373 we remove the optional products from the recordset that will get price recomputation. If sale_subscription is installed we will set the product's prices to 0 https://github.com/odoo/enterprise/blob/85e0689ba12442e22e83f3337749c7ad2eb9d7d8/sale_subscription/models/sale_order.py#L674 so the price of the 'Optional product' SOL will change but will be equal to 0 ### Fix: An exception for the filtering has been introduced as we will recompute the price of the optional products only if the pricelist is getting changed opw-5058609 Forward-Port-Of: odoo/odoo#234968 Forward-Port-Of: odoo/odoo#230053
This update fixes how tax reports are grouped and filed when a business belongs to a tax unit. OSS reports now correctly include all companies in the same unit, and standard tax returns are tied to the main company responsible for filing. This helps prevent missing or misassigned tax information in multi-company setups.
Original PR description
This PR delivers multiple fixes to ensure consistent and accurate behavior when working with tax units across OSS and standard tax return reports: [FIX] l10n_eu_oss_reports: Correct Tax Unit…
This PR delivers multiple fixes to ensure consistent and accurate behavior when working with tax units across OSS and standard tax return reports: [FIX] l10n_eu_oss_reports: Correct Tax Unit Detection for OSS Reports OSS reports lack a country, causing _get_available_tax_units to return no results. As a consequence, only the environment's main company was considered. This fix ensures that when multiple companies belong to the same tax unit, their OSS reports are correctly consolidated under that shared unit. [FIX] account_reports: Link Tax Unit Returns to the Main Company When generating domestic tax returns for a company that is part of a tax unit, the main company of the unit should be used since it is responsible for filing. This update ensures tax return generation is always aligned with the appropriate main company. [FIX] account_reports: Enforce Main Company When Generating Report Options get_options previously relied on the order of companies within a tax unit, assuming the first entry was the main company. Because this order is not guaranteed, the call is now explicitly scoped using with_company to ensure the main company is always used when preparing report options.
Documentation and clarification updates
This change updates Vauxoo’s contributor agreement record to include Jonathan Osorio Alcala as an approved contributor. It is an administrative/legal update that helps keep contributor records current and ready for future code contributions.
Original PR description
Incorporate Jonathan Osorio Alcala (jonathanosalc) as Vauxoo's contributor. I confirm I have signed the CLA and read the PR guidelines at http://www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235181
1 change
Enhancements to existing features
The IoT Box technical information now includes a clickable link to the exact source commit used in the image. This makes it easier to verify which build is running and speeds up troubleshooting and support checks.
Original PR description
To ease checking the HEAD commit on the IoT Box, we now compute the github url to the commit, and redirect to it clicking on the hash in the technical information tab. Forward-Port-Of: odoo/enterprise#99539 Forward-Port-Of: odoo/enterprise#99422
41 changes
Enhancements to existing features
Employees can now view and select a VoIP provider themselves instead of relying on an administrator for every change. This makes provider switching simpler while still keeping the information they can access limited to what they need.
Original PR description
We now allow base.group_user to have read access to voip.provider so that user can change provider by themselves. Note that the visible fields to base.group_user are still limited. Task-5262635
This update adds a button to create a CFDI for all payslips in a payroll run at once, instead of handling them one by one. It helps payroll teams complete Mexican payroll reporting faster and with less manual work.
Original PR description
This adds a button to generate a CFDI for the whole payrun when ready. Task: 5224206
This update refreshes the automatic database backup module and its supporting files to align with the latest v19 codebase. It helps keep backup scheduling, notifications, and related documentation current so system backups remain reliable and easier to maintain.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Maintenance app is being updated so equipment opens in a table-style list by default instead of separate cards. This makes it easier for teams to scan, compare, and manage equipment details at a glance while keeping the same underlying features.
Original PR description
Thanks for asking me to work on this. I will get started on it and keep this PR's description up to date as I form a plan and make progress. <!-- START COPILOT CODING AGENT SUFFIX --> <details>…
Thanks for asking me to work on this. I will get started on it and keep this PR's description up to date as I form a plan and make progress. <!-- START COPILOT CODING AGENT SUFFIX --> <details> <summary>Original prompt</summary> > In the maintenance module (addons/maintenance) for Odoo 18, change the equipment view from individual blocks (kanban view) to a table format (list/tree view) as the default view. > > The changes should: > 1. Modify the equipment action in addons/maintenance to set the tree/list view as the default view instead of kanban > 2. Update the view mode order to prioritize list/tree view over kanban view > 3. The tree view should display equipment in a table format with columns including: equipment name, category, equipment location, serial number, model, effective date, cost, and responsible person > 4. Keep all existing functionality intact - just change the default display format from kanban blocks to a table > > Files that likely need modification: > - addons/maintenance/views/maintenance_views.xml (to set default view mode) > - Any action definitions for equipment that currently default to kanban view > > The goal is to show all equipment in a table/grid format for better overview and management instead of individual card blocks. </details> *This pull request was created as a result of the following prompt from Copilot chat.* > In the maintenance module (addons/maintenance) for Odoo 18, change the equipment view from individual blocks (kanban view) to a table format (list/tree view) as the default view. > > The changes should: > 1. Modify the equipment action in addons/maintenance to set the tree/list view as the default view instead of kanban > 2. Update the view mode order to prioritize list/tree view over kanban view > 3. The tree view should display equipment in a table format with columns including: equipment name, category, equipment location, serial number, model, effective date, cost, and responsible person > 4. Keep all existing functionality intact - just change the default display format from kanban blocks to a table > > Files that likely need modification: > - addons/maintenance/views/maintenance_views.xml (to set default view mode) > - Any action definitions for equipment that currently default to kanban view > > The goal is to show all equipment in a table/grid format for better overview and management instead of individual card blocks. <!-- START COPILOT CODING AGENT TIPS --> --- 💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more [Copilot coding agent tips](https://gh.io/copilot-coding-agent-tips) in the docs.
This update makes sure that links from payroll and contract screens open the correct employee or contract forms. It improves navigation for users by sending them to the intended record view instead of an incorrect or outdated one.
Original PR description
The contract template form view is now written on the formview_action directly. This is a backport of https://github.com/odoo/enterprise/pull/97463 task-5082709 Forward-Port-Of: odoo/enterprise#99486
When users open a version record in HR, they are now sent to the most relevant screen: contract templates open in the contract template view, while employee-related versions open in the employee form with the correct version already selected. This makes navigation more accurate and reduces confusion when reviewing or editing HR version data.
Original PR description
If the version record is a contract template, redirect to the version contract template view. Otherwise, redirect to the employee form view with the version_id in the context. This is a backport of https://github.com/odoo/enterprise/pull/97463 task-5082709 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#235691
Resolved issues and error corrections
This change makes the purchase catalog suggestion test more reliable by moving it to a test setup that better handles timing delays. It prevents random failures in automated builds without changing the user-facing purchasing flow.
Original PR description
Description of the issue/feature this PR addresses: Fixes non deterministic runbot error in the purchase catalog suggestion JS tour: https://runbot.odoo.com/odoo/runbot.build.error/233744 Current behavior before PR: We test the adding product quantity behavior of the kanban product record with the suggestion feature ON **in a JS tour.** which has a non deterministic behavior on the runbot due to a debounce on an RPC. Desired behavior after PR is merged: Perform the same functionality test but in Hoot testing (which allows for parallel testing) and can better handle awaiting the debounce on the AddProduct RPC call. Use this PR as reference for the Hoot test odoo/enterprise#63041 (see the discussion on runAllTimersin the above mentionned PR if unclear --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change fixes an error that appeared when users grouped the Chart of Accounts by Status. The view now works correctly instead of showing a traceback, making it easier to review accounts by status without interruption.
Original PR description
When grouping by the ``Status (audit_status)`` field in the Chart of Accounts view, A traceback will appear. Steps to reproduce the error: - Install ``Accounting`` module - Go to Accounting > Configuration > Chart of Accounts - Group By: ``Status (audit_status)`` field Traceback: ```py SyntaxError: syntax error at or near "," LINE 1: SELECT , COUNT(*) FROM "account_account" WHERE "account_acco... ``` https://github.com/odoo/enterprise/blob/9ebe781f2abd399ad4610114a75993b784f71921/account_reports/models/account.py#L319-L321 In the main view of ``acount.account``, ``working_file_id`` is not available in the context, So, ``working_file`` becomes ``False`` and ``_field_to_sql`` returns an empty SQL(). This results in the above traceback when grouping by the Status field. sentry-6944233306
This update makes payroll PDF generation more resilient when a record cannot be rendered. Instead of letting the whole scheduled process fail and eventually disable itself, the error is now saved on the record and the remaining files continue to be processed.
Original PR description
When rendering PDF files, `_get_rendering_data` is expected to return a dict with the key `error` when needed. Some localizations respect this correctly, but others will raise an UserError instead. In particular, the `Payroll: Generate pdfs` cron will keep trying to generate the file and the `UserError` will never be caught, so the scheduled action will eventually be deactivated. With this fix, the exception is caught, the message is recorded on the sheet, and the PDF is skipped. The cron will then keep processing the other records. Source: investigation after the cron got disabled on our server
This update prevents product quantities in the online shop from becoming decimal values when packaging rules are applied. It rounds quantities down so customers only see valid whole-number quantities, avoiding confusing or incorrect stock displays.
Original PR description
### Issue: In ecommerce quantity can become decimal. #### To reproduce: 1- Add a packaging `Pack of 6` to the product 2- Uncheck `continue selling` 3- Update in-stock quantity of the product to 9 4- In product shop page and increase the qty to 9 5- Change the packaging option to `Pack of 6` Talked with PO about this issue. There are no use cases in ecommerce where the quantity needs to be a decimal number. We should round the quantity down, as in this instance where: - In-stock quantity: 9 - Packaging: Pack of 6 The `free_qty` should be 1. opw-5237233
This update prevents list views from crashing when they use sample data together with grouped results. It makes list behavior consistent with kanban so empty real groups are handled safely and users can continue browsing without errors.
Original PR description
This commit reverts PR [1] which attempted to fix an issue with grouped list views with sample data. The issue occured when the web_read_group returned real groups that are all empty. When this…
This commit reverts PR [1] which attempted to fix an issue with grouped list views with sample data. The issue occured when the web_read_group returned real groups that are all empty. When this happened, the model kept and relied on the real groups information, in particular which groups are open ("folded" flag).
In kanban, this works fine because we use those real groups in the sample server, and populate them with sample records. However, we didn't do that for the list view, for an obscure reason. As a consequence, in list, we sometimes received sample groups that matched the real ones (same id, when grouped by many2one), so we re-used the real group information (i.e. the folded flag). We were then manipulating groups that we believed to be open, i.e. to have a `records` key, whereas the fake read group done by the sample server returned groups without that `records` key, leading to a crash.
PR [1] tried to fix web_read_group in the SampleServer, to take into account the `opening_info` and return a `__records` key for opened groups. However, the fix crashed if there were more open real groups than sample groups (i.e. 5).
This commit fixes the issue by generalizing the kanban logic to the list, i.e. by moving it to the RelationalModel. From now on, both kanban and list will use the real groups, and fill them with sample data if necessary.
In master, we'll go even further by allowing to manipulate those groups (e.g. edit, create new...) like we do in kanban.
[1] https://github.com/odoo/odoo/pull/226253
Issue reported on the feedback pad after migrating odoo.com to v19
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-prThis update corrects how grouped list views calculate the width of the group header. As a result, grouped lists should now display columns more accurately and avoid layout issues when optional fields are shown.
Original PR description
This commit removes the colspan incrementation for optional fields in the group name. The incrementation was redundant, as the group configuration cog menu <th> is always present in the column for optional fields when the list is grouped. This ensures the colspan value now correctly reflects the actual number of visible columns. task-5261958
Regular users can now create Global Invoices in the Mexican localization without getting an access error. This fixes a permissions issue that previously blocked non-admin users from completing the process and ensures the CFDI document is created successfully.
Original PR description
## Issue: When creating a Global Invoice with a non-admin user (e.g., demo), an Access Error was raised: `Sorry, you are not allowed to access this document` ## Cause: This commit change the…
## Issue: When creating a Global Invoice with a non-admin user (e.g., demo), an Access Error was raised: `Sorry, you are not allowed to access this document` ## Cause: This commit change the attachment creation to use the SUPERUSER: https://github.com/odoo/enterprise/pull/95197 However, updating `attachment.res_id` then required `base.group_system` access rights, preventing regular users from modifying the attachment As a result, non-admin users (like demo) triggered an access error during Global Invoice creation ## Steps to reproduce: - Switch to the MX company - Create a product with an UNSPSC Category (Accounting Tab) - Create and Confirm an Invoice for the product (enable CFDI to public) - Connect as Demo - Go in Accounting > Customers > Invoices - Toggle the last created invoice checkbox - Actions > Create Global Invoice - Before the fix, the Access Error is displayed - Check in the invoice Chatter for the Global CFDI document creation success opw-5181925 Forward-Port-Of: odoo/enterprise#98218
This update fixes an error that could cause a crash when creating a group time off request that overlaps with an existing one. It also corrects the wording of the message shown to users, so they now get a clear notification instead of a traceback.
Original PR description
Issue: When generating a new group time off, if the leave type uses "hour" as the request unit (e.g., unpaid or extra hours), and there is a conflicting leave request for the same time period, a traceback occurs. Steps to Reproduce: - Generate a group time off using this leave type. - Ensure there is an existing leave request that overlaps with the requested time. - Observe the traceback error. Root Cause: The translation function _ is invoked incorrectly in the error message, and there are typos in the message text. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Product descriptions in the online shop now adapt better to the available space, making long text easier to read in showcase and card list layouts. Editing descriptions in showcase mode also works more smoothly because the overlay no longer blocks access to the text.
Original PR description
On showcase and card list design, the description can be very long making the paragraphs hard to read. The readability standard for comfortable reading is ~66 characters. The responsive font-size on these designs were not properly following the container width. On showcase, in edit mode the description couldn't be edited because the overlay was displayed over it. task-5150655 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The system now avoids using the mobile phone search feature until the user has typed at least three characters. This prevents an error from appearing as soon as someone starts typing and makes contact search feel smoother.
Original PR description
`phone_mobile_search` doesn't allow you to search for less than 3 characters. This commit excludes `phone_mobile_search` from the search domain when there are less than 3 characters. This avoids triggering an UserError on the first characters typed. Forward-Port-Of: odoo/enterprise#99548
The FEC import process has been adjusted to load only the partner details it actually needs, instead of pulling in every available field for all partners. This reduces memory usage and helps prevent import failures on large databases.
Original PR description
### Description: When importing an FEC, Odoo will fetch all the partners to link the new imported records to the existing partners. The issue is that it triggers the prefetching of all the fields of the partners (304k partners in their case), causing a memory error. To avoid that, we can just fetch the field that we need (e.g. "name" and "ref"). ### Reference: opw-5153555 Forward-Port-Of: odoo/enterprise#98483
This update corrects how fixed local taxes are written into Mexican electronic invoices. It prevents the tax amount from being multiplied by 100 in the XML, so the generated CFDI shows the right value and avoids reporting errors.
Original PR description
Steps to reproduce: 1. With an MX Company setup configure a new tax as follows - Tax Computation: Fixed - SAT Tax Type: Local - Factor Type: Cuota - Amount: 5 2. Create a customer invoice with the tax 3. Generate CFDI Issue: In the XML the ImpuestosLocales node contains `<implocal:TrasladosLocales ImpLocTrasladado="VAT 0%" Importe="20.00" TasadeTraslado="500.00"/>` The tax fixed amount was multiplied by 100 This occurs because we don't check if the tax is fixed when normalizing the amount opw-5132807 Forward-Port-Of: odoo/enterprise#99431 Forward-Port-Of: odoo/enterprise#98988
When a delivery is split into two pickings, the availability status of the original move is now recalculated correctly. This prevents the system from showing outdated stock availability information and helps users rely on accurate delivery statuses.
Original PR description
Steps to reproduce: - Create a storable product “P1” - Update its quantity to 10 - Create a delivery picking with 10 units of P1 - Confirm → The picking is in “Ready” state and the move is “Available” - Update the “Quantity” of P1 to 6 units in the picking → The move state is recomputed to “Partially Available”, since the demanded quantity exceeds the quantity done. https://github.com/odoo/odoo/blob/18.0/addons/stock/models/stock_move.py#L2207-L2208 - Split the picking Problem: A new picking is created with 4 units in quantity and its move is “Available”, but the original move with 6 units does not have its state recomputed. opw-5173374 Forward-Port-Of: odoo/odoo#232914 Forward-Port-Of: odoo/odoo#232516
When a shape is applied to a background or image, it is now clearly highlighted in the shape selector. This makes it easier for users to see the current setting and improves the overall usability of the editor, including better keyboard support and panel behavior.
Original PR description
Before this commit, when a shape was applied to a background or an image, that shape was not highlighted in the shape selector. After this commit, active shapes are highlighted with a border in the shape selector. task-5187272 Forward-Port-Of: odoo/odoo#233035
This fix prevents an error that could happen when a stock move line has no quantity. It helps ensure inventory valuation calculations continue smoothly instead of failing in these edge cases.
Original PR description
The method, _get_valued_qty introduced in this commit: https://github.com/odoo/odoo/commit/08b62a4bbcc6f9a391b2cc00a621ef4c76100229#diff-ad6229e976ce0bd1592e805b88e9813ac4e3f6fb989d3dfb8dfb8b70af03cd58 because move_lines can have quantity as zero. This is where the value of in_qty comes from. 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 change improves automated tests by making unfinished drag-and-drop actions safely cancel themselves at the end of a test. It prevents delayed errors from appearing after tests have already finished, which makes test runs more stable and easier to trust.
Original PR description
Before this commit, when initiating an unfinished drag sequence (i.e. calling `drag` without `drop` or `cancel`), the drag sequence was ended by destroying the component, which could throw asynchronous errors after the test finished. One possible fix would be to wait for these errors upon ending a test, but this process is handled by Owl and through a possible chain of promises, which would have to be accounted for by an arbitrary amount of 'animationFrame' or 'advanceTime' calls. Instead, the `contains...drag` and `contains...dragAndDrop` now handle a single drag sequence at a time, with a systematic cleanup after each test in case a drag sequence has been left pending. In such cases, the sequence is canceled. Enterprise: https://github.com/odoo/enterprise/pull/99369 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235826 Forward-Port-Of: odoo/odoo#235359
This fix removes an access issue that could block Recruitment Administrators from sending referral campaigns when they do not have Employees access. It ensures the campaign action works for the intended recruitment users, improving the workflow for hiring teams.
Original PR description
STEP TO REPRODUCE:
------------------
1- Give to Marc Demo the right : Recruitment / Administrator (be sure he doesn't have any right on Employees)
2- Log as Marc Demo
3- Go to Recruitment
4- Click on the three dots in kanban card
5- Click on Referral Campaign
6- Click on Send
You will have an access error
This user (with these groups) should be able to send a referral campaign
task-5082344
Forward-Port-Of: odoo/enterprise#98773
Forward-Port-Of: odoo/enterprise#96746This update ensures changes to Belgian Dimona payroll fields are properly tracked in the version history. It resolves a failing automated test and helps keep change logs complete and reliable for payroll-related updates.
Original PR description
The test_hr_version_fields_tracking was failing because the Belgian Dimona fields in hr.version model were missing tracking=True. task-5122440 Forward-Port-Of: odoo/enterprise#95735
This change restores the correct default document type when creating debit notes. It prevents the system from accidentally replacing that default with an invoice document type, which helps avoid confusion and ensures debit notes start with the right settings.
Original PR description
Restores code from v16 to define a default document type for debit notes on records with debit_origin_id. Previously, when using the wizard to generate a debit note, the default document type (related to debit notes) was being overwritten by the first document type associated with invoices. Although this behavior will be removed in v17, this fix is necessary to prevent overwriting the default value for now. Note: It's still possible to use the document type for invoices. Therefore, the change only affects the computation of the default value. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181106
This fix prevents Studio from crashing when editing JSON-based fields such as analytic distribution. It adds the missing placeholder support so dynamic widget settings work correctly and the editor stays usable.
Original PR description
When trying to edit the `analytic_distribution` field using Studio, the following traceback occurred: `Caused by: TypeError: Cannot read properties of undefined (reading 'subOptions')` This happened because the new option `placeholder_field` was [introduced](https://github.com/odoo/odoo/commit/6620ebbd184de6f106fceb4427a081b61d97296a) for dynamic placeholders in widget. However, there was no support declared for `placeholder` inside the `FIELD_TYPE_ATTRIBUTES` definition for the `json` field type. This commit adds `EDITABLE_FIELD_ATTRIBUTES.placeholder` to the `json` field type, allowing widgets on JSON fields to correctly handle `placeholder_field` options without causing a Studio crash. opw - 5180896 upg - 3249816
This update makes sure drag-and-drop actions used in automated tests are fully completed before the test ends. It helps prevent unfinished test steps from being canceled too early, improving the reliability of web and Gantt-related test results.
Original PR description
Since drag sequences are automatically canceled at the end of tests, 'cancel' or 'drop' calls should be properly awaited before the end of a test. This commit ensures that these actions are properly finished before a test ends. Community: https://github.com/odoo/odoo/pull/235359 Forward-Port-Of: odoo/enterprise#99559 Forward-Port-Of: odoo/enterprise#99369
This fixes an issue where adding a shape to certain Unsplash images could fail after selecting images from a multi-word search. The image path is now handled correctly, so users can edit these images without encountering an error.
Original PR description
Steps to reproduce: =================== - Connect Unsplash to your database - Add a snippet on your website page like "Feature wall" for example - Double click on an existing image - type at least…
Steps to reproduce: =================== - Connect Unsplash to your database - Add a snippet on your website page like "Feature wall" for example - Double click on an existing image - type at least two words separated by a space like "Sleeping cat" - select any image from the list. - Add a shape to this image -> Traceback Cause: ====== When an image is chosen from Unsplash using a multi-word search, its URL contains encoded characters (e.g., `%20` for a space). The image processing utility was extracting the `pathname` directly from the image's URL. This path, however, remained URL-encoded. This encoded path was then used in a subsequent RPC call to fetch the original image data before applying the shape. https://github.com/odoo/odoo/blob/b9435baa1948f54e19f2dd5702a39d073e8eb57d/addons/html_editor/static/src/utils/image_processing.js#L204 This caused the fetch operation to fail, returning an `undefined` value. The attempt to apply a shape to this `undefined` result is what triggered the traceback. Solution: ========= The `srcUrl.pathname` is now wrapped in `decodeURIComponent()`. This function correctly decodes URL-encoded sequences (like `%20`) back into their original characters before the path is sent to the server. The backend now receives a clean, valid path, resolving the traceback. opw-5241317 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235263
This update fixes an issue in report editing where inserting a new table or element could move the cursor to the wrong place. The editor now keeps the user’s position intact, so they can continue typing or interacting with the inserted content smoothly.
Original PR description
On a new report, add a X2Many table in a new Report. In many cases there will be some issues with the selection as, when inserting the Element via the command of the report Editor we explicitly focus the editable of the html_editor. We need the document inside the iframe to get the focus, because our flow implied to click on some popover bound to the main window. But focusing the editable element changed the selection. So, instead, we focus the iframe's inner window, and the selection stays at the right place, and the user can immediately interact with it (by continuing typing after the insertion) task-5159482 Forward-Port-Of: odoo/enterprise#97642
The sales order product search now works with supplier-specific product names and codes again. This restores a useful lookup option that was accidentally removed, helping users find the right product faster when matching supplier information.
Original PR description
Commit 6e69b1d4a357bf236695a2ed5b09fd62de911872 cleaned up SO views and removed some context fields from the product_id and product_template_id fields which were in fact used in the `_search_display_name` override of the related models. This commit brings back those values to allow finding products by their seller product name or code. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235591
This update fixes how employee version records are duplicated, ensuring all relevant details are copied when creating a new version. It also adjusts a payroll validation rule so it checks uniqueness per employee instead of per version, which better matches how the information is now stored.
Original PR description
## [FIX] hr*: make sure copy of a version copy all version fields This commit makes sure all the information of a version is completely duplicated when the user creates a new version from an existing version of an employee. ## [FIX] l10n_be_hr_payroll_group_s: move group S unicity constraint per employee Before this commit, the group S unicity constraint were per versions since before it was per contract. Now, since we no longer any contract model and more than version could represent the same contract, that constraint is a bit too restrictive. Moreover, the group S is more stored on the employee, so it would surely make more sense to trigger an error if 2 different employees have the same group S code. This commit moves the group S unicity constraint in hr.employee model to make sure we check per employee instead of per version. Forward-Port-Of: odoo/enterprise#95559
This change prevents an error that could happen when users click "Create and Enrich Partner". It ensures the system saves the correct company reference, so partner creation and enrichment complete successfully without interruption.
Original PR description
Currently, an error occurs when the user clicks the `Create and Enrich Partner` button. **Error:** `ProgrammingError: can't adapt type 'res.partner'` This error occurs when the user clicks the…
Currently, an error occurs when the user clicks the `Create and Enrich Partner` button.
**Error:**
`ProgrammingError: can't adapt type 'res.partner'`
This error occurs when the user clicks the `Create and Enrich Partner` button. Then it tries to find or
create the company using IAP. From here [1], it returns the record as company, and here [2], it writes
this record into the partner as the parent_id. However, since the parent_id is a record instead of an ID,
when the system tries to browse the partner by this record [3], the error is raised.
This commit ensures that when writing the parent_id of the partner, the actual ID is used instead
of the record.
[1]- https://github.com/odoo/odoo/blob/591584268cfcbad54ee675ea62d047c3900ed629/addons/mail_plugin/controllers/mail_plugin.py#L386
[2]- https://github.com/odoo/odoo/blob/591584268cfcbad54ee675ea62d047c3900ed629/addons/mail_plugin/controllers/mail_plugin.py#L52-L53
[3]- https://github.com/odoo/odoo/blob/591584268cfcbad54ee675ea62d047c3900ed629/addons/account/models/partner.py#L801
sentry-6831922000
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#235198This update fixes several issues in employee versioning so that new versions preserve all the right information and any edits made during creation are tracked properly. It helps prevent missing data or unintended changes when updating employee records, making version management more reliable for HR teams.
Original PR description
## [FIX] hr: track the fields updated when creating new version Before this commit, when the user alters an employee form view and then create a new version, if a version exists on that employee…
## [FIX] hr: track the fields updated when creating new version Before this commit, when the user alters an employee form view and then create a new version, if a version exists on that employee altered, it will copy the version with the changes made by the user at the same time and so no tracking values on the values changed by the user are created. This commit makes sure the changes made by the user are correctly tracked when a new version is created with some values given in parameter. ## [FIX] hr: add explanation how to change group on version fields in employee model ## [FIX] hr*: make sure copy of a version copy all version fields This commit makes sure all the information of a version is completely duplicated when the user creates a new version from an existing version of an employee. ## [FIX] hr: protect fields copied in create_version to avoid recomputing Before this commit, since now we do a write after the copy of a new version to be able to track the changes made by the user. We cannot guarantee the vals given to the write will trigger a compute method from a field copied. This commit makes sure the version fields copied will never be invalidated and only the fields inside the write (that is, the fields altered by the user) will be altered. Forward-Port-Of: odoo/odoo#222744
Financial reports on mobile devices can be scrolled again after a styling issue was fixed. This restores access to report content that could previously be cut off on smaller screens.
Original PR description
make the financial reports scrollable again, as the overflow-hidden inadvertently removed it. task-5251154
This fix ensures leave records are created under the employee’s own company instead of the company of the person validating the leave. As a result, resetting work entries keeps the correct leave type and avoids turning leave time into regular attendance by mistake.
Original PR description
When validating a leave for an employee from another company, if the employee’s working hours had no company set, the created resource.calendar.leaves used the validator’s company instead of the employee’s. This caused the reset of work entries to replace leave entries by attendance. We now compute the resource calendar leave’s company using calendar_id.company_id or its existing company before falling back to the current validator company. task-5240785 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
Attendance officers can now update attendance records even when related work entries already exist. The system no longer blocks the edit because of payroll permissions, making routine attendance corrections smoother and reducing access issues for non-payroll users.
Original PR description
Steps to reproduce: 1. Log in as an Attendance Officer without payroll rights. 2. Attempt to edit any attendance record. Cause: If work entries already exist for the attendance, Odoo tries to regenerate them an action requiring payroll permissions. Solution: Execute the work entry regeneration wizard with sudo to bypass the payroll access restriction. Task: 5265141
This fix removes an unwanted border that appeared on the background blur toggle in the call video settings. It makes the video call interface look cleaner and more consistent when users click the option.
Original PR description
**Current behavior before PR:** The background blur toggle button in the call video settings dropdown shows an unintended border when clicked. **Desired behavior after PR is merged:** The background blur toggle button in the call video settings dropdown no longer shows border when clicked. Before: <img width="463" height="203" alt="image" src="https://github.com/user-attachments/assets/ffc42a8d-3d07-480d-84ba-5959e7bf723d" /> After: <img width="398" height="205" alt="image" src="https://github.com/user-attachments/assets/01cc4883-b6e0-4e23-b400-45c4373ef77e" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change makes live chat agent assignment depend only on whether an agent is truly available, not on their custom chat status. As a result, agents who are actually online will no longer be incorrectly left out of chat routing.
Original PR description
Since 19.0, users can set their im status (online/away/busy/offline). Because of this, some agents are considered unavailable while they actually are online. The intent is to prevent assignation when an agent is *really* unavailable. Custom IM status shouldn't interfere with assignation. This commit ensures we only consider *real* IM status to determine if an agent is available. 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
When an appointment cannot be saved because there are not enough available seats, the error message now clearly includes the appointment type name. This makes the message easier to understand and helps users quickly identify which appointment is affected.
Original PR description
Currently, when creating a new appointment with a specified number of people but no resources, saving the record triggers a UserError that does not display the appointment type name. Issue: 2 seats are missing to be able to book the appointment.type(1,): Table (30) <img width="1813" height="776" alt="image" src="https://github.com/user-attachments/assets/f87f45de-3552-47bb-b34c-fcc06cea425f" /> Solution: 2 seats are missing to be able to book the Table: Table (30) <img width="1769" height="905" alt="image" src="https://github.com/user-attachments/assets/04188071-be67-4500-b720-039ee7a27c2e" />
Documentation and clarification updates
This change adds Raj Gohel’s individual contributor license agreement to Odoo’s records. It is an administrative update that helps confirm the legal permissions needed for contributions, with no effect on product features or users.
Original PR description
I am signing the Odoo Individual Contributor License Agreement. This PR adds my CLA entry to the list of individual contributors. Signed, Raj Gohel rajgohel2018@gmail.com GitHub: https://github.com/Rajgohel0312
This change updates Vauxoo’s contributor agreement record to include Jonathan Osorio Alcala as an approved contributor. It is an administrative/legal update that helps keep contributor records current and compliant.
Original PR description
Incorporate Jonathan Osorio Alcala (jonathanosalc) as Vauxoo's contributor. I confirm I have signed the CLA and read the PR guidelines at http://www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235181
18 changes
Enhancements to existing features
Users can once again mark individual invoice lines as “No Follow-Up” so they are excluded from reminder emails and reports. This restores a common accounting workflow and avoids sending follow-ups for amounts that should not be chased, while keeping the partner’s follow-up status accurate.
Original PR description
During the rework of the follow-up report, we removed the "No Follow-Up" field from journal items, making it impossible to exclude individual journal items from triggering a follow-up. In this commit…
During the rework of the follow-up report, we removed the "No Follow-Up" field from journal items, making it impossible to exclude individual journal items from triggering a follow-up. In this commit we do the following: - Re-introduce a field for that, since it is a common requirement to be able to exclude individual items from the follow-up reports. The field is stored on the journal item, but can also be toggled from the journal entry. In case of multiple installments on the invoice, toggling the field on one installment will toggle it for all installments. - Adapt the Follow-Up Report and Customer Statement variants of the Partner Ledger to add a toggle for the "No Follow-Up" field on each report line, that toggles the field on the corresponding journal item(s). - Prevent the follow-up status on the partner to change when all of the overdue journal items are marked as "No Follow-Up". - Make sure users can toggle the "No Follow-Up" setting on the invoice level when opening the "Overdue Invoices" view from the partner's "Accounting" tab. - Make sure all receivable/payable lines without a due date (either from a manual miscellaneous entry or a PoS entry) are put under the "Due" section in the Follow-Up Report instead of the "Overdue" section. Since there is no due date, they can't be overdue. - Make sure the PDF and XLSX exports of the Follow-Up Report don't include the "No Follow-Up" lines, and the customer follow up email only includes the amount of the other lines. Backport of https://github.com/odoo/enterprise/commit/74b9d2ef17e4f9a217db8432d886de2eca4baef9 and https://github.com/odoo/odoo/commit/2789a0fbfa358c5c164e44380c2a4a10e5679615 Task: 5138378 Upgrade PR → https://github.com/odoo/upgrade/pull/8864
Resolved issues and error corrections
This fix prevents a website error when shoppers switch between product variants on subscription products. It ensures the pricing data is handled safely even when no pricing is available, avoiding unexpected page tracebacks.
Original PR description
Step to reproduce: - install website_sale_subscription - create a product, add few variants and tick 'Subscriptions' option. - open that product from /shop - toggle between variants Cause: - In case the pricing is not present, 'False' is passed(not an iterable) - `_onChangeCombinationSubscription` expects a iterable, causing traceback Fix: - we pass empty list instead of False opw-5241612
This change removes hidden line breaks from Swiss QR code fields so the required information stays on the correct line. It helps prevent QR codes from being rejected when they are generated from data that contains newlines.
Original PR description
Swiss QR codes have required information for each line of the QR code. Newline characters present in a field's content shift the content to a different line than intended, causing the QR code to be rejected. This commit removes newline characters from the field elements and alters a unit test to check if this issue occurs again. opw-5095997 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233880
This change fixes WebSocket timeout handling so Odoo no longer misses delayed responses or leaves connections hanging when the other side does not reply. It makes closing behavior more reliable and standards-compliant, reducing stuck connections and improving overall stability.
Original PR description
This PR fixes several issues with WebSocket timeouts: - Waiting for more than one response was not handled properly, resulting in missed timeouts. - The closing handshake did not strictly follow the RFC when initiated on the server side (it closed without waiting for the other peer). - Close timeouts were not enforced (the connection was not terminated when the other peer did not respond to the close frame). Forward-Port-Of: odoo/odoo#234881
This change restores the correct default document type when creating debit notes. It prevents the debit note setting from being overwritten by an invoice-related option, so users get the expected default value while still keeping the invoice option available.
Original PR description
Restores code from v16 to define a default document type for debit notes on records with debit_origin_id. Previously, when using the wizard to generate a debit note, the default document type (related to debit notes) was being overwritten by the first document type associated with invoices. Although this behavior will be removed in v17, this fix is necessary to prevent overwriting the default value for now. Note: It's still possible to use the document type for invoices. Therefore, the change only affects the computation of the default value. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181106
This change prevents the calling system from trying to register twice when a user leaves the page. It avoids an error that could interrupt call service cleanup and helps the app shut down more cleanly.
Original PR description
On page unload, two conflicting things happen: - A REGISTER request with expires=0 is sent to invalidate the registration - The WebSocket disconnects, triggering the reconnection mechanism that attempts to reissue a registration These two concurrent and conflicting REGISTER requests result in the following error: > RequestPendingError: REGISTER request already in progress, waiting for final response This commit prevents the reconnection mechanism from occurring in the event of a "natural" disconnection, such as one triggered by a page unload. This way, the two conflicting REGISTER requests aren't sent on page unload. [Task-5261940](https://www.odoo.com/odoo/project/5778/tasks/5261940) Forward-Port-Of: odoo/enterprise#99376
This update fixes a problem where file uploads could fail after users interacted with elements inside embedded UI components. It ensures the system correctly recognizes those interactions, so file selection works as expected in more cases.
Original PR description
Before this commit, using 'setInputFile' after interacting with an element contained in any shadow root would not work ("no input has been interacted with" error).
This commit allows the listeners responsible for detecting clicks/focus on file inputs to handle the shadow root cases properly.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix ensures customers only see optional products that belong to the website they are browsing. It prevents products from appearing in the add-to-cart pop-up when they are not available on that specific website, which avoids confusion and incorrect product choices.
Original PR description
Steps to reproduce: =================== 1- Create another website 2- Sales app > Products > Open any product's form 3- In the Optional Products field, select any other product in your database for this field 4- Open the product form of the optional product you selected 5- Set the Website field to only be one of your websites, rather than All 6- Navigate to the Website app > Select the non set website in the other Steps 7- Open your shop > Select your main product > Click the add to cart button -> See the optional product appear in the pop-up. Cause: ====== _should_show_product function doesn't validate if a product is available on the website from which the request originates when handling multiple websites. Solution: ========= Update the function to take multiple websites into consideration opw-5179894 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change makes the manufacturing add-component tour more reliable by removing a flaky search step that could trigger inconsistent page updates. It also preselects the target product so it appears first, helping the automated process complete consistently without affecting the business workflow.
Original PR description
The search in the "Add Component" dialog caused a re-render race, making the tour ``test_add_component_from_shop_foor_in_multi_step_manufacturing`` fail intermittently. This fix removes the search steps and marks the “Courage” product as favorite so it appears first in the catalog. runbot-227694
Bancontact payments that require extra card verification now stay in a pending state instead of being marked as failed. This fixes cases where customers were incorrectly shown an error during the payment process, improving completion of legitimate payments.
Original PR description
When paying with Bancontact, in case a 3DS validation is required (challenge flow), Wordline will send a webhook (see below) to indicate that an external (asynchronous) validation was requested.…
When paying with Bancontact, in case a 3DS validation is required (challenge flow), Wordline will send a webhook (see below) to indicate that an external (asynchronous) validation was requested.
Example of recevied webhook:
```
{
'apiFullVersion': 'v1.1',
'apiVersion': 'v1',
...
'payment': {
'status': 'AUTHORIZATION_REQUESTED',
'statusOutput': {
'isAuthorized': False,
'isCancellable': False,
'isRefundable': False,
'statusCategory': 'PENDING_CONNECT_OR_3RD_PARTY',
'statusCode': 51
}
},
'type': 'payment.authorization_requested'
}
```
Since efc2788dfccd, when receiving such webhook we set the transaction as error then force the user flow to `redirect`; this was done to handle payment w/ token (`online_token`) where a 3DS challenge is still required.
But for Bancontact - which is non-tokenizable - we will always be in the "redirect" mode, so we must keep the transaction as `pending`.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update prevents quality checks from appearing for items that were not actually picked in the Barcode app, and it also avoids asking for quantity-based checks before a serial or lot number has been assigned. As a result, users only see the checks that apply to the product being processed, reducing confusion and validation blockers.
Original PR description
*: {stock_barcode_,}quality_control #### There are two issues addressed in this PR: 1) In the barcode app, quality checks triggered at validation includes quality checks related to unpicked products.…
*: {stock_barcode_,}quality_control
#### There are two issues addressed in this PR:
1) In the barcode app, quality checks triggered at validation includes quality checks related to unpicked products.
2) Quality check related to product without set lots are triggered.
### Steps to reproduce:
- Create a storable products product A tracked by SN
- Create a control points of type pass/fail on receipts control by
quantity on product A
- Create and confirm a receipt with a move 2 x product A
- Open the receipt in the barcode app
- Scan product A > Scan SN001
- Click on Quality Check
#### > Both QC's are displayed to be processed
### Expected behavior:
Only the QC related to the scanned SN should be processed as it is the only unit that will be moved at validation.
### Cause of the issue:
Only picked move lines are considered to be processed in the barcode app. However, the `check_quality` triggered by clicking on the quality check button only check if the move related to the move line is picked:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L64-L72
### Fix:
Relying the `barcode_trigger` context key will ensure a uniform behavior between the QC's displayed to be processed directly from the QC button and from these displayed at validation since this context key is already used at validation:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/stock_barcode/static/src/models/barcode_model.js#L581-L590
Note we all changed the default return value of the `check_quality` from `False` to `True` here:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L71-L73
because this method is called in the `pre_action_done_hook` during the `button_validate` of the picking:
https://github.com/odoo/odoo/blob/a97d3c772001f4f0b9df66d28c1c8f19358898e0/addons/stock/models/stock_picking.py#L1415-L1421
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L91-L96
and since a result that is not `True` is expected to be an action that should be processed prior to validation, returning `False` would make it impossible to proceed with a validation in case the `check_quality` is called and there is no check to process.
Task: 4716252
opw-5010764This update fixes several issues in the test framework around file and URL handling, including blob URLs, streamed content, and object URL cleanup. It also corrects how certain mail attachment responses are processed, making automated tests more reliable and reducing the risk of test side effects between runs.
Original PR description
See commit messages for details --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change prevents an error that could appear when opening a stock quantity record without a location selected. It makes the inventory screen more reliable for users working with new or incomplete records.
Original PR description
Currently, an error is produced when accessing the stock quant form view without a location set. **Steps to Reproduce:** 1. Install the Inventory module. 2. Create a product with tracking enabled (By Unique Serial Number). 3. Click **"Update Quantity"** (opens list view). 4. Click **New**, click View on the unsaved record (opens form view). 5. Remove the Location field. **Error:** `TypeError - sequence item 0: expected str instance, bool found` **Cause:** In the display name computation at [1], the system attempts to join name parts where one of them can be `False` if the location is not set. **Fix:** Before generating the display name, it now checks whether the record is saved (record.ids). If the record is unsaved (no ID), it sets an empty `display_name` and skips the name-joining logic. [1] - https://github.com/odoo/odoo/blob/16e889bf5885c4d827b8c2c5dce102f98aad689f/addons/stock/models/stock_quant.py#L599 sentry-6717759358
This change fixes an issue where imported French accounting entries could lose their matching markers too early, preventing some lines from being automatically reconciled later. As a result, FEC imports are more reliable and more entries are matched correctly without manual intervention.
Original PR description
When a FEC file imports journal items, it will create them to draft with reconciliations stated by a matching number starting with "I" (also the case for other some types of imports). Once the entries are posted, the system will create odoo reconciliation records for those journal items. The issue lies in this part of the code removing the matching when performing reconciliations for the same matching number https://github.com/odoo/odoo/blob/9d34c7ee85d105a56c3393a3dbb3e5d62d4d634a/addons/account/models/account_partial_reconcile.py#L206 Most of the time it's not a problem for the auto reconcile mechanism of FEC. However since this mechanism reconciles grouped on matching + account, we can end up in a case where a first reconciliation on account A will remove all matching number similar but on account B leading to no automatic reconciliation for them. This commit provides a test to reproduce this issue. opw-5086823
Imported accounting entries were sometimes losing their special matching markers too early, which could prevent some items from being automatically reconciled later. This fix keeps those imported markers handled correctly so reconciliation works reliably across different accounts.
Original PR description
When a FEC file imports journal items, it will create them to draft with reconciliations stated by a matching number starting with "I" (also the case for other some types of imports). Once the…
When a FEC file imports journal items, it will create them to draft with reconciliations stated by a matching number starting with "I" (also the case for other some types of imports). Once the entries are posted, the system will create odoo reconciliation records for those journal items. The issue lies in this part of the code removing the matching when performing reconciliations for the same matching number https://github.com/odoo/odoo/blob/9d34c7ee85d105a56c3393a3dbb3e5d62d4d634a/addons/account/models/account_partial_reconcile.py#L206 Most of the time it's not a problem for the auto reconcile mechanism of FEC. However since this mechanism reconciles grouped on matching + account, we can end up in a case where a first reconciliation on account A will remove all matching number similar but on account B leading to no automatic reconciliation for them. This commit aims to fix that by removing amls imported matching number (starting with "I") from the reconciled amls to consider. opw-5086823
This update makes the Swiss payroll transmission tests independent from accounting-specific settings, so they can run reliably in more environments. It also adjusts payslip validation to work even when no journal is set on the payroll structure, reducing unnecessary test failures and setup dependencies.
Original PR description
Forward-Port-Of: odoo/enterprise#98672
This update corrects the sequence number used when creating vendor batch payments. It ensures vendor batches are named with the proper outgoing sequence instead of accidentally using the incoming one, which helps keep payment references accurate and consistent.
Original PR description
Currently when creating a vendor batch payment, the system may incorrectly use the inbound batch payment sequence to generate the batch name Steps to reproduce: - Create a Vendor payment. - Create a Vendor batch payment, add the payment, validate it. Issue: Name has been set using the incoming batch payment sequence This occurs because `batch_type` is set to readonly when a payment is added to the list. As result, the current batch type is never sent to the backend that will use the default 'inbound'. opw-5128426
Documentation and clarification updates
This change updates the contributor agreement record for Vauxoo to include Jonathan Osorio Alcala. It is an administrative update that ensures the contributor is properly covered for future code contributions.
Original PR description
Incorporate Jonathan Osorio Alcala (jonathanosalc) as Vauxoo's contributor. I confirm I have signed the CLA and read the PR guidelines at http://www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235181
10 changes
Resolved issues and error corrections
The employee org chart button now opens the Hierarchy view on mobile instead of defaulting to the Kanban view. This makes it easier for users to see reporting lines and navigate employee relationships on smaller screens.
Original PR description
Steps to Reproduce: - Open an employee record. - Set managers for the employee. - Open the employee’s form view on mobile. - Click org chart stat button. Before: - On mobile, the org chart button opened the Kanban view by default. After: - On mobile, the org chart button now opens the Hierarchy view by default. task-5245129 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes each Flutterwave payment reference unique by adding a timestamp suffix before sending it to the payment provider. It helps avoid payment creation errors in test and reset environments where the same reference could otherwise be reused.
Original PR description
The `/payments` endpoint of the Flutterwave v3.0.0 API expects unique `tx_ref` parameters (matching Odoo's payment transaction `reference` field) to be passed. This is guaranteed by a UNIQUE() SQL constraint in Odoo, but testing sometimes involves dropping the database, leading to transaction references being repeated at the provider level for a given merchant account. This commit singularizes all transaction references by suffixing them with the current timestamp, ensuring that the `tx_ref` API parameter remains unique across transaction reference sequences.
This change avoids a browser error when the app tries to read platform information that some browsers no longer provide. It makes the web interface more resilient and helps ensure users can keep working without interruptions caused by browser differences.
Original PR description
This commit uses "Feature detection" to avoid some error when the platform key is not available from navigator. > The platform property indicates the platform/OS the browser is running on. > Theoretically this information is useful for detecting the browser and serving code to work around browser-specific bugs or lack of feature support. However, this is unreliable and is not recommended for the reasons given in User-Agent reduction and Browser detection using the user agent. > Feature detection is a much more reliable strategy. https://developer.mozilla.org/en-US/docs/Web/API/Navigator/platform https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Testing/Feature_detection task-4420689 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The import screen now recognizes CSV files regardless of whether the file extension is written as .csv or .CSV. This ensures users see the same formatting options and experience a smoother, more consistent import process.
Original PR description
Before this fix, the import side panel displayed the formatting options only when the uploaded file had a lowercase .csv extension. Files with an uppercase .CSV extension could still be imported but did not show the format selection section, leading to inconsistent behavior. This commit updates the condition to perform a case-insensitive comparison on the file extension. Task-5145031 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When a sales order creates a purchase order, Odoo now makes sure the chosen supplier is actually valid. This prevents purchase orders from being created with an expired or unsuitable vendor when the customer is not one of the product’s suppliers.
Original PR description
**Issue** A PO triggered by a SO could have an invalid vendor selected. **Steps to reproduce** - Install Sale and Purchase apps - Create a product with: - Two routes: MTO and Buy (Inventory tab) -…
**Issue**
A PO triggered by a SO could have an invalid vendor selected.
**Steps to reproduce**
- Install Sale and Purchase apps
- Create a product with:
- Two routes: MTO and Buy (Inventory tab)
- Two sellers in this order (Purchase tab):
1. With an expired `end_date`
2. With a valid `end_date`
- Create a SO for that product with a client that is **not** one of the vendors
→ A PO is created with the first vendor instead of the second (valid) one.
**Cause**
In the method `_run_buy`, to retrieve the vendor for the PO, `_select_seller` is called with the associated partner of the SO:
https://github.com/odoo/odoo/blob/fa8bfc7306c7f85b013d7f5e336dcfe0586990df/addons/purchase_stock/models/stock_rule.py#L62C1-L66C52
That method calls `_get_filtered_sellers` with that associated partner:
https://github.com/odoo/odoo/blob/fa8bfc7306c7f85b013d7f5e336dcfe0586990df/addons/product/models/product_product.py#L699
Which returns an empty recordset because every seller record is filtered out since every one of them has an associated partner different than the one set on the SO:
https://github.com/odoo/odoo/blob/fa8bfc7306c7f85b013d7f5e336dcfe0586990df/addons/product/models/product_product.py#L673C1-L674C25
Then, in `_run_buy`, the fallback is to call `_prepare_sellers` with no param, and to select the first one found:
https://github.com/odoo/odoo/blob/fa8bfc7306c7f85b013d7f5e336dcfe0586990df/addons/purchase_stock/models/stock_rule.py#L70C1-L72C18
And since, `_prepare_sellers` sorts the records according the sequence (among other thing but not the end_date):
https://github.com/odoo/odoo/blob/1478cbcfbf8d1e0184fce6236c5201ba4b59a159/addons/product/models/product_product.py#L653
it will select the first one (here, the one with an expired end_date)
**Solution**
One option would be to not indicate the vendor when calling `_select_seller` in `_run_buy`, but this would prevent specifying a vendor explicitly.
Instead, add a better fallback where we call `_select_seller` again without specifying the vendor, ensuring a valid seller is selected even when the SO partner doesn’t match any vendor.
opw-5145683This fix ensures the “View Quotation” button in purchase emails opens the website tied to the correct company, instead of always using the default site. It helps users and suppliers land on the expected page when multiple company websites are in use.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Host a server with demo data on localhost; 2. create & switch to a second company; 3. have a website linked to the second company; 4. set the website's domain to http://2.localhost:8069; 5. create a purchase order; 6. send order via email; 8. open mail via Settings / Technical / Email / Emails. Issue ----- The "View Quotation" button links to the default URL instead of the second company's website. Cause ----- The button added via `_notify_get_recipients_groups` only adds a relative URL, which then defaults to the database's base url when sent. Solution -------- Use an absolute URL, using the order's `get_base_url` method. opw-5035391
This update prevents an error when viewing a quotation preview after customizing the sales report with Studio. It makes the preview use the same data naming as the edited report, so the document renders correctly instead of failing.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Edit the `sale.report_saleorder` report using `web_studio`. 2. Add the `amount_untaxed` field next to the "Untaxed Amount" subtitle. 3. Create or navigate to…
Versions -------- - 17.0+ Steps ----- 1. Edit the `sale.report_saleorder` report using `web_studio`. 2. Add the `amount_untaxed` field next to the "Untaxed Amount" subtitle. 3. Create or navigate to a quotation and click on the "Preview" action. Issue ----- A traceback occurs during the rendering of the `sale.sale_order_portal_template` template. ``` Error while render the template KeyError: 'doc' Template: sale.document_tax_totals Path: /t/t/tr/td[1]/span Node: <span t-field="doc.amount_untaxed"/> The error occurred while rendering the template sale.document_tax_totals and evaluating the following expression: <span t-field="doc.amount_untaxed"/> ``` Cause ----- In the `sale.report_saleorder_document` template, `doc` is used as the variable name for the current sale order. Consequently, the studio edit uses this variable name to modify the `sale.document_tax_totals` template called within `sale.report_saleorder_document`. However, the `sale.sale_order_portal_template` template, used for the portal preview, also calls `sale.document_tax_totals` but uses `sale_order` as the variable name for the current order. Solution -------- Add an alias `doc` for `sale_order` during the rendering of `sale.document_tax_totals` when called in the portal report preview. opw-5251932
This fix stops the website from showing technical error pages when an unusual product setup creates a rental order without valid dates. Instead of exposing a traceback to customers, the system now handles the problem more gracefully during checkout.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have `website_event_sale` but not `stock` installed; 2. create an event with a ticket; 3. make the ticket's product rentable; 4. change ticket's product type to Goods; 5. publish the event to website; 6. register for the event via website; 7. go to payment. Issue ----- AttributeError: 'bool' object has no attribute 'tzinfo' Cause ----- Having odd configurations like rentable tickets creates rental orders without rental dates, leading to unhandled errors. Solution -------- While rentable event tickets doesn't make enough sense to make it work, we can still improve the error handling to prevent showing tracebacks to the client. opw-5207045
This fix ensures leave accrual balances are calculated correctly when an accrual allocation’s start date is changed. As a result, employees now receive the right number of accrued days according to the configured plan, avoiding undercounted balances.
Original PR description
Version: * 17.0 Steps to Reproduce: 1. Create an accrual plan with: * Accrued gain time: At the start of the accrual period * Carry-over time: Other * Carry-over date: 1 January * Add a milestone where the employee accrues 2 days monthly, with a milestone reached = 0 days. 2. Create a new allocation: * Set allocation Type to accrual allocation * Select the accrual plan created above * Set date_from to the 1st of the previous month Issue: * The expected accrued days are 4, but the system only calculates 2. Fix: * When changing the `date_from` value, set `already_accrued` to False. * This ensures `_process_accrual_plans` runs `_add_days_to_allocation` properly and recalculates the correct accrued days. After: * Accrued days now calculate correctly based on the accrual plan. task-5236714 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change corrects a printing setting in the Windows IoT printer driver that was causing PDF labels to shift on Zebra printers. It helps ensure labels print in the right position again, reducing wasted labels and manual adjustments.
Original PR description
Adding the argument "-dPDFFitPage" in the printer driver for the windows IoT broke the alignment when printing PDF labels on Zebra printers. Issue introduced in #232866 opw-5220275 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr