Daily updates from Odoo
Monday, July 6, 2026
36 changes · saas-19.1
Resolved issues and error corrections
The outstanding payments widget on invoices now lists payments consistently by newest date first, using the payment ID as a tie-breaker. This makes it easier for users to review recent payments and reduces confusion caused by mixed ordering.
Original PR description
Before this commit: The invoice outstanding payments widget was not sorted by date globally, which could lead to confusion for users when viewing the widget. After this commit: This commit adds a sorting mechanism to ensure that the payments are displayed in descending order based on their date and ID. opw-6254080 Forward-Port-Of: odoo/enterprise#121642
Stripe expense authorizations are now matched correctly when merchant category codes fall within configured ranges, reducing incorrect errors during card expense processing. Declined Stripe expenses also avoid duplicate refusal messages, making expense records clearer for users and approvers.
Original PR description
# [FIX] hr_expense_stripe: Fix MCC ranges Context: Since 3e52d875 when receiving an authorization whose MCC fits in a range we would not find it in the search. This is logical yet we return an error before checking properly mcc codes with range included After this commit: This will also check that the authorization MCC exist if we don't directly find the range. We move the "not found" error after that check too The forgotten tests have been added into the overrides opw-6185961 opw-6288399 # [FIX] hr_expense_stripe: Fix double refusal of expenses Context: When an expense is created through a declined stripe authorization, the expense is refused twice, resulting in a duplicated refusal message After this commit: Do not refuse already refused expenses Forward-Port-Of: odoo/enterprise#121474
This fix ensures the recruitment reports app includes the component it needs to display cohort views. It prevents installation failures in certain setup modes, making deployments smoother and reducing setup interruptions.
Original PR description
installing hr_recruitment_reports with the --ski-auto-install flag causes an error. The error happens because it does not explicitly depend on web_cohort while displaying a cohort view. task-6352888 runbot_error-237854 Forward-Port-Of: odoo/enterprise#122432
Fixed how shipment insurance is sent to Envia so insured deliveries can be processed as expected. This helps ensure customers using Envia delivery methods receive the correct insurance documentation, such as insurance PDFs, when validating shipments.
Original PR description
Issue ----- Insurance set on the delivery method is not correctly being communicated to Envia. Steps to reproduce ----- - Create a MX company - Set up Envia - Fedex Nacional Economico (ground) - 10% insurance - Create a MX client - Create a product (with some weight) - Create a SO using the delivery method & confirm - Validate the picking > No insurance pdf is being printed Cause ----- We are passing the insurance value as a `insurance` field on the shipment, which is not what the API expects. We should instead pass it in `additionalServices` as shown in the example of https://docs.envia.com/docs/additional-services#how-to-add-services-to-a-shipment ----- Ticket: opw-5254952 Forward-Port-Of: odoo/enterprise#118966
Sales commission plans now block salesperson start dates that fall outside the plan's effective period. This prevents incorrect commission setup and helps keep plan assignments aligned with approved date ranges.
Original PR description
Version: 18.0 Steps to reproduce: - open sale commission plans and create a new plan with an effective period - go to the salesperson tab and add a salesperson - set the salesperson from date after the plan end date issue: salesperson period start date was accepted even if it was set after the plan end date fix: added validation to raise an error when the salesperson start date falls outside the plan effective period task id: 6241188 Forward-Port-Of: odoo/enterprise#118289
Users who choose to handle notifications inside Odoo will now be alerted in their inbox when a signature request they sent is completed. This helps request owners track completed documents without relying on email notifications.
Original PR description
## Issue When a user sets their notification to "Handle in Odoo" (`inbox`) and a sign requested is completed, they do not receive the expected notification. ## Steps to reproduce 1. Install *Sign*…
## Issue When a user sets their notification to "Handle in Odoo" (`inbox`) and a sign requested is completed, they do not receive the expected notification. ## Steps to reproduce 1. Install *Sign* (`sign`) 2. Sets the current user's notification preference to "Handle in Odoo" (`inbox`) 3. Create a sign request and send it to Marc Demo 4. As Marc Demo, sign the request 5. **The user who sent the sign request did not receive a notification to notify them that the request was signed.** ## Fix This is a partial backport of both https://github.com/odoo/enterprise/commit/463d6a2aae536356e6dee6b902f2e881dbc4fbda (saas-18.2) and a related fix https://github.com/odoo/enterprise/commit/41395dba4fd31222f5fd9fc94a84c977cf9334f9 (19.0). Before the first commit, users would not receive inbox notification when sign requests would be completed. ## Note to reviewer The issue only occurs in 18.0, as it is fixed by https://github.com/odoo/enterprise/commit/463d6a2aae536356e6dee6b902f2e881dbc4fbda in 18.2, but we can backport the fix from https://github.com/odoo/enterprise/commit/41395dba4fd31222f5fd9fc94a84c977cf9334f9 from 18.2 to 18.4 if desired. opw-6251702 Forward-Port-Of: odoo/enterprise#122740 Forward-Port-Of: odoo/enterprise#120740
This update fixes Sign app test failures that could happen when demo data or prior manual activity was present. It makes automated checks focus only on the records created by each test, helping developers validate changes more reliably without affecting business features.
Original PR description
Version: 19.0 `test_sign_request_notification`, `test_gc_removes_orphan_roles_and_dummy_items` ,`test_sign_tour` and `test_sign_tour_without_sign` fail locally when you run them on a db with demo…
Version: 19.0
`test_sign_request_notification`, `test_gc_removes_orphan_roles_and_dummy_items` ,`test_sign_tour` and `test_sign_tour_without_sign` fail locally when you run them on a db with demo data installed, after doing some manual testing/ operations on it.
- `test_sign_request_notification` builds `completion_mail_to_user` by searching `mail.mail` for any email addressed to the admin's address. If admin had received any other email before this test ran, it got counted too, so the assertion on `len(completion_mail_to_user)` became wrong. We now also filter by subject matching `sign_request.reference`, so it only counts the email this test's own sign request actually generated.
- `test_gc_removes_orphan_roles_and_dummy_items` relies on the helper `_get_signer_and_item_gc_context` to count dummy sign items (page < 0). That helper searched `sign.item` with no domain at all, so any dummy item left behind by a different template got added to `non_active_item_ids` and broke the `len(non_active_item_ids) == 4` check. We now scope that search to `template_id = sign_template.id`, so it only counts items belonging to the template created in the test.
- `sign_tour` had a step targeting `.o-autocomplete--dropdown-item:contains('Administrator')` in the signer autocomplete. After installing demo data the admin user is named `Mitchell Admin`, so the tour failed on databases using that name. Both contain 'Admin', so the trigger now matches on that instead.
taskid- 6329037
Forward-Port-Of: odoo/enterprise#121878The Journal Audit PDF report now avoids adding an empty final page when no global tax summary is included. This keeps printed audit reports cleaner and reduces confusion for accounting users.
Original PR description
Steps to reproduce: 1. Set the active company as My Company (san francisco) 2. Navigate to Accounting > Review > Journal Audit 3. Remove all journals from the report except Bank and Misc. 4. Use the PDF action button to print the report. 5. The last page of the report is completely empty. https://drive.google.com/file/d/1otpniJgt1UNCe2hrUBwqIK58dGuXpu8T/view?usp=sharing This commit ensures that the Journal Audit report does not have blank pages when the global tax summary section is not present. It uses some features of QWeb outlined in the following docs article: https://www.odoo.com/documentation/19.0/developer/reference/frontend/qweb.html#loops opw-6224670 Forward-Port-Of: odoo/enterprise#121068
The voice transcript 'share by email' action now posts the transcript summary only to the record the user is viewing. This prevents summaries from being accidentally added to other records of the same type, keeping customer and lead histories accurate.
Original PR description
Issue: Voice transcript 'share by email' button would get post the transcript summary to the chatters of all records of a given model. Steps: 1) install crm and ai 2) activate openai and gemini by…
Issue: Voice transcript 'share by email' button would get post the transcript summary to the chatters of all records of a given model. Steps: 1) install crm and ai 2) activate openai and gemini by saving the api keys inside settings. 3) create 2 crm leads in order a) lead 1 and lead 2 4) go into lead 1 and in the description then type in '/voice-transcription'. 5) Go into the 'transcription' section of the voice transcription 6) type something and save 7) then click 'start recording' 8) click 'stop recording' - it doesn't need to actually record 9) wait to process 10) click the 'share by email' button 11) check lead 2 for a message created (there shouldnt be one) 12) go back to lead 1 and click the 'share by email' button 13) check lead 2 again and a second message appears. that is becuase it makes a new mail.compose.message with res_ids of a list of multiple crm.lead.id (e This was fixed in 19.2+ with the pr https://github.com/odoo/enterprise/pull/115978. But it didnt make it in 19.0 and 19.1 Fix: default_res_ids: model?.config.resIds, -> default_res_ids: [model?.config.resId] take the single record id instead of the list res_ids opw-6285883 Forward-Port-Of: odoo/enterprise#121021
International UPS shipments now use the customer’s main commercial address as the Sold To address when appropriate, preventing incorrect commercial invoices when delivery and billing details differ. If UPS requires the Sold To country to match the delivery country, Odoo falls back to the delivery address and warns the user so the shipment can proceed with clear visibility.
Original PR description
Issue ----- When making an international delivery to a partner with different invoice and delivery addresses, we send the delivery address as the `Sold To` address as well. Problematic case 1 ----- -…
Issue ----- When making an international delivery to a partner with different invoice and delivery addresses, we send the delivery address as the `Sold To` address as well. Problematic case 1 ----- - Create a belgian company - Setup UPS - Create a French customer - Add a different french delivery address - Create a product (with some weight) - Create a SO (with UPS delivery) to the customer & confirm - Validate the transfer > Commercial invoice `Sold To` uses the delivery address Solution for case 1 ----- Use the delivery address' `commercial_partner_id`. This leads to another issue in some edge cases... Problematic case 2 (caused by case 1 fix) ----- - Create a belgian company - Setup UPS - Create a French customer - Add a delivery address in Switzerland - Create a product (with some weight) - Create a SO (with UPS delivery) to the customer & confirm - Validate the transfer > UPS error `The Sold To party's country code must be the same as the Ship To party's country code with the exception of Canada and satellite countries.` Solution for case 2 ----- Default back to delivery address for the `Sold To` field when countries don't match, as this is a limitation of the UPS API. Warn the user, either on the SO or the transfer itself (if no SO). Warning looks like this (on SO): <img width="1914" height="716" alt="image" src="https://github.com/user-attachments/assets/f7aa73c4-f24c-42da-8f3e-6a58765ef020" /> ----- Ticket: opw-6200263 Forward-Port-Of: odoo/enterprise#121340 Forward-Port-Of: odoo/enterprise#118031
This update fixes an issue where replacing website icons removed their styling classes (like rounded or shadow). The fix ensures that icons in the website builder retain their original visual styles, providing a more predictable and consistent user experience. This improves the visual quality of website content.
Original PR description
Issue: Replacing an icon removes style classes applied to the original icon, such as `rounded`, `rounded-circle`, `shadow`, or `img-thumbnail`. This issue was introduced by [commit], which stopped…
Issue: Replacing an icon removes style classes applied to the original icon, such as `rounded`, `rounded-circle`, `shadow`, or `img-thumbnail`. This issue was introduced by [commit], which stopped preserving image-specific classes when replacing an image with an icon. This behavior is appropriate in the backend editor, where icons do not support these styling options. However, the same logic also affected the website builder, where icons support the same styling options as images. As a result, these classes were unnecessarily removed when replacing an icon. Steps to reproduce: 1. Add an icon with style classes such as `rounded`, `rounded-circle`, `shadow`, or `img-thumbnail`. 2. Replace the icon. 3. Notice that the style classes are removed from the new icon. Fix: Preserve these style classes when replacing icons in the website builder, allowing the newly selected icon to retain the existing visual styling. [commit]: https://github.com/odoo/odoo/commit/8638dbc21a7a3ebb3c9cc195d2249b4eb5c264ab task-[6200832](https://www.odoo.com/odoo/project/974/tasks/6200832) Forward-Port-Of: odoo/odoo#265496
This update fixes an unexpected accrual of holiday days that occurred when carryover balances were applied at the beginning of the year. The fix ensures accruals only happen at the standard period boundaries (start/end of month or level transitions), preventing confusion and ensuring accurate holiday balance tracking. This improves the reliability of holiday accrual calculations.
Original PR description
## Issue Currently, an extra accrual happens on carryover date, but it shouldn't. Indeed, accrual only happened at the start - end of a period, or on level transition. ## Reproducing steps Let's take an accrual plan with a level that adds 2 days/month on the 15th of the month. The carryover takes place at the beginning of the year. So we will have this: - 2025-11-01 -> creation of the allowance, 0 days available - 2025-11-15 -> 1 day (only 15 days are counted, so only half of the days are added) - 2025-12-15 -> 3 days (1 full month elapsed) - 2026-01-01 -> 4 days (as the carryover triggers an accrual) -> this event causes confusion as the accrual seems to “come out of nowhere” - 2026-01-15 -> 5 days - 2026-02-15 -> 7 days task-5432188 Forward-Port-Of: odoo/odoo#245201
This update corrects a bug where currency conversion rates were incorrectly calculated through branch companies instead of the root company. Previously, multi-branch setups caused errors, but this fix ensures rates are always determined based on the parent company, improving reconciliation and data accuracy. This resolves a critical issue impacting financial reporting.
Original PR description
**Description of the issue/feature this PR addresses:** When branch companies are involved, currency conversion goes through the branch instead of its root company. Because currency rates in Odoo…
**Description of the issue/feature this PR addresses:** When branch companies are involved, currency conversion goes through the branch instead of its root company. Because currency rates in Odoo only ever live on the root company, resolving a rate through a branch is incorrect. Furthermore, when two sibling branches are active at the same time, it makes the computed company a multi-record set, breaking the reconciliation process with an "Expected singleton" error. This is grounded in how the rest of res.currency already behaves by design: res.currency._get_rates() looks up rates with company_id in (False, company.root_id.id). res.currency.rate._check_company_id() forbids setting a rate on a company that has a parent_id. Therefore, rates are, by design, only ever meant to live on the root company. The only place that still passed the raw company (branch included) into with_company() was res.currency._get_conversion_rate(). **Current behavior before PR:** _get_conversion_rate() forwarded the received company untouched to from_currency.with_company(company). As a result, Odoo looked up the conversion rate through the branch rather than its parent. When more than one branch of the same parent is active at the same time (resulting in a recordset of 2+ branches), company.currency_id inside _compute_current_rate() was no longer a singleton, causing the code to crash with ValueError: Expected singleton: res.company(...) — even though every branch shares the exact same currency and rate defined on their common root company. **Steps to reproduce:** 1) Enable multi-company and branches. 2) Create a parent company P (e.g., using ARS as main currency). 3) Create two branches under P: B1 and B2 (branches inherit P's currency). 4) On the parent company P, define a currency rate for a foreign currency, e.g., USD (Accounting > Configuration > Currencies > USD > Rates). 5) Log in with a user that has P, B1, and B2 all selected as active companies (all three checked in the top-right company switcher). 6) In branch B1, create a customer invoice in USD. 7) In branch B2, register a customer payment in USD. 8) Open the Auto-reconcile tool or try to reconcile the journal items directly. Result: A ValueError: Expected singleton is raised during the reconciliation because the conversion rate is resolved against the multi-company recordset B1 + B2 instead of P. **Desired behavior after PR is merged:** _get_conversion_rate() now resolves the company to its root_id before computing the rate. Branches will correctly fallback to their parent company, and multiple active sibling branches will collapse to a single root company, ensuring that company.currency_id remains a singleton. With the same steps described above, the invoice and the payment now reconcile normally, safely using the single USD rate defined on the parent root company. Non-branch (standalone) companies remain unaffected since a root company's root_id is itself. **video** https://drive.google.com/file/d/14NGTTzP28CgSiYFQdFZ6juHSsib_MDd9/view --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273758
This update corrects a technical issue that prevented proper logging functionality in Odoo's SaaS version, specifically impacting versions 19.0 and later. The fix ensures that necessary data is captured during the forwardport process, maintaining accurate logging records.
Original PR description
During the forwardport, it was missed that get_log_metadata needs an argument starting from 19.0. Forward-Port-Of: odoo/odoo#273694
This update resolves an issue where importing vendor bills from KSeF would fail if custom taxes were used. Now, the system automatically detects and processes KSeF bills with custom taxes, ensuring accurate import functionality. This improves the reliability of importing invoices from the Polish tax authority.
Original PR description
…oder signature When importing a vendor bill from KSeF, the system strictly relied on official Odoo tax XML IDs (e.g., `vz_kraj_23`). If a user had custom taxes (e.g., from a third-party localization), the import would crash with a UserError indicating the tax was not found. Allow manually uploading a FA(3) XML file to vendor bills, and it is detected automatically by the system This commit fixes these issues by: 1. Implementing a smart fallback tax search. If the official XML ID is not found, it dynamically searches for a matching purchase tax based on the KSeF tax code (e.g., '23' -> 23% purchase tax, 'zw' -> 0%). 2. Adding an adapter method that matches the expected EDI decoder signature, processes the file data, and writes the parsed values to the draft invoice. task-6067168 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256818
This update resolves an issue where receipts sometimes printed blank or were cut prematurely. By adding a brief delay and using more precise printer commands, the system now ensures the receipt is fully rendered before paper is advanced, resulting in consistently printed receipts. The update also enhances the printer SDK for stability and future tracking.
Original PR description
Previously, printing a receipt could sometimes result in blank paper being dispensed or the paper being cut prematurely. This occurred because the sequence of line feeds and cut commands was dispatched immediately after sending the image payload, before the printer hardware had sufficient time to process and spool the bitmap. To resolve this, a 200ms delay is introduced after the bitmap is sent. Additionally, the arbitrary `printAndLineFeed` calls are replaced with a precise `printAndFeedPaper` and explicit `partialCut` command. This ensures the hardware has fully rendered the receipt before advancing the paper and engaging the blade. Finally, the internal imin SDK (`lib/imin-printer/imin-printer.js`) is updated to handle websocket connection timeouts gracefully and to expose new hardware APIs for future tracking. owp-6242801 Forward-Port-Of: odoo/odoo#270765
This update resolves a rare issue where the Glory cash machine occasionally sent a complex websocket message, leading to errors in Odoo's processing. The fix ensures the message is correctly formatted, preventing the error and maintaining reliable transaction processing with the Glory machine.
Original PR description
Rarely, the Glory machine can send a websocket message containing 2 root XML elements, which causes the `parseXML` function to fail. This commit fixes the issue wrapping the message in a root element, and then returning the children. opw-6292925 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272040
This update allows invoices in Italy to include both the 0% Digital Tax (DoI) and other applicable taxes on a single line. Previously, the system incorrectly handled DoI taxes, preventing plafond updates and proper deductions. This change ensures accurate VAT calculations and invoice processing for Italian customers.
Original PR description
- Create a declaration of intent in the customer's contact - Issue an invoice that includes both the 0% E (DoI tax) and any other tax - You will see how the plafond is not updated and the amount of this invoice is not deducted from it The method _compute_l10n_it_edi_doi_amount specifically exclude from the doi amount lines with the doi tax and another tax. However it should be possible to use both on a single line. We can use the amount subtotal because the doi is always 0%. opw-6253475 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267669
This update fixes an issue where the number of expenses linked to a sales order was inconsistent, leading to confusion for users. Now, all expenses associated with a sales order are accurately counted, ensuring the smart button displays the correct number of expenses and provides a reliable list when clicked. This improves the user experience and data accuracy.
Original PR description
**Before this commit** Only expenses that generated a sale order line on an SO would be counted in that SO's count of expenses, introducing confusing behavior with the smart button on the SO form view that would take the user to a list of all expenses that have anything to do with the current SO. **After this commit** We return to the behavior that was present in Odoo 18.1 where all expenses that are associated with a SO show up in that SO's "expense_count", making the number in the smart button consistent with the number of expenses that will be fetched when clicking on it. opw-6309575 Forward-Port-Of: odoo/odoo#272287
This update resolves an issue where creating multiple applications with the same applicant information would trigger an error within the Talent Pools feature. The fix restricts the duplication of talent records, ensuring data integrity and preventing application errors. This improves the user experience when managing recruitment applications.
Original PR description
When multiple talent records share the same information, opening the Talent Pools smart button from a matching application will trigger a traceback. Steps to reproduce the error: - Install…
When multiple talent records share the same information, opening the Talent Pools smart button from a matching application will trigger a traceback. Steps to reproduce the error: - Install ``hr_recruitment`` module with demo data - Go to Recruitment > Applications > Talent Pools > Create a new pool - Go to Recruitment > Applications > All Applications > Create a new application with valid email > Click Add to Pool > Select the Talent Pool > Add to Pool - Duplicate the created talent record - Create another application with the same email > save > click Talent Pools Traceback: ```py ValueError: Expected singleton: hr.applicant(2, 1) ``` https://github.com/odoo/odoo/blob/d4e76a5663223a2a2c6e50d1701fabbdcaf32405/addons/hr_recruitment/models/hr_applicant.py#L857-L859 Here, the talent is searched using matching applicant information. When a matching talent has been duplicated, the search returns multiple records. Assigning a multi-records to the many2one field ``pool_applicant_id`` then raises a singleton error. Solution: Restrict the duplication of talent. sentry-7556261128 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273301 Forward-Port-Of: odoo/odoo#270827
This update fixes an issue where invoices weren't accurately reflecting timesheet hours after a partial refund was issued on a sales order. The change ensures that previously invoiced hours are properly deducted when generating new invoices, preventing over-invoicing and maintaining accurate record-keeping of service time. This improves the reliability of our invoicing process.
Original PR description
### Steps to reproduce: - Download 'Sales' and 'Timesheets' apps - Create a service product invoiced on delivered quantities with timesheet tracking - Create and confirm a SO for quantity 1 - Log 20h…
### Steps to reproduce: - Download 'Sales' and 'Timesheets' apps - Create a service product invoiced on delivered quantities with timesheet tracking - Create and confirm a SO for quantity 1 - Log 20h on timesheets - Invoice the SO - Create a credit note for 11 hours => only 9 hours are invoiced - Log 5h more on timesheets - Back to the SO > create invoice again > All the 25hrs are to invoiced, although 9 of them were invoiced before ### Cause of Issue: When generating the new invoice, `_recompute_qty_to_invoice` calls `_get_delivered_quantity_by_analytic` which retrieves the analytic values for the SO line. The values retrieved are later used to determine the delivered quantity, which is later assigned to be `line.qty_to_invoice` without taking into account the already invoiced hours. https://github.com/odoo/odoo/blob/7a6518e39d34575a3977e7c4a0053a45223e203c/addons/sale_timesheet/models/sale_order_line.py#L176-L186 ### Fix: Ensures that hours that have already been completely invoiced are deducted from the quantity to invoice. opw-6253650 Forward-Port-Of: odoo/odoo#273156 Forward-Port-Of: odoo/odoo#268025
This update resolves an issue preventing users from changing a product's bill of materials type (kit to manufacture) when sales orders are already linked across multiple companies. The fix corrects a data integrity check that incorrectly considered company differences, now allowing for more flexible product management in a multi-company environment. This ensures sales orders can be processed correctly regardless of the initial bom type.
Original PR description
### Steps to reproduce: - Have two companies: company1 and company2 - Create a producct P available in both company1 and company2 - with company1, create a kit bom for a product P - with company2,…
### Steps to reproduce: - Have two companies: company1 and company2 - Create a producct P available in both company1 and company2 - with company1, create a kit bom for a product P - with company2, create and confirm a sale order for 1 unit of P - with company1, change the bom type of P from kit to manufature #### > UserError: As long as there are some sale order lines that must be delivered/invoiced and are related to these bills of materials, you can not remove them. ### Cause of the issue: Changing the bom type from a kit (phantom type) to a non kit will launch a call of the `_ensure_bom_is_free` in order to ensure data integrity if the kit bom was used by a relevant sale order line: https://github.com/odoo/odoo/blob/f4c76be062bec47b68ee42505d7d42fed31ac0f2/addons/sale_mrp/models/mrp_bom.py#L15-L18 https://github.com/odoo/odoo/blob/f4c76be062bec47b68ee42505d7d42fed31ac0f2/addons/sale_mrp/models/mrp_bom.py#L24-L42 However, this check does not take the company of the bom into account and in the present flow, the company of the bom is different from the company of the supposedly problematic sol. opw-6290304 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273839 Forward-Port-Of: odoo/odoo#271119
This update fixes an error that occurred when clearing the date field in the WIP Accounting Entry wizard. Previously, the wizard would crash. Now, users can temporarily empty the date field without causing an error, ensuring a smoother workflow for managing manufacturing orders.
Original PR description
Issue Before This PR: When clearing the Date field in the WIP Accounting Entry wizard, an error was raised during the re-computation of dependent fields. This prevented from temporarily emptying the…
Issue Before This PR: When clearing the Date field in the WIP Accounting Entry wizard, an error was raised during the re-computation of dependent fields. This prevented from temporarily emptying the date field while editing the wizard. Steps to Reproduce: - Open the list view of Manufacturing Orders. - Open the Post WIP Accounting Entry wizard by either: - Selecting one or more Manufacturing Orders and choosing Actions ,click Post WIP Accounting Entry - Or, opening a Manufacturing Order form and selecting Post WIP Accounting Entry from the Actions & Reports menu. - Clear the Date field. - Observe that an error is raised. Cause of the Issue: The compute methods _compute_reversal_date() and _compute_line_ids() assumed that wizard.date was always set. When the Date field was cleared, its value became False, but the compute logic still attempted to compare or use the date, resulting in an error. With This PR: The compute methods now verify that wizard.date is set before performing date-dependent computations. This prevents errors when the Date field is temporarily cleared, allowing the wizard to behave correctly during user input. Issue reference: https://github.com/odoo/odoo/issues/246547 Forward-Port-Of: odoo/odoo#273002
This update clarifies the roles and responsibilities associated with the 'User' and 'Administrator' groups within the Project module. The changes improve the clarity of how users manage tasks and projects, ensuring better understanding of their access and capabilities.
Original PR description
This commit improves the grammar of the Project user group description. ### **For User:** **Before -** `User can user the your employees' schedule` **After -** `User: Can manage tasks in projects shared with them.` ### **For Admin:** **Before -** `Administrator can manage the employees' schedule` **After -** `Administrator: Can manage projects and stages, with access to reporting and configuration.` **opw-6340390** Forward-Port-Of: odoo/odoo#273061
This update resolves an issue where the standard price of products wasn't being correctly updated during purchase order creation, leading to false test failures. The fix ensures the standard price is accurately calculated by freezing the time of manual valuation, preventing discrepancies and improving data consistency.
Original PR description
The below test sometimes fail for an incorrect reason and leads to a false positive:…
The below test sometimes fail for an incorrect reason and leads to a false
positive:
https://github.com/odoo/odoo/blob/6dbeac3a42f46b42c638c05aea8285452c944c3f/addons/stock_dropshipping/tests/test_purchase_order.py#L21
Here is another way to reproduce the issue with a higher probability of
false positive (and it is actually easier to read and understand what the
test is doing and what's wrong). It needs to edit the following test:
https://github.com/odoo/odoo/blob/ec58c5e12987401659ea0d75d3be2905ad1d807d/addons/purchase_stock/tests/test_create_picking.py#L953
With the below diff:
```diff
--- a/addons/purchase_stock/tests/test_create_picking.py
+++ b/addons/purchase_stock/tests/test_create_picking.py
@@ -965,6 +965,7 @@ class TestCreatePicking(ProductVariantsCommon):
'price': 500.0,
'discount': 10,
})]
+ self.product_id_1.standard_price = 1.0
po = self.env['purchase.order'].create(self.po_vals) # create a PO for 5 units
po.button_confirm()
with Form(po) as po_form:
```
It will lead to:
```
Traceback (most recent call last):
File ".../test_create_picking.py", line 976, in test_average_cost_updated_after_po_with_discount
self.assertEqual(self.product_id_1.standard_price, 450.0)
AssertionError: 1.0 != 450.0
```
Here are the explanations: when receiving an AVCO product, at some point, we
recompute its standard price. To do so, among several operations, we take
the last manual update, and we ignore all previous SM:
https://github.com/odoo/odoo/blob/2dbd88657395da965125c8f085da93e04c9c8f0a/addons/stock_account/models/product.py#L463-L465
This is an issue when things are done too quickly. See the pattern:
```py
self.product_a.standard_price = 5.0 # -> define valuation_from_date
po.confirm() # with another cost
receipt.button_validate() # -> define move.date
```
In case of a fast execution, both dates will be equal. We therefore ignore
the SM and rely on the manual update to define the standard price, which is
not expected. This explains the above `AssertionError`.
Fixing the codebase is quite tricky since the opposite use case could also
happen, aka first processing a receipt and only then modifiying the standard
price.
Tests side, a more important solution should probably be implemented to ease
their redaction and avoid this basic pattern. Yet, a WIP task is changing
the valo for Odoo 20, so the whole logic may change. Second, the current
issue is impacting a lot of builds, so we need to move forward. For both
reason, the commit only "fixes" the current test.
runbot-939955
Forward-Port-Of: odoo/odoo#273078This update ensures WIoT instances are immediately accessible during upgrades to the latest Odoo versions. The change sets the HTTP interface to '0.0.0.0', preventing a default configuration change that would otherwise block access. This streamlines the upgrade process for WIoT deployments.
Original PR description
WIoT are built in v19, but progressively upgrading to 19.1,2,3,... We need to set the `http_insterface` param to `0.0.0.0` so they are ready when upgrading, as `http_interface` changes to localhost by default in 19.1. Forward-Port-Of: odoo/odoo#271857
This update optimizes how Odoo forms respond to changes. Previously, opening a form triggered onchange methods repeatedly for each field that was updated. This change reduces unnecessary calls, resulting in faster form loading and a smoother user experience. It's a small but important improvement for overall system performance.
Original PR description
When an onchange method depends on several fields that all change at once (for example two fields that both have a default value), opening the form triggers that method once per field, even though a single call would suffice. This adds a per-pass set of already-applied onchange methods so that, within the same batch of changed fields, each method is invoked only once. Note this does not guarantee a method is called exactly once overall: it may still run again in later onchange passes; we only remove the redundant calls within a single pass. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273843 Forward-Port-Of: odoo/odoo#251813
This update fixes an issue where cash rounding records were incorrectly shared across all Indian companies. Previously, a single record was duplicated, leading to errors when opening invoices. The change ensures each new Indian company has its own unique cash rounding record, resolving data inconsistencies and improving invoice processing.
Original PR description
### Issue: When creating a new Indian company, the `Half Up` cash rounding is reassigned to the new company instead of being duplicated Previous Indian companies lose access to it, causing errors…
### Issue: When creating a new Indian company, the `Half Up` cash rounding is reassigned to the new company instead of being duplicated Previous Indian companies lose access to it, causing errors when opening invoices that reference the cash rounding if the user doesn't have access to that company ### Cause: `cash_rounding_in_half_up` was defined as a `data` record with a fixed XML ID (`l10n_in.cash_rounding_in_half_up`) `_get_in_account_cash_rounding` referenced that XML ID directly and set `company_id` to the current company on each chart of accounts installation This reassigned the single shared record to the new company instead of creating a new one Moving the definition to the `@template` decorator without a module-prefixed XML ID lets the chart of accounts system create one record per company, as intended ### Steps to reproduce: - Install `l10n_in` and switch to `IN Company` - Check the Cash Rounding records grouped by company - Create a new Indian company - Enable both `IN Company` and the new company - Check the Cash Rounding records grouped by company again Before the fix, only the last created Indian company has the Cash Rounding record opw-6318857
This update resolves an issue where archived employee order data remained visible in the POS system. The fix ensures that orders processed by an archived employee are no longer displayed when searching for 'Paid' orders. This improves data accuracy and prevents confusion for users.
Original PR description
Steps to reproduce on runbot:
- Enable "Log in with Employees"
- Connect to the POS with an employee
- Process an order
- Go to the backend
- Archive the employee
- Connect to the POS with another employee
- Go to the "Order" tab and search for "Paid" orders
Error:
Odoo Server Error: {archived_employee_id}
[opw-6223243](https://www.odoo.com/odoo/project/49/tasks/6223243)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#273394
Forward-Port-Of: odoo/odoo#266364This update fixes a potential issue where users could still register payments against blocked invoices, even though the payment button was hidden. Now, blocked invoices are correctly displayed as 'Blocked' in lists and payments cannot be registered through standard flows. This ensures accurate financial reporting and prevents incorrect payment processing.
Original PR description
When an invoice is blocked for payment, the form view hides the Pay button, but users could still register a payment from list/payment-item flows. Prevent payment registration for blocked invoices in both the invoice action path and the payment register wizard path. Also make blocked invoices display as Blocked in invoice lists instead of Posted or Sent. task-6310234 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270830
This update fixes an issue where the 'To Pay' section on point-of-sale receipts incorrectly displayed the total due instead of the actual cash payment amount. The change ensures the receipt accurately reflects the price plus tax, aligning with previous behavior and improving clarity for users.
Original PR description
**Steps to reproduce:** - Create a rounding method, only for cash, rounding of 100 - Create a product, costing 100 - Go to the PoS, order and pay for the product with cash - The "To Pay" section is the total due, and not what we actually paid - It is 115 but it should be 100 as this is what we pay for **Why the fix:** The current behavior is to display the total due, not rounded, just everything we have to pay for. Before 19.0, what we paid for was displayed, in this exemple it would display 100 and not 115. This is correct as it seems it is what this section of the receipt is about. We now use **total_amount_currency** which is computed like this https://github.com/odoo/odoo/blob/006a6a1cc6e50bd8b328d0cabb7abbcf610e34bb/addons/account/static/src/helpers/account_tax.js#L1411-L1414 So it is the price + the tax + the rounding, in this exemple it would be **100 + 15 + (-15)** opw-6225613 Forward-Port-Of: odoo/odoo#265298
This update resolves a rare technical problem within Odoo's web interface that could occasionally cause a test to fail. The fix ensures that popovers are properly closed, preventing errors that arise when components are destroyed during the testing process. This improves the stability of the web interface.
Original PR description
Add an extra step to close the popover and prevent the `Component is destroyed` error[1], which can happen during hoots cleanup, similar to the issue we see when some dialogs perform RPCs as they are being destroyed. [1]: https://runbot.odoo.com/runbot/build/115972540 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273826 Forward-Port-Of: odoo/odoo#273085
This update fixes a technical error that prevented users from accessing the 'By Employee' report within the Time Off module when specific employee settings were configured. The issue stemmed from a singleton problem, now resolved to ensure the report functions correctly for all users. This ensures accurate reporting on employee time off requests.
Original PR description
A singleton error appears when opening the "By Employee" report under Time Off. Steps to reproduce: 1)Install the l10n_fr_hr_holidays module. 2)Switch to the French company. 3)Open any employee record. 4)Set Working Hours (resource_calendar_id) to empty. 5)Set Hours Per Week. 6)Create a time off request for any past date. 7)Go to Reporting → By Employee. Task:-6043142 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 update resolves an issue where users with access restricted to a 'branch' company were unable to properly validate purchase orders for components linked to a different 'company1' company. The fix ensures the system correctly handles valuation calculations when components are associated with different company IDs, preventing access errors.
Original PR description
### Steps to reproduce: - Have a company with a branch say "company1" and "branch" - Create two products: Final product (FP), Component (Comp) - Set the company_id of FP to "branch" and of Comp to…
### Steps to reproduce: - Have a company with a branch say "company1" and "branch" - Create two products: Final product (FP), Component (Comp) - Set the company_id of FP to "branch" and of Comp to "company1" - Associate both products with a product category set to avco in company1 (the field is company dependant) - Create a bom for FP with company_id set to "branch": 1 X Comp - Impersonate a user whose only allowed and default is "branch" - Create and confirm an MO for 1 unit of FP - Set the qty_producing to 1 unit and validate #### > Access Error: Access to unauthorized or invalid companies. ### Cause of the issue: Validating the MO will, validate the component move and set its value: https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/stock_move.py#L168-L173 But, in order to determine this value, it is necessary to determine its `property_cost_method`: https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L60-L69 Now, the issue is that the `product_template` of the component belongs to "company1" so that the user is unauthorized to read the valuation method of the product category for "company1". opw-6216141 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272429
This update fixes a testing issue within the account_edi_ubl_cii module by using a real, partial XML file for partner bank account retrieval tests. This ensures more accurate and reliable testing of the system's ability to process UBL invoices, leading to greater confidence in the financial data being imported.
Original PR description
Move the partner retrieval bank account number test to the `test_ubl_import_bis3_invoice_be_retrieve_partner.py` file and use a partial XML instead of a generated XML. Forward-Port-Of: odoo/odoo#273575 Forward-Port-Of: odoo/odoo#269995
This update fixes a minor typo in the Odoo email responsive design code. The correction ensures the email layout renders correctly across different devices, improving the user experience for recipients. This change is a routine maintenance task to maintain consistent email quality.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274343