Daily updates from Odoo
Monday, March 4, 2024
56 changes
12 changes
Resolved issues and error corrections
A recent update incorrectly removed visual styles (hatched and striked) from calendar events in the Year view of the HR module. This caused confusion about event statuses (e.g., 'To Approve'). This change restores the correct visual indicators, ensuring accurate event representation.
Original PR description
During the revamp, in commit 97fea91a570d2bb8a0d454be9cbe7ea4269f6699, the classes `.o_event_hatched` and `.o_event_striked` were removed by mistake. This causes confusion with the status of the events in the Year view of the `hr_holidays` module. According to the legend and the visual style of the events, they look like they are all validated when they are actually "To Approve" or "Refused". | Before| After| |-----|-----| |  | | task-3617333 part of task-3575827 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144208
This update fixes a bug preventing detailed account changes (like invoice account modifications) from being visible in financial reports. This ensures accountants and auditors have accurate tracking of financial transactions, improving reporting reliability and compliance. The fix addresses a technical limitation related to sub-model tracking.
Original PR description
Steps to reproduce: - Create an invoice and confirm it - reset to draft - change the account of an aml (product sales -> asset) -> on the log note you will see the detail of the modification `Account: 400000 Product Sales -> 101000 Current Assets` - connect with Demo - go on the same invoice Issue: You will not see the details of the aml account change This is problematic since Accountant and auditors should be able to see it. Cause: Sub-model tracking is not supported. Although we override this constraint in accounting (refer to https://github.com/odoo/odoo/blob/f56de22f10d09e6e34b25cbff04bbb6bf0823e54/addons/account/models/account_move.py#L5058-L5071), it remains inaccessible for users other than base.system. This is because we attempt to locate the account_id field on the model account.move defined in tracking.mail_message_id. opw-3632295 Forward-Port-Of: odoo/odoo#155034 Forward-Port-Of: odoo/odoo#151096
This update resolves an issue where non-admin users accessing the mobile order menu for a restaurant would encounter an error due to restricted image access. The fix grants access to images for all users with valid access tokens, ensuring a smoother ordering experience for customers.
Original PR description
**Current behavior:** Trying to access the mobile order menu for a pos restaurant with some non-default landing page images as a non-admin user will result in an access error. **Expected behavior:**…
**Current behavior:** Trying to access the mobile order menu for a pos restaurant with some non-default landing page images as a non-admin user will result in an access error. **Expected behavior:** The images should load on this page for anyone who has a valid access token for the page route. **Steps to reproduce:** 1. Make a restaurant in the POS application 2. Enable mobile ordering and set a database user with `user` level access to the POS app to be the default user for this newly created restaurant 3. Upload a splash image for the restaurant 3. On the POS dashboard, select the three vertical dot button on the restaurant -> `Mobile Menu` to get the access error **Cause of the issue:** The default user on the restaurant POS will not necessarily have access rights to the `ir.attachment` model/records. **Fix:** Get the images as sudo()- IMO there isn't a reason these should be inaccessible to anybody considering they are intended to be seen on the landing page by people trying to order. opw-3748314 Forward-Port-Of: odoo/odoo#155589
This update resolves a technical issue preventing users from correctly setting up payment providers for child companies. The fix ensures that payment method lines are created only within bank journals specific to the child company, preventing a common error message related to duplicate payment types and names.
Original PR description
…mpany Steps to reproduce: - Create a branch - Select the two companies in the company selector - Go to payment provider and duplicate the "Demo" one: * set the name as "Demo child" * set the company…
…mpany
Steps to reproduce:
- Create a branch
- Select the two companies in the company selector
- Go to payment provider and duplicate the "Demo" one:
* set the name as "Demo child"
* set the company as the child
* delete the journal
- Go back in payment provider and try to select the created payment
provider
Issue:
UserError: "You can't have two payment method lines of the same payment type (%s) and with the same name (%s) on a single journal."
Cause:
When opening the provider view, it triggers:
- payment.provider._compute_journal_id: if there is no journal_id set on the provider and there is a default bank journal (journals are shared between branches) we'll try to link the payment method to this journal.
https://github.com/odoo/odoo/blob/7d39137df61832e4fe2240fef8e33ad7435359e8/addons/account_payment/models/payment_provider.py#L52-L64
If there is no payment method line (pml), we'll create one with the defaul_payment_method (Demo, the one we duplicated) and with the default journal (Bank from parent company)
- account.payment.method.line._compute_name: it sets the pml.name to 'Demo'
https://github.com/odoo/odoo/blob/7e8185ba20476dd3428ce5e0196207b3bc03eccf/addons/account/models/account_payment_method.py#L134-L138
The constraint in
https://github.com/odoo/odoo/blob/7e8185ba20476dd3428ce5e0196207b3bc03eccf/addons/account/models/account_payment_method.py#L140-L151
is raised since we have to pml with the same name (Demo), the same Journal (Bank from parent) and the same payment type (inbound) with different id's.
Solution:
Find only Bank journals created i n the child company
opw-3692146
Forward-Port-Of: odoo/odoo#154183This update addresses an issue where the duration widget sometimes failed to display correctly due to errors in the Babel formatting library. As a temporary solution, the system now attempts to re-format using the standard English (US) locale before raising an error, providing a more reliable display. This is a best-effort fix due to limitations with our base Ubuntu version.
Original PR description
In case of exception of type KeyError during the formatting with Babel instead to raise a Traceback, we first retry with the en_US locale. Babel fixes each week new bug of formatting like the one in the test, but we cannot bump our default babel version since it is not in the stable Ubuntu 22 so it is a best effort fix that will not hide all bugs but is better that nothing. https://github.com/python-babel/babel/pull/827 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#155909
A recent update to the website's header caused dropdown menus (like the user menu and language selection) to disappear when the page was scrolling. This commit corrects this issue by adjusting how the header's height is managed, ensuring dropdowns appear correctly. A new test has been added to prevent this issue from recurring.
Original PR description
Since the commit [1], a new element called "o_header_hide_on_scroll" was introduced in some header templates. This element has the feature of gradually decreasing its height as you start scrolling…
Since the commit [1], a new element called "o_header_hide_on_scroll" was introduced in some header templates. This element has the feature of gradually decreasing its height as you start scrolling the page until it completely disappears. To reduce the height of this element without leaving its contents fully visible (because they maintain their height), we added an "overflow: hidden" property on it. However, this "overflow: hidden" introduced a bug fixed by this commit. Due to this, the dropdowns within the "o_header_hide_on_scroll" element, like "user menu" dropdown or "language selection" dropdown, became invisible. Steps to reproduce the bug: - Go to Website edit mode. - Click on the header. - Choose the "Menu - Sales 2" template from the options. - Select the "Fixed" Scroll Effect from the options. - Click on the "User Menu" dropdown in the header. - Bug: The dropdown menu does not appear. The same issue occurs if you type something in the search bar; the dropdown with the results does not appear either. To fix this, we don't apply "overflow: hidden" on the "o_header_hide_on_scroll" element when the page hasn't been scrolled yet. And if the page has been scrolled just a bit and the user clicks on a dropdown or the search bar, we scroll the page to the top first, and then display the dropdown menu. This commit also add a test tour to prevent the bug from reappearing. [1]: https://github.com/odoo/odoo/commit/143d475c3ab8d755906807bda8edb655c6dd22eb opw-3698887 Forward-Port-Of: odoo/odoo#154979
This update resolves an issue where the document upload button was hidden in the applicant recruitment view. Now, when the 'Documents for Recruitment' setting is disabled, the upload button will be visible, allowing applicants to properly submit their documents. This ensures a smoother recruitment process.
Original PR description
**Description of the issue/feature this PR addresses:** In the kanban view of all applicants within the recruitment module, an issue arises when applicants attempt to upload documents. --- **Current behavior before PR:** upload button is hidden while uncheck the settings from Documents for Recruitment. --- **Desired behavior after PR is merged:** upload button is visible while uncheck the settings from Documents for Recruitment. --- **Fix:** The PR addresses the problem by modifying tree view of ir.attachment and default_res_model in the context. This adjustment is crucial as the current setting results in an incorrect model name, preventing the display of uploaded documents in this model. task-3579833 Forward-Port-Of: odoo/odoo#155958 Forward-Port-Of: odoo/odoo#150593
This update fixes a bug where kiosk orders with a zero total amount would incorrectly redirect users to the home page without printing a receipt. Now, when an order is zero, the system correctly displays the receipt and confirmation page, providing a smoother user experience for kiosk transactions.
Original PR description
Before this commit: =================== If there is an order with a total amount of 0 in kiosk mode, then after the cart page it is redirected to the home page without printing a receipt. After this commit: ================== with this commit, if an order amount is 0 then it will redirect to the confirmation/receipt page like a normal order with the amount without redirecting to the payment page. task - 3773450 Forward-Port-Of: odoo/odoo#155826
This update fixes an issue where multi-selection product attributes weren't appearing in the product configurator popup when using the Point of Sale (PoS) on mobile devices. Previously, this prevented users from fully customizing products during order creation. This change ensures consistent functionality across all devices, improving the PoS user experience.
Original PR description
Current behavior: When adding a product with a multi selection attribute, the attribute is not displayed in the product configurator popup. This only happens when opening it on a mobile device. Steps to reproduce: - Add a product with a multi selection attribute - Open PoS - Add the product to the order - The attribute is not shown on the product configurator popup opw-3711164 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154893
This update resolves an issue causing excessive error logging on Raspberry Pi 5 devices due to a problem with the display interface. By protecting subprocess calls, the system now handles exceptions more gracefully, ensuring smoother operation once the device is connected to a database.
Original PR description
Currenlty, on raspberry pi 5 our dislay interface is invading the logger with errors due to the absence of both tvservice and the required vcgencmd methods to identify the connected displays The goal…
Currenlty, on raspberry pi 5 our dislay interface is invading the logger with errors due to the absence of both tvservice and the required vcgencmd methods to identify the connected displays The goal of this PR is to avoid this  While searching for a solution to properly detect displays on a raspberry pi 5 we can avoid the excessive log errors by protecting the subprocess calls. When used with vcgencmd, the python wrapper of 'vcgencmd' bash utility is missing the 'Vcgencmd().display_power_state()' method on raspberry pi 5, which causes a subprocess.CalledSubprocessError because the wrapper itself is missing a try/except block arount its subprocess call [here](https://github.com/sushantnadkar/vcgencmd/blob/68578dd887f2e0f62c1e8bf95323574cfc489be0/vcgencmd/vcgencmd.py#L18) Tvservice is not used on new rpi models so there is no need to protect it While the errors will still be present in the logs for a fresh image at the moment, once an rpi5 is connected to a database, it will receive the code from this PR and will handle the exceptions more gracefully [task-3771334](https://www.odoo.com/web#cids=1&menu_id=4720&action=333&active_id=1428&model=project.task&view_type=form&id=3771334) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155882 Forward-Port-Of: odoo/odoo#155615
This update fixes an issue where clicking the 'Parent Task' button in the portal user interface would sometimes fail to load related task information. The team manually added the necessary search view ID to ensure the button consistently opens the correct task details, improving user experience.
Original PR description
How to reproduce the bug :
- Go to one project from portal user
- Open a task
- Create a subtask of this task
- Open the subtask
- Click on "Parent Task" button
=> Traceback
Fix :
- The search view is not loaded when opening the parent task
- We add manually the search view id in the action opening the
parent
taskid:3551354
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#142559This update fixes an issue where email styling sometimes lost information when both CSS and inline styles were applied to the same element. Specifically, it ensures that margin values are correctly converted during email creation, preventing style conflicts and ensuring consistent visual presentation. This improves the quality and reliability of our email communications.
Original PR description
When inlining styles for e-mails, some styles could be lost if they were defined in css but also had an inline style that started with the same characters. For example, a node with a style attribute defining `margin-top: 10px` and a css style defining `margin: 5px` would end up with `margin-top: 10px` and losing the rest of the information. opw-3650141 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156087
3 changes
Resolved issues and error corrections
Spreadsheet template validation now happens automatically when records are changed, rather than relying on a separate post-install check. This helps catch invalid data earlier and keeps spreadsheet-related features more reliable with minimal user-facing impact.
Original PR description
See community PR. The validation is now done with an `api.constrains` instead of a post-install test. Task: 3577092
Belgian payroll now avoids relying on salary-contract data unless that related feature is installed. This prevents errors for companies using payroll without the optional salary contract module, while keeping custom representation fee behavior where it belongs.
Original PR description
Before correction : The function _get_representation_fees_threshold used a field from hr_job. But this field exist only if l10n_be_hr_contract_salary is installed After correction : Put the behaviour of this function linked to this field in l10n_be_hr_contract_salary.
The Documents search panel had a small spacing problem caused by custom folder and delete icons. This fix removes the extra padding so the panel layout appears correctly for users.
Original PR description
Technical ==================== Due to a recent change here https://github.com/odoo/odoo/pull/149246 there is padding issue because in documents we are overriding the carets and trash icons and width of the "o_toggle_fold" is fixed so that's why it is causing the issue. After this PR ================== Removed the unnecessary padding. Task-3761896
41 changes
Resolved issues and error corrections
This update fixes two issues in the payroll system: (1) payslip reports were incorrectly displaying default values for optional fields, which confused employees, and (2) generating declaration PDFs was failing when previous declarations had been deleted. These fixes ensure payslip reports show only actual data and declaration generation works reliably.
Original PR description
Steps to reproduce: - Print the payslip report Current behaviour: - Default value is showing inside the payslip report Expected behaviour: - It shouldn't display default value since it is affecting the actually payslip Explanation: - With the new update, the report now has the default value to display on the report editor. However it also affecting all the non mandatory fields to display on the report. Since it is a non mandatory fields, the fields could be empty and the report display the default value, which is quite confusing for the end user. X-original-commit: a65e162
This fix resolves an issue where purchase orders were not being automatically created in the second company when using inter-company transactions with subcontract services. The system now correctly creates purchase orders as expected when companies are properly configured with subcontract services enabled. This ensures that multi-company workflows operate smoothly without missing purchase orders.
Original PR description
Steps to reproduce: - Create two company San Francisco (SF) and Chicago (CH) - Make a service product, with "Subcontract Services" enabled on both company - For SF set CH as the vendor. - For CH set…
Steps to reproduce: - Create two company San Francisco (SF) and Chicago (CH) - Make a service product, with "Subcontract Services" enabled on both company - For SF set CH as the vendor. - For CH set an external vendor - For both company enable "Inter-Company Transaction" and "Automatic Validation" - Enable subcontract services and set the first company as the vendor - Make a PO on SF and confirm it - An SO is created on CH Issue: A PO should be created on CH but we have nothing. Solution: Remove the function override that would stop this behavior. This code is part of commit (https://github.com/odoo/enterprise/commit/7cb233575e6440cc02cc67f5d5e747c7d22ae183), this function restriction was needed to fix a flow. "Subcontract Services" wasn't company dependent at the time of the commit, meaning that if company CH didn't have a supplier we ran into an issue since we would try to confirm a PO without any vendor. Now that "Subcontract Servives" is company dependent this particular flow is now avoidable by the client (making it a mis-configuration instead of a bug). opw-3622278
This fix resolves an issue where the bank transaction sync would appear to be stuck in a "loading" state on the dashboard. Previously, when errors occurred during transaction creation (such as incorrect journal configuration), the loading status wasn't properly cleared, leaving users confused about whether the sync was still in progress. Now the system correctly resets the status and displays error messages appropriately.
Original PR description
In some cases, when the cron to fetch transaction is running, we first set the status of the connection to "fetching transactions" which is displayed on the dashboard. Once the process is over, status is changed to "done". If an error happen when contacting the provider, status is also reset in order to not display the "fetching status" message forever. However it can happen that an error occured when creating transaction in database (wrong configuration inside the journal, etc) and those errors were not resetting the fetching_status flag. Hence leaving the customer with the impression that it was still loading transactions. This commit fixes the problem by resetting the flag in such cases. So if such an error happen during the cron, it won't fetch transactions and display will be clean. Error will still be raised to the customer if he clicks on manual refresh.
Fixed an issue where the "Sign Report" button on task portal pages was incorrectly positioned and unclickable in Safari browsers. The fix ensures the button displays properly across all browsers by adjusting its alignment in the page layout.
Original PR description
To reproduce: ============= - on Safari (Epiphany for Linux) - on a task for which you can "Sign Report" - click on "Sign Report" -> on portal "Sign" button is badly positioned which make it unclickable Problem: ======== - apparently on Browsers like Safari, we must specify position for the button otherwise it won't be correctly positioned Solution: ========= - add `align-self-star` to make sure the button is correctly positioned at the start of the grid layout opw-3725269 
The standard allowance in the Indian payroll system has been corrected from Rs 1 to Rs 50,000 in accordance with Government of India guidelines. The allowance is now calculated based on the employee's actual working days, ensuring accurate and compliant salary calculations for Indian employees.
Original PR description
Issue: ---------- As of now, the standard allowance is 1 rupee. Fix: --------- As per Government of India guidelines, the standard allowance is Rs 50000, so we calculated the amount based on the employee's working day. task-3672767
This fix prevents errors when viewing subscription reports if a billing period is incorrectly set to zero. The system now validates that billing periods must have a positive value, preventing the calculation errors that were causing reports to fail. Existing databases with incorrect settings will need manual correction of their billing period values.
Original PR description
Steps to reproduce: - - Subscriptions > Configuration > Reccurence periods. - Pick Monthly and set duration to zero. - Subscriptions > Reporting > subscriptions **Traceback Error** Cause of the…
Steps to reproduce: - - Subscriptions > Configuration > Reccurence periods. - Pick Monthly and set duration to zero. - Subscriptions > Reporting > subscriptions **Traceback Error** Cause of the issue: - The SQL queries: https://github.com/odoo/enterprise/blob/f673997a361e97ff2a22d92f9bf34e7277992039/sale_subscription/report/sale_subscription_report.py#L50-L72 divide by zero when the `billing_period_value` field of the `sale.subscription.plan` model is set to 0. Fix: Since the `billing_period_value` field of the `sale.subscription.plan` model should not be allowed to be set at 0 see: commit https://github.com/odoo/enterprise/commit/194ab0f47f7d304448718748429c9f7016121d1b For our fix to be stable, we propose here to implement an ORM constraint that will somewhat achieve the same duty as the sql constraint introduced in 17.1: commit https://github.com/odoo/enterprise/commit/48aef7df451d22d8b2eb941637a13f050d96ea5b but without breaking existing DB's that already uses incorrectly the `billing_period_value` field. Note: This fix ensures that the issue will not be reproducible anymore but does not solve the issue for DB's that already uses incorrectly the `billing_period_value` field. For the subscriptions reports to work correctly on these DB's, the `billing_period_value` will still need to be set manually to acceptable values on each `sale.subscription.plan`. opw-3733854 ---
This fix resolves an issue where the recruitment system would fail when adding detected skills that belong to skill types without a default level assigned. The system now properly handles this scenario, allowing recruiters to successfully process candidate skills without encountering validation errors.
Original PR description
When the detected skill belonged to a skill type for which none of the levels were marked as default, a validation error would occur as the level is a required field of `hr.applicant.skill`. Ticket #3673664
This update fixes a crash that occurred in the Web Studio export test when running tests for individual apps that don't have a currency field. The system now automatically creates the necessary currency field when needed, ensuring tests run smoothly without interruption.
Original PR description
…t in test Before this commit, the test /web_studio.test_export crash in single app testing because the model on which the test is done did not have a currency field. After this commit, there is no crash as we create a new currency field if necessary. runbot-error-57418
This update adds database indexes to the Sales Subscription module to significantly speed up the deletion of sales orders and order lines in large databases. Without these indexes, deleting records could take an extremely long time. This fix ensures faster performance when managing sales orders in enterprise environments with substantial data volumes.
Original PR description
In large database, the time to unlink sale.order or sale.order.line can be huge, because some index are needed. @rco-odoo @arj-odoo Forward-Port-Of: odoo/enterprise#57783 Forward-Port-Of: odoo/enterprise#39414
This update fixes how the system handles errors when syncing bank accounts with Odoo's online banking service. Previously, users would see confusing error messages when trying to delete outdated bank connections or when the bank's records were no longer available. Now the system automatically handles these situations by cleanly removing old connections and creating fresh ones, providing a smoother experience.
Original PR description
- When trying to delete a record and receiving an OdooFinRedirectException(mode=link), allow record deletion. - When trying to link with a bank account and record is too old and has been deleted server side. Don't display traceback saying to reopen in link mode, instead delete record and create a new one.
This update corrects the alignment of total labels in Field Service worksheet PDF reports. Previously, the 'total' labels were not properly aligned to the right side of the report. The fix applies CSS styling to ensure consistent and professional formatting when generating worksheet reports with product line items.
Original PR description
Steps to reproduce: - go to the field service - go to any task add product to it - generate the pdf report 'worksheet report pdf' Issue: - 'totals' labels is not aligned to the right Solution: - aligned the 'labels' to the right us css class Task:3549234 Forward-Port-Of: odoo/enterprise#57899 Forward-Port-Of: odoo/enterprise#50101
This fix resolves an issue where deleted payroll declaration sheets would cause errors when generating PDF documents. Previously, when a declaration sheet was deleted, the associated declarations remained in the system and would cause the PDF generation process to fail. The fix ensures that orphaned declarations are properly cleaned up, allowing users to successfully generate declaration PDFs after recreating declaration sheets.
Original PR description
Steps to reproduce: - Create a payroll declaration sheet - Populate the declaration - Delete the declaration sheet - Create another payroll declaration sheet - Populate the declaration again - Try to generate the declaration pdfs Current behaviour: - Error raised Expected behaviour: - Generate declaration pdfs successfully Explanation: When deleting declaration sheet, declarations will not be deleted. They remained in the database. Therefore when excuting the generate pdfs scheduled action, the system will search the declarations and try to browse the deleted declaration sheet. As a result, error raised. X-original-commit: 7ad17cb
This update corrects an incorrect value used in the payroll testing process for Morocco. The fix ensures that contract creation tests run properly, which helps maintain the reliability of the payroll system for Moroccan operations.
Original PR description
Fix wrong value for crontract creation in test file test_payroll_ma.py. task : 3774041 Forward-Port-Of: odoo/enterprise#57721
This fix resolves an issue where electronic invoices generated for Ecuador were missing currency information in required fields. The currency data is now properly included throughout the EDI document, ensuring compliance with Ecuador's electronic invoicing requirements and preventing document validation errors.
Original PR description
**Current behavior:**
Creating an EDI document from an invoice does not have fields
for currency (moneda) in some places where it is expected.
**Expected behavior:**
Creating an EDI document from an invoice will include these
fields in all their expected places.
**Steps to reproduce:**
0. Install the l10n_ec_edi accounting module; switch current
company to 'EC Company'
1. Duplicate an existing invoice and validate it
2. Process the invoice to receive an XML edi document
3. This form is purportedly missing expected fields
**Cause of the issue:**
The currency information is not set in a manner to be
accessed in all the places it is needed in edi_document.xml.
**Fix:**
Currency information is passed to the requisite scope via
methods in the l10n_ec_edi account.move class.
opw-3669363
Forward-Port-Of: odoo/enterprise#54687This fix resolves an error that occurred when closing a Point of Sale session with branch-specific accounts. Previously, accounts assigned to a branch were not recognized as valid, causing journal entry validation to fail. Now, branch-owned accounts are properly validated alongside their parent company accounts, allowing multi-branch operations to function correctly.
Original PR description
Steps to reproduce: - Install point of sale and accounting - Create a branch - Make a copy of the outstanding receipts account and change company to the branch - Attach the branch to this account in the accounting settings - Open a PoS make a transaction and close the session Issues: An error is displayed notifying the user that the journal entry draft is not valid. Solution: Accounts that are attached to a branch should be valid for them as well as their parents account. Task link: https://www.odoo.com/web#model=project.task&id=3659707 opw-3659707
This fix resolves an issue where purchase orders were not being generated when confirming a sales order with a subcontracted service product in a multi-company setup. The system now correctly uses the company context associated with the sales order when creating purchase orders, ensuring that subcontract service configurations are properly recognized regardless of which company confirms the order.
Original PR description
Steps to reproduce: - Setup two companies and a product - For one of the company activate "Subcontract Service" on the product - Make an SO with the product and in Other Infos set the company with the one that has subcontract service on - Confirm the SO with the company that doesn't have it on Issue: No PO is generated. Solution: Make sure we got the right context when generating purchase. opw-3622278
Fixed a display issue in surveys where resizing a multi-line text box would cause it to overlap with other questions on the same page. The fix applies automatic height adjustment to the text box container, preventing unwanted overlapping while maintaining proper functionality for both survey creation and taking surveys.
Original PR description
**Steps to reproduce:** - Create a survey and enable all questions in 1 page - Add questions. (Minimum 1 Multiple Lines Text Box) - Test the survey - Fill the text area with a certain amount of data…
**Steps to reproduce:** - Create a survey and enable all questions in 1 page - Add questions. (Minimum 1 Multiple Lines Text Box) - Test the survey - Fill the text area with a certain amount of data vertically - Now, hold the icon to resize the text area block - It's overlapping with other questions. **Issue:** Fixed `height:1px` is applied to Parent div. **Technical Reason:** With this commit (https://github.com/odoo/odoo/commit/eaacaf122dff62adcdf885f0ffdcb4a506bded27) the height is applied to the parent div and textarea which is the same for the backend(title of the survey) and frontend. Now backend needs to apply this height to the parent and text area because it has to show all data in the text area but, in the frontend, if we change the height of the textarea then while pressing enter the textarea block increases, and this should not happen. **Solution:** So, applying the `h-auto` class to the parent div of textarea. Now, the questions did not overlap with each other. **Task**-3707415
Fixed an issue where the automatic follower subscription system wasn't using the most up-to-date information when records were manually edited or merged. This caused problems when assigning users to records after a merge, as the system would try to add them as followers even though they were already subscribed. The fix ensures the system checks the latest data before making subscription changes.
Original PR description
`_message_auto_subscribe` relies on `_get_subscription_data` to know who is subscribed to what. This method uses a raw SQL query but doesn't flush the relevant records beforehand. This is not an issue in most normal cases, but if followers are edited manually, for example in order to merge existing models, it may cause issues when then assigning someone to the model will attempt adding them to the list of followers, when they already were on it. task-3713472 original issue in opw-3634410 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155043 Forward-Port-Of: odoo/odoo#152041
Fixed a bug in the website editor where cropping an image that was partially scrolled out of view would apply the crop widget incorrectly, making it impossible to crop properly. The fix automatically scrolls the page to fully display the image before opening the crop tool, ensuring users can always see and edit the entire image correctly.
Original PR description
Steps to reproduce: - Go to a website page (in "edit" mode) > Add a "Text Image" block > Add other blocks before and after the snippet so you can scroll the page content. - Scroll in a way that makes only a part of the image visible. - Select the image and click on the "Crop" button > The crop widget is applied to the image in its current position (partially visible), which makes it impossible to crop it correctly. The goal of this commit is to prevent the issue described above by simply scrolling to a position that allows to correctly edit the image before applying the crop widget and also allowing the widget element to scroll when trying to crop an image that overflows the current viewport. task-3420186 Forward-Port-Of: odoo/odoo#154285 Forward-Port-Of: odoo/odoo#152440
This fix resolves an issue where the Google Calendar and Microsoft Outlook sync buttons were not updating their status after restarting a sync operation. The update improves the user experience by ensuring button states accurately reflect the current sync status in real-time.
Original PR description
This PR aims to fix an issue with google/outlook sync buttons: The button state doesn't update automatically after restarting the sync. Changes: Introduced new states for the reactive values of the model, which control how the button is displayed. Task: 3731623
This fix resolves an error that occurred when users tried to unreconcile or reverse a payment that was reconciled with an invoice after the bank journal's outstanding receipts account had been changed. The system now correctly handles payments linked to old outstanding accounts, allowing users to safely undo reconciliations without encountering validation errors.
Original PR description
When having reconciled a payment with an invoice after having changed the outstanding receipts account on the bank journal, we get an error when unreconciliing the payment and the move. Steps: - Create two new outstanding receipts accounts X and Y - Set X as outstandings receipts account on the Bank journal - Create a manual customer payment P for $100, confirm - On Bank journal, change the outstanding receipts account from X to Y - Create and confirm an invoice for $100 - Reconcile with payment P from the widget - Unreconcile or reset invoice to draft -> Error: "Journal Entry %s is not valid. In order to proceed, the journal items must include one and only one outstanding payments/receipts account." This is a fw port of https://github.com/odoo/odoo/pull/149285 which is not needed in 16, and needed here only where we reset move to draft/unreconcile opw-3659092
Fixed an issue where payment information was missing from Point of Sale invoices. When users created a POS order and generated an invoice, the payment details would not appear in the PDF. This fix ensures payments are properly recorded before the invoice is generated, so customers and staff can see complete payment information on all invoices.
Original PR description
Current behavior: When invoicing a POS order, the payment were not appearing in the invoice. Steps to reproduce: - Create a POS order - Validate and invoice the order - Open the invoice PDF, the payment is not appearing opw-3748596 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects how date and datetime values are formatted in property fields. Previously, invalid date strings were being saved to the database instead of properly formatted dates. This ensures that when users set default date values in property definitions, they are stored correctly in the proper date format.
Original PR description
Bug === Since c5b87e130bd69996c9121227bb6d085035c362fa , the Date / Datetime are not formatted the way they suppose to be. So the value is not correct (it contains the timezone, etc). Because of that, the string "Invalid Date" is stored in database instead of "YYY-mm-dd". Task-3774178
Fixed a bug where the search bar popup appeared in the wrong location when users clicked the search icon on a fixed website header. The search functionality now displays correctly below the header instead of overlapping with it, improving the user experience when searching on scrolled pages.
Original PR description
Steps to reproduce:
- In website edit mode, have a header with a search icon
('default header').
- Add a few building blocks, enough so that you can scroll.
- Save the page.
- Scroll down until the header is back to fixed on top.
- Click on the search icon.
- Bug: the search bar appears in header (instead of below it, like at
the beginning).
This issue occurs because when the header is fixed and has a 'transform:
translate' property applied, the search modal, which is positioned
absolutely, takes the dimensions of the header instead of those of the
body.
To resolve this, we relocated the '#o_search_modal' element from the
'#header' to '#o_shared_blocks'.
task-3646513This update fixes an issue where incomplete URLs in product documents were being treated as local links instead of external ones, resulting in broken pages. For example, "youtube.com" will now be properly converted to "https://www.youtube.com". The system now validates and formats all URLs correctly when users add document links to products.
Original PR description
Added a validation for URLs on product.document to resolve an issue where incomplete links on documents will redirect to a local URL instead of an external URL. Thus leading to a page that does not exist. e.g.: youtube.com instead of https://www.youtube.com This seemed like the proper course of action as there would be no reason to not validate as any URL within the database can still be formatted properly and work the same. Changed from targeting 15.0 ir.attachments to targeting product.document on this version as per @ryv-odoo Old PR: https://github.com/odoo/odoo/pull/155322 api.constrains does not seem to work upon creation on this model, so I opted to use the api.onchange. opw-3698591 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix enables the "open positions" text displayed on job listings to be properly translated into different languages. Previously, the way this text was written in the template prevented the translation system from recognizing and extracting it for translation. Now job seekers visiting your website in different languages will see the open positions count in their own language.
Original PR description
When listing jobs on the website, we show the number of open positions. Currently the "open positions" were crafted in the QWeb template in such a way that the translation mechanism couldn't extract it and thus it could not be translated. In this commit we fix that, so that it can be translated again. opw-3761288 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155930 Forward-Port-Of: odoo/odoo#155876
Fixed a bug where shipping costs were not recalculated when customers changed their delivery address during checkout. Now when a customer edits and confirms a new shipping address, the carrier rate is automatically recalculated and updated to reflect the correct cost for that location. This ensures customers see accurate shipping prices based on their actual delivery address.
Original PR description
Steps to reproduce: 1) Configure a carrier with 3d party api(for ex. fedex) 2) Create 2 shipping addresses(better to choose addresses with different delivery rates) 3) Go to /shop and add product that needs to be delivered 4) Proceed to checkout choosing a shipping address and a carrier 5) See the calculated rate 6) Click on 'edit' near the addresses and change the address 7) Click 'confirm' and observe that a new rate on the badge is not applied to the order After this commit the rate is recalculated and updated when the shipment address is changed. opw-3737266 Forward-Port-Of: odoo/odoo#155170
This fix resolves an issue where invoice tax totals were incorrectly calculated when using global tax rounding. The system was applying rounding adjustments to negative tax lines that didn't need them, causing a 1-cent difference between the sales order and invoice. The fix prevents unnecessary rounding adjustments from being applied to tax lines that are already properly rounded.
Original PR description
Create a sale order having these line values: - Price Unit 54.45, tax 10% not included - Price Unit 600.00, tax 10% not included - Price Unit -500.00, tax 10% not included Tax total will be:…
Create a sale order having these line values: - Price Unit 54.45, tax 10% not included - Price Unit 600.00, tax 10% not included - Price Unit -500.00, tax 10% not included Tax total will be: |name|total| |---|---| |Untaxed Amount |154.45| |Taxes | 15.44| |Total | 169.89| From the Sales Order create the Invoice Issue: Invoice tax totals will be |name|total| |---|---| |Untaxed Amount |154.45| |Taxes | 15.45| |Total | 169.90| This occurs because when managing the rounding errors for global rounding the system 'force' a 1 cent difference on the negative line that do not need rounding Example: Line 1 - current diff: 0.0 - computed tax amount: 5.455 - tax amount + diff: 5.455, after rounding: 5.45 - stored diff for next line: -0.005 Line 2 - current diff: -0.005 - computed tax amount: 60.0 - tax amount + diff: 59.995, after rounding: 60.0 - stored diff for next line: -0.005 Line 3 - current diff: -0.005 - computed tax amount: -50.0 - tax amount + diff: -50.005, after rounding: -50.01 A solution is to not add the diff when the tax line is already rounded opw-3715229 Forward-Port-Of: odoo/odoo#155636 Forward-Port-Of: odoo/odoo#154861
This fix moves the "Kode Transaksi" (Transaction Code) field from the Accounting tab to a more accessible location next to the Tax ID field. This change enables the sales team to access and use this important field in their daily workflow, as they don't have access to the Accounting tab.
Original PR description
Currently the field `Kode Transaksi` can be found inside the accounting tab. This fix will move it under the tax field. `Kode Transaksi` is a field that should be used in the sale flow and is…
Currently the field `Kode Transaksi` can be found inside the accounting tab. This fix will move it under the tax field. `Kode Transaksi` is a field that should be used in the sale flow and is currently unavailabe for sales team. Steps to reproduce: ------------------- * Install **l10n_id** * Create a company with indonesian localization * Switch to that company * Creat a contact * Toggle the checkbox next to `Tax ID` * Under the `Accounting` tab, you can find `Kode transaksi`. Sales team don't have access to the accounting tab, and thus not to `Kode transaksi` either. Why the fix: ------------ Technically what we want here is to have the field for `Kode Transaksi` after the `vat` field from this view https://github.com/odoo/odoo/blob/04593b265b765f7a6ee079f21bad6a1cf0e5d094/odoo/addons/base/views/res_partner_views.xml#L205-L210 Two possible solutions for this fix: * Fetch the path to `group/group` and put the field inside. * Fetch the path to the `vat` field and put the field after. This would also require to change the priority of the view starting from saas-16.3 because the `vat` field is being moved in this view: https://github.com/odoo/odoo/blob/8ccde3f101cdb6ca41fe29cc5b4252f13745774a/addons/base_vat/views/res_partner_views.xml#L14-L18 By changing the priority, it would allow for `Kode transaksi` to be place after the `vat_vies_container`. Else it would be inside, which does not make sense inthis case. opw-3731357 Forward-Port-Of: odoo/odoo#155515
This fix resolves an issue where email styling was incorrectly losing CSS margin properties when both inline styles and CSS styles were present. Previously, if an element had both an inline margin-top style and a CSS margin style, the additional margin information would be lost. This update ensures all margin properties are properly preserved when converting styles for emails.
Original PR description
When inlining styles for e-mails, some styles could be lost if they were defined in css but also had an inline style that started with the same characters. For example, a node with a style attribute defining `margin-top: 10px` and a css style defining `margin: 5px` would end up with `margin-top: 10px` and losing the rest of the information. opw-3650141 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156087
This fix corrects how product totals are calculated in Point of Sale reports when discounts are applied across multiple orders. Previously, rounding errors could occur when the same product with the same discount appeared in different orders, causing the reported total to be off by a few cents. The fix ensures each order line is calculated individually before summing, providing accurate financial reporting.
Original PR description
Before this commit, if a product had a discount applied in two different orders, it could lead to incorrect calculations in the report For instance, if a product priced at 14.45 had a 30% discount…
Before this commit, if a product had a discount applied in two different orders, it could lead to incorrect calculations in the report For instance, if a product priced at 14.45 had a 30% discount applied, the discounted value would be 10.115, which rounds to 10.12. However, if there were two orders with the same discount, the report calculation would count the quantity of a product with the same discount and calculate the product total amount in one place. This would result in a discounted value of 10.115 * 2 = 20.23, while in the two different orders we had two 10.12 which sums to 20.24. With this commit, the calculation method has been changed. Now, the product amount total for each line is calculated first, and then the sum of these amounts is used to calculate the total for all of the orders. This change ensures accurate computation of the product total sum when discounts are applied across multiple orders. opw-3721376 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156044 Forward-Port-Of: odoo/odoo#155899
This fix corrects where the "Landed Cost" option appears in product forms. Previously, it was incorrectly showing up for Event Tickets, Event Booths, and Gift Cards. Now it will only display for Service and Storable products where it's actually needed. This prevents confusion and ensures users only see relevant options for their product type.
Original PR description
Steps to Reproduce : - install sales, stock modules - go to products and create new - select product type as Event Ticket,Event Booth or Gift Card - Landed cost boolean is suppose to be visible for a…
Steps to Reproduce : - install sales, stock modules - go to products and create new - select product type as Event Ticket,Event Booth or Gift Card - Landed cost boolean is suppose to be visible for a service type product under purchase. Issue : - Landed cost boolean is suppose to be visible for a service type product under purchase, But currently it is visible on other type of products specific to other models like event tickets, event booths etc. Cause: - In product Module there are two Selection fields like detailed_type and type. The detailed_type Selection field contain service, consumable, event booths, event tickets, storable product And the type selection field contains service, consumable, storable product - In xml views for that landed cost boolean the invisible attribute contains the condition like type != service, because of this the landed cost boolean is visible for the product type of event tickets, event booths and gift Cards. Solution: - if we use detailed_type instead of type selection field, then the landed cost boolean field will be invisible on other product types. task- 3725202 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#153371
This update fixes an issue where form fields were not correctly tracking their validation state when values changed from valid to invalid to valid again. The fix improves how the system resets field validity, reducing unnecessary change notifications and ensuring forms behave correctly when users modify field values multiple times.
Original PR description
The commit https://github.com/odoo-dev/odoo/commit/7452f855f05251a5458ddb4d654b03be1b179d40 was fixing the problem in a simple way. It however wasn't good enough of a fix as we discovered we were triggering too many onChange after the forward port. So we revert commit https://github.com/odoo-dev/odoo/commit/7452f855f05251a5458ddb4d654b03be1b179d40, and backport https://github.com/odoo-dev/odoo/commit/5ffc6048aab011d8e0fd1f4ae0c0a6f042e79288 from 17.1. It adds a method on the model to reset the validity of a field. It was not what felt the best, but as it is working and we just want to fix the problem in stable, we go for it. Forward-Port-Of: odoo/odoo#155621 Forward-Port-Of: odoo/odoo#154991
A test for the calendar month view was failing intermittently because it assumed the calendar was always in week view when trying to change the display scale. This fix improves how the test selects the scale option, making it work regardless of the current view mode. This ensures the calendar feature works reliably across different user scenarios.
Original PR description
The `test_calendar_month_view_start_hour_displayed` makes sure that start hour is display in calendar month view.
The test was failing because when clicking on scale selector, it used '.dropdown-toggle:contains("Week")' however it might happen that the current scale is not week.
This commit fixes this issue by changing the way we access the scale selector.
fixes runbot-59023This fix resolves a race condition that occurs when two processes try to create the same attachment directory simultaneously, which sometimes caused the system to crash when generating website assets (CSS and JavaScript files) for the first time. The update ensures the directory creation process completes successfully even when multiple processes attempt it at the same time.
Original PR description
Fix race-condition when a directory is created by two processes (python's os.py handles it for all directories, but not for the last one). Happens sometimes when generating assets for the first time…
Fix race-condition when a directory is created by two processes (python's os.py handles it for all directories, but not for the last one). Happens sometimes when generating assets for the first time (CSS, JS); one of the two times might crash.
Traceback :
```FileExistsError: [Errno 17] File exists: '/home/odoo/.local/share/Odoo/filestore/brawl-stars/7d'
File "odoo/http.py", line 2251, in __call__
response = request._serve_db()
File "odoo/http.py", line 1826, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1847, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1824, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1832, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2057, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 740, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 34, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 30, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/website/models/website.py", line 431, in configurator_apply
redirect_url = theme.button_choose_theme()
File "addons/website/models/ir_module_module.py", line 399, in button_choose_theme
self._theme_remove(website)
File "addons/website/models/ir_module_module.py", line 375, in _theme_remove
self.env['theme.utils'].with_context(website_id=website.id)._reset_default_config()
File "addons/website/models/theme_models.py", line 259, in _reset_default_config
self.env['web_editor.assets'].make_scss_customization(
File "addons/website/models/assets.py", line 38, in make_scss_customization
self.make_scss_customization('/website/static/src/scss/options/colors/user_theme_color_palette.scss', {
File "addons/website/models/assets.py", line 143, in make_scss_customization
self.save_asset(url, 'web.assets_frontend', updatedFileContent, 'scss')
File "addons/web_editor/models/assets.py", line 77, in save_asset
self.env["ir.attachment"].create(new_attach)
File "<decorator-gen-292>", line 2, in create
File "odoo/api.py", line 420, in _model_create_multi
return create(self, [arg])
File "addons/website/models/ir_attachment.py", line 23, in create
return super().create(vals_list)
File "<decorator-gen-61>", line 2, in create
File "odoo/api.py", line 421, in _model_create_multi
return create(self, arg)
File "odoo/addons/base/models/ir_attachment.py", line 636, in create
values.update(self._get_datas_related_values(
File "odoo/addons/base/models/ir_attachment.py", line 277, in _get_datas_related_values
values['store_fname'] = self._file_write(data, values['checksum'])
File "odoo/addons/base/models/ir_attachment.py", line 132, in _file_write
fname, full_path = self._get_path(bin_value, checksum)
File "odoo/addons/base/models/ir_attachment.py", line 112, in _get_path
os.makedirs(dirname)
File "os.py", line 225, in makedirs
mkdir(name, mode)
```
sentry-4417110945
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix allows the system to properly handle GET requests when using JSON as the route type. Previously, GET requests with JSON route type were not functioning correctly. This improvement enhances the flexibility of the API by enabling read operations to use JSON formatting, making data retrieval more consistent across different request types.
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
This fix resolves a problem where form fields were displaying database IDs instead of user-friendly labels when setting up conditional visibility rules. When creating forms with fields that depend on other field values (like showing additional fields based on country selection), users will now see the proper country names instead of numeric IDs, making the form configuration experience clearer and more intuitive.
Original PR description
This commit resolves an issue (arose in [1]) where a select field was displaying IDs instead of labels. Steps to reproduce: - Navigate to edit mode - Drop a form block. - Select the form action type "create customer" (CRM app must be installed). - Add a field for "country". - Add another field and set its visibility to depend on the country value. Issue: Users are seeing IDs instead of country labels. [1]: https://github.com/odoo/odoo/commit/a54f11edb1f81c8dade2a4ef6080b666b94e918d task-3460326 Forward-Port-Of: odoo/odoo#155531
Portal users can now successfully view parent tasks from subtasks without encountering errors. The fix ensures the search view loads properly when navigating to a parent task, allowing portal users to seamlessly work with task hierarchies in projects.
Original PR description
How to reproduce the bug :
- Go to one project from portal user
- Open a task
- Create a subtask of this task
- Open the subtask
- Click on "Parent Task" button
=> Traceback
Fix :
- The search view is not loaded when opening the parent task
- We add manually the search view id in the action opening the
parent
taskid:3551354
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#142559This fix ensures that product variants are automatically created, archived, or deleted when product attribute exclusion rules are created, modified, or removed. Previously, variants were not being updated when exclusions were imported, which could result in inconsistent product data. This change improves data accuracy and consistency in product management.
Original PR description
opw-3693065 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156212 Forward-Port-Of: odoo/odoo#155103
Fixed a bug in email template previews where recipient lists were not being parsed correctly, causing some or all followers to be missing from the preview. When users created email templates with dynamic recipient lists and clicked preview, the system was incorrectly splitting the recipient data, resulting in incomplete or wrong recipient information being displayed.
Original PR description
Steps to reproduce:
---
1. Activate dev mode
2. Go to Email Templates
3. Create a new template
4. Applies to Task
5. Email Configuration > To (Partners)
6. {{[p.id for p in object.message_partner_ids]}}
7. Click on Preview
8. Select a record with followers
9. Look at Recipients
10. => No or not all followers/partners are included
Cause of the issue:
---
Caused by https://github.com/odoo/odoo/commit/cf7ae6b9d562622709e2730c1ea8c43816c169bf
In the case of partner_to being '[2,3,4]'
Split would output '[2', '3', '4]'
So after the isdigit it would be '3'
It should have been 2, 3, 4
opw-3677069
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#149563This fix resolves an issue in the Point of Sale system where combo product choices were not properly updated when product variants were created. Previously, when a product in a combo choice was archived due to variant creation, the system failed to replace it with the newly created variants. This update ensures that combo choices automatically reference all new variants, maintaining the integrity of combo offerings.
Original PR description
-When product in combo choices are being archived because of variants creation, replace the archived reference with all newly created variants. -Add test to reproduce this use case task id: 3713861 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