Thursday, October 24, 2024
29 changes · saas-17.4
Resolved issues and error corrections
Guest checkout will no longer link newly created delivery contacts to the generic Public User account as their company. This keeps customer contact records cleaner and avoids confusion for staff reviewing orders created through express checkout.
Original PR description
Versions -------- - saas-17.4 Fixed in 18.0+ via #174073 Steps ----- 1. Enable Demo payment w/ express checkout; 2. as anonymous user, add a deliverable product to cart; 3. go to checkout; 4. finalize order using the "Pay with Demo" button; 6. on the back-end, check the newly created contact for the order. Issue ----- Newly created contact has "Public User" listed as company. Cause ----- The `_complete_address_values` method introced by 453cfab758505 avoids adding "Public User" as `parent_id` value for addresses of type 'billing' but overlooked taking the same precaution for the 'shipping' address type. This was inadvertently fixed in 087c48c4ed2ef, which modified the method to add Click & Collect. Solution -------- Avoid adding the archived "Public User" as `parent_id`, regardless of address type. opw-4235452
Missing sample data was added so Point of Sale automated tests run successfully when the Peruvian POS localization is installed. This helps keep release validation reliable and reduces false test failures during quality checks.
Original PR description
How to reproduce: 1. install l10n_pe_edi_pos 2. run `test_pos_js` The following traceback is obtained: ``` Error received after termination: QUnit test failed: point_of_sale > Chrome > test unsynch data error filtering : message: "Promise rejected during "test unsynch data error filtering": Cannot read properties of undefined (reading 'code')" ``` Adding demo data fixes the error. runbot-73446
The Discuss app now keeps unread message counts aligned between the sidebar and the unread message banner. This prevents users from seeing conflicting counts when messages are marked unread or received across active sessions.
Original PR description
Discuss displays an unread counter for the user to keep track of unread messages. This counter is notably shown in the sidebar and in the unread messages banner. However, these counters sometimes have different values, which is inconsistent. Steps to reproduce: - Open two browsers (admin/demo). - Send enough messages from demo to admin to get a scrollbar. - Scroll to the top with admin, mark the first message as unread. - Focus the composer: only the banner remains. - Send another message from demo. - The sidebar displays 1 unread message while the banner still shows the same value. To better indicate unread messages, the banner/indicator remains until the user returns to the thread. As a result, server and local values can sometimes become desynced. This PR ensures both counters account for this desync, adding the local counter to the server one when necessary.
The Activities kanban view no longer shows a New button that could not create anything. This removes a confusing, non-working action and makes the interface clearer for users managing activities.
Original PR description
Current behaviour: --- When being on the kanban view of "my activities", the new button is visible but doesn't do anything. Expected behaviour: --- The button shouldn't be visible, because you shouldn't be able to create activities in the kanban view. Steps to reproduce: --- 1. Install contacts 2. Go to contacts 3. Click on the clock in the upper right 4. Click on "View all activities" 5. Switch to kanban view 6. Click on "New" 7. Nothing happens Fix: --- Disabled the "new" button opw-4210619 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The restaurant point-of-sale flow no longer repeats an order setup step that is already handled by the main point-of-sale system. This keeps the process cleaner and helps avoid unnecessary duplicate work without changing how users operate the restaurant POS.
Original PR description
Description of the issue/feature this PR addresses: - Rremove redundant call to `addPendingOrder`. Current behavior before PR: - Currently, `addPendingOrder` is invoked once by the `point_of_sale` module, and immediately again by `pos_restaurant` [when](https://github.com/odoo/odoo/blob/875ea840b913fd31ef73df9e10e4426df6195bfc/addons/pos_restaurant/static/src/overrides/components/product_screen/product_screen.js#L16-L18) the ProductScreen component mounts. Desired behavior after PR is merged: - Following the fix for #182495, the 'addPendingOrder' call in pos_restaurant becomes redundant and is no longer necessary. - As now we call the same function in root component. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue in the Sign app where clicking a date field during signing inserted “undefined” instead of today’s date. This ensures signers see the correct date automatically, reducing confusion and avoiding manual corrections.
Original PR description
Steps to reproduce: - Sign app > Upload a PDF & Sign - Add a Date field > Sign Now > Sign Now - Click the date field The value 'undefined' fills the field instead of today's date. This was caused by an oversight when resolving a conflict in https://github.com/odoo/enterprise/pull/71864, the query selector should have grabbed the date from the HTML document but didn't. opw-4278391
Deleting a measure used to sort a pivot table could make the spreadsheet side panel crash. This fix clears the affected sort setting when that measure is removed or changed, keeping pivot editing stable for users.
Original PR description
When deleting the measure on which the pivot is sorted, the side panel would crash. This commit fixes this issue by removing the sortedColumn from the pivot when the measure is deleted. Task: [4154831](https://www.odoo.com/web#id=4154831&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
Miscellaneous changes
We faced multiple times error because this update doing a try_loading is called in `post-` scripts (after the module is loaded) and not in `end-` scripts (when all modules are loaded). All l10n_* modules were changed in this PR: https://github.com/odoo/odoo/pull/183359 task-3794536 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185027
Original PR description
We faced multiple times error because this update doing a try_loading is called in `post-` scripts (after the module is loaded) and not in `end-` scripts (when all modules are loaded). All l10n_* modules were changed in this PR: https://github.com/odoo/odoo/pull/183359 task-3794536 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185027
A traceback occurs from version 18.0 when the user creates a new link tracker. To reproduce this issue in 18.0: 1) Install website, link tracker and enable debug mode 2) Tries to create a new link tracker record from the link tracker Error:- ``` TypeError: Cannot mix str and bytes arguments (got (False, 'False')) ``` The onchange sets computes to False by default when they're requested, and apparently does not recompute them if they don't depend on anything. Because of that
Original PR description
A traceback occurs from version 18.0 when the user creates a new link tracker. To reproduce this issue in 18.0: 1) Install website, link tracker and enable debug mode 2) Tries to create a new link tracker record from the link tracker Error:- ``` TypeError: Cannot mix str and bytes arguments (got (False, 'False')) ``` The onchange sets computes to False by default when they're requested, and apparently does not recompute them if they don't depend on anything. Because of that the `short_url_host` value will be False and this leads to a traceback when the compute method of `short_url` triggers. Ref of the breaking commit:- https://github.com/odoo/odoo/pull/170548/commits/20d2f122568feead98df18706ca0a4691c8393c5 sentry-5969318187 Forward-Port-Of: odoo/odoo#182898
The password reset email was not being translated according to the receiver's language. This caused the template to render in the website language, leading to confusion for receivers with different language. The problem came form Convert the "Reset Password" template into QWeb view in https://github.com/odoo/odoo/pull/125874, Before, to sent the email `mail.send_mail()` function was used, and it has a check for the receiver language. and after https://github.com/odoo/odoo/pull/125874 th
Original PR description
The password reset email was not being translated according to the receiver's language. This caused the template to render in the website language, leading to confusion for receivers with different…
The password reset email was not being translated according to the receiver's language. This caused the template to render in the website language, leading to confusion for receivers with different language. The problem came form Convert the "Reset Password" template into QWeb view in https://github.com/odoo/odoo/pull/125874, Before, to sent the email `mail.send_mail()` function was used, and it has a check for the receiver language. and after https://github.com/odoo/odoo/pull/125874 the function wasnt used any more. it replaces with `mail.send()` that send the rendered content directly. To resolve this issue, the language of the receiver user is explicitly set in the context before rendering the email template. This ensures the email content is translated based on the user's preferred language then calling the function that send it. Now the template is rendered using the receiver's language (`user.lang`), or falls back to the website language `self.env.lang` if the receiver's language is not set. Or falls back to 'en_US' if the language is not set. owp-4149894 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182635
Problem: When creating a purchase order (PO) for a company with branches, products from all branches are shown in the product list, even if only the main company is selected. However, users are not allowed to create POs for products belonging to other branches, leading to confusion. Steps to reproduce: - Create a company with branches. - Configure some products for the main company and others for the branches. - In the company selector, choose the main company, keeping branches selected.
Original PR description
Problem: When creating a purchase order (PO) for a company with branches, products from all branches are shown in the product list, even if only the main company is selected. However, users are not allowed to create POs for products belonging to other branches, leading to confusion. Steps to reproduce: - Create a company with branches. - Configure some products for the main company and others for the branches. - In the company selector, choose the main company, keeping branches selected. - While creating a PO, products from the branches appear in the product list. opw-4116680 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184757 Forward-Port-Of: odoo/odoo#180623
Some payment request are failing when sent to viva wallet. Steps to reproduce: ------------------- * Configure viva wallet payment for shop session * Configure one product to have a price unit of 5.1 and na taxes * Open shop session * Add that product to order (only once) * Select **Payment** * Select viva wallet payment method that you configured * Select **Send** > Observation: Error. There are some issues betwees us and Viva Wallet, try again later. [{'type': 'int_from_float', 'lo
Original PR description
Some payment request are failing when sent to viva wallet.
Steps to reproduce:
-------------------
* Configure viva wallet payment for shop session
* Configure one product to have a price unit of 5.1 and na taxes
* Open shop session
* Add that product to order (only once)
* Select **Payment**
* Select viva wallet payment method that you configured
* Select **Send**
> Observation: Error. There are some issues betwees us and Viva Wallet, try again later. [{'type': 'int_from_float', 'loc': ['body', 'amount'], 'msg': 'Input should be a valid integer, got a number with fractional part', 'input': 510.00000000000006, 'url': '...'}]
Why the fix:
------------
Just a floating point precision issue. `3.1 * 100 = 310` but `5.1 * 100 = 510.00000000000006`, explaining why the issue does not always happen.
opw-4076168
Forward-Port-Of: odoo/odoo#184496
Forward-Port-Of: odoo/odoo#184048e-Resguardo document type must not have internal type **Current behavior before PR**: e-Resguardo document type has "invoice" internal type  **Desired behavior after PR is merged**: e-Resguardo document type do not have internal type **Task Adhoc side**: 43467 **Task Latam side**: 1280 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port
Original PR description
e-Resguardo document type must not have internal type **Current behavior before PR**: e-Resguardo document type has "invoice" internal type  **Desired behavior after PR is merged**: e-Resguardo document type do not have internal type **Task Adhoc side**: 43467 **Task Latam side**: 1280 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184810
When upgrading a module where a model has been removed entirely, the ORM does a clean up for 'ir.model.fields.selection' records. However, in this case it doesn't work, because the records reference a model that no longer belongs to the registry (if there are no migration scripts). This commit simply makes the cleanup ignore such a case. It makes sense, because the whole table will be deleted anyway (if there are no migration scripts). STEPS - install a module that defines a model with
Original PR description
When upgrading a module where a model has been removed entirely, the ORM does a clean up for 'ir.model.fields.selection' records. However, in this case it doesn't work, because the records reference a model that no longer belongs to the registry (if there are no migration scripts). This commit simply makes the cleanup ignore such a case. It makes sense, because the whole table will be deleted anyway (if there are no migration scripts). STEPS - install a module that defines a model with a selection field - rename or remove the model - upgrade the module This commit fixes #179392. It was inspired by #104624. opw-3024537 Forward-Port-Of: odoo/odoo#184764
A known issue in Brave (https://github.com/brave/brave-browser/issues/2362#issuecomment-571775236) prevents push notifications unless "Use Google Services for Push Messaging" is enabled in settings. Before this commit, attempting to enable desktop notifications in Brave resulted in a traceback. This commit handles the failure by displaying a more helpful message, suggesting enabling Google Services when using Brave, or showing a generic error for other browsers. task-4191214 Forward-
Original PR description
A known issue in Brave (https://github.com/brave/brave-browser/issues/2362#issuecomment-571775236) prevents push notifications unless "Use Google Services for Push Messaging" is enabled in settings. Before this commit, attempting to enable desktop notifications in Brave resulted in a traceback. This commit handles the failure by displaying a more helpful message, suggesting enabling Google Services when using Brave, or showing a generic error for other browsers. task-4191214 Forward-Port-Of: odoo/odoo#184394 Forward-Port-Of: odoo/odoo#183968
This commit fixes an issue where the dynamic placeholder popover would not fully close upon pressing escape or clicking on the cross when a relation field was selected. This is because its previous condition for changing state instead of closing was if it had some field path selected upon closing the model field selector popover. This would not handle well the case where a relation is selected before closing. The fix is therefore to specify inside calls to the close function of the model field s
Original PR description
This commit fixes an issue where the dynamic placeholder popover would not fully close upon pressing escape or clicking on the cross when a relation field was selected. This is because its previous condition for changing state instead of closing was if it had some field path selected upon closing the model field selector popover. This would not handle well the case where a relation is selected before closing. The fix is therefore to specify inside calls to the close function of the model field selector popover whether it closed because a final value was selected or not. task-4066184 Forward-Port-Of: odoo/odoo#184907 Forward-Port-Of: odoo/odoo#184838
This commit allows uninvited admins to edit non-private events (public, confidential). It was a needed change since administrators might have to change the event information of these types of events day to day. A re-work of the compute methods will be made on master followed by the addition of the proper ACL rules for handling calendar events. task-4182649 Forward-Port-Of: odoo/odoo#180051
Original PR description
This commit allows uninvited admins to edit non-private events (public, confidential). It was a needed change since administrators might have to change the event information of these types of events day to day. A re-work of the compute methods will be made on master followed by the addition of the proper ACL rules for handling calendar events. task-4182649 Forward-Port-Of: odoo/odoo#180051
**Current behavior:** Opening a purchase order, clicking on the forecast report for a product in an orderline, then navigating to a "Used By" link, then clicking the back button in browser will reusult in a traceback when MRP is installed. **Expected behavior:** No traceback. **Steps to reproduce:** *install mrp,purchase* *enable reception report in settings* 1. Open a purchase order with a product that is used in another order 2. Click on the forecast report on the order lin
Original PR description
**Current behavior:** Opening a purchase order, clicking on the forecast report for a product in an orderline, then navigating to a "Used By" link, then clicking the back button in browser will…
**Current behavior:** Opening a purchase order, clicking on the forecast report for a product in an orderline, then navigating to a "Used By" link, then clicking the back button in browser will reusult in a traceback when MRP is installed. **Expected behavior:** No traceback. **Steps to reproduce:** *install mrp,purchase* *enable reception report in settings* 1. Open a purchase order with a product that is used in another order 2. Click on the forecast report on the order line 3. Click on a linked record in the "Used by" column in the report table 4. Click the browser back button -> traceback **Cause of the issue:** When trying to rebuild context, we get the actual model name provided by this.props.action.res_model. This was invariably treated as a stringified number in a read call to `ir.model` to try to get the model name -> result of the read is nonsense and when it is later used in an RPC, it tries to read fields from a nonexistent model. **Fix:** Get rid of the String -> Number conversion, directly use the value in `res_model` as the new `this.resModel`. opw-4181590 Forward-Port-Of: odoo/odoo#183742
This commit adds a constraint on the availability_condition, checking that if the availability_condition is set to country, the field country_id is set. task-4160643 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184686 Forward-Port-Of: odoo/odoo#182509
Original PR description
This commit adds a constraint on the availability_condition, checking that if the availability_condition is set to country, the field country_id is set. task-4160643 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184686 Forward-Port-Of: odoo/odoo#182509
Use Case : Argentinian Company (pesos) Invoice in USD Payment received in USD, with withholding tax on it The current logic will convert the withholding values from USD (payment currency) to USD (invoice currency) instead of converting to ARS (company currency) and set this value as balance. This is of course incorrect. opw-4150317 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183726
Original PR description
Use Case : Argentinian Company (pesos) Invoice in USD Payment received in USD, with withholding tax on it The current logic will convert the withholding values from USD (payment currency) to USD (invoice currency) instead of converting to ARS (company currency) and set this value as balance. This is of course incorrect. opw-4150317 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183726
__Current behavior before commit:__ The `info` variable contains the entry `isAvailable` used [here][1]. This should be updated as soon as a livechat operator enters or leaves the channel. However since this view is cached (by [this line][2]) it happens that the livechat bubble appears without any operators available and vice versa. __Description of the fix:__ Add a t-nocache to prevent `info` from being cached and always be up-to-date. __Steps to reproduce the issue:__ On runbot this b
Original PR description
__Current behavior before commit:__ The `info` variable contains the entry `isAvailable` used [here][1]. This should be updated as soon as a livechat operator enters or leaves the channel. However…
__Current behavior before commit:__ The `info` variable contains the entry `isAvailable` used [here][1]. This should be updated as soon as a livechat operator enters or leaves the channel. However since this view is cached (by [this line][2]) it happens that the livechat bubble appears without any operators available and vice versa. __Description of the fix:__ Add a t-nocache to prevent `info` from being cached and always be up-to-date. __Steps to reproduce the issue:__ On runbot this behavior is inconsistent since each worker has its own cache. It is however consistent in local with only one worker. Make sure you are **not** in debug mode 1. Set a livechat channel on the website, make sure there is no chatbot on it 2. Enter the livechat channel with the admin 3. Open the website on an incognito window (the chat bubble should be there) 4. Leave the livechat channel with the admin 4. Refresh the incognito window The chat bubble is still there. Note that the chat bubble might not appear at all even when the admin enter the livechat if the opposite has been cached before. opw-4233744 [1]: https://github.com/odoo/odoo/blob/837a6a8/addons/im_livechat/views/im_livechat_channel_templates.xml#L100 [2]: https://github.com/odoo/odoo/blob/2997afa/addons/website/views/website_templates.xml#L86 Forward-Port-Of: odoo/odoo#184644
**Steps to reproduce:** - Install l10n_sa_edi_pos - Switch to a Saudi Arabian company (e.g. SA Company) - Create a user with admin rights for Invoicing, but no right for POS and Inventory - Connect with that user - Create an invoice for an Individual contact - Click on "Send & Print" **Issue:** A traceback is raised because the system tries to access some POS orders to get the payment means code, but the user hasn't the rights for that. opw-4192948 --- I confirm I have sig
Original PR description
**Steps to reproduce:** - Install l10n_sa_edi_pos - Switch to a Saudi Arabian company (e.g. SA Company) - Create a user with admin rights for Invoicing, but no right for POS and Inventory - Connect with that user - Create an invoice for an Individual contact - Click on "Send & Print" **Issue:** A traceback is raised because the system tries to access some POS orders to get the payment means code, but the user hasn't the rights for that. opw-4192948 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184785 Forward-Port-Of: odoo/odoo#184342
Prior to this PR, the layout of the Twitter section in the email template was distorted (see reference image: https://tinyurl.com/29meoh6o). With this PR, the layout issue will be fixed to ensure it displays correctly. Task-4210376 Forward-Port-Of: odoo/odoo#184045
Original PR description
Prior to this PR, the layout of the Twitter section in the email template was distorted (see reference image: https://tinyurl.com/29meoh6o). With this PR, the layout issue will be fixed to ensure it displays correctly. Task-4210376 Forward-Port-Of: odoo/odoo#184045
Before this commit we are not able to move expense to a reconciled account in a future period because posting future entries are delayed so we can't reconciled journal items on the fly. * create new company 'test' * switch on it * install French accounting (l10n_fr) * check 'Show Full Accounting Features' to gives access to accounting feature on your user access tab * create vendor bill and post it * go to the 'Journal Items' tab and click on cut-off button and set following fields in
Original PR description
Before this commit we are not able to move expense to a reconciled account in a future period because posting future entries are delayed so we can't reconciled journal items on the fly. * create new company 'test' * switch on it * install French accounting (l10n_fr) * check 'Show Full Accounting Features' to gives access to accounting feature on your user access tab * create vendor bill and post it * go to the 'Journal Items' tab and click on cut-off button and set following fields in the wizard: * *Recognition Date*: next month * *Accrued Account*: '486000 Charges constatées d'avance' * Adjusting Amount: as you want 50% for example * *Journal* : Miscellaneous Operations * click on create journal entries button Journal entries should be created. Fixes #94390 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184793 Forward-Port-Of: odoo/odoo#94395
Problem: When a user is on a branch, they are unable to view the parent company's discounts and are unable to apply it to the sales orders. Purpose: The branch should have access to the discounts & loyalty programs from the parent company. Steps to Reproduce on Runbot: 1. Install sale_loyalty 2. Create a branch 3. On the branch company, observe that no discounts & loyalty programs from the parennt company are displayed 4. Attempt to apply a coupon code from a discount belonging to the
Original PR description
Problem: When a user is on a branch, they are unable to view the parent company's discounts and are unable to apply it to the sales orders. Purpose: The branch should have access to the discounts & loyalty programs from the parent company. Steps to Reproduce on Runbot: 1. Install sale_loyalty 2. Create a branch 3. On the branch company, observe that no discounts & loyalty programs from the parennt company are displayed 4. Attempt to apply a coupon code from a discount belonging to the parent company on a sales order and receive a ValidationError opw-4079487 closes odoo/odoo#182392 X-original-commit: 85d130302e88deb4ee8d1172d847d7ab78918418 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184807
Before this commit: The lock date error message was hard-coded to the MM/DD/YYYY format, regardless of the user's language, which causing inconsistency and confusion in date format. After this commit: The lock date error message now dynamically follows the date format set to the user's language, which improve consistency and reduce confusion. task-3925185 Forward-Port-Of: odoo/enterprise#72579 Forward-Port-Of: odoo/enterprise#70405
Original PR description
Before this commit: The lock date error message was hard-coded to the MM/DD/YYYY format, regardless of the user's language, which causing inconsistency and confusion in date format. After this commit: The lock date error message now dynamically follows the date format set to the user's language, which improve consistency and reduce confusion. task-3925185 Forward-Port-Of: odoo/enterprise#72579 Forward-Port-Of: odoo/enterprise#70405
**Version:** - 17.0 **Current Behaviour:** - Whenever tags were added to the document, the saved notification would appear, which looked odd. - Adding multiple tags caused the field size to increase, which was inappropriate. **Updated Behaviour:** - The saved notification will only appear when exiting the document. - A CSS class has been added to maintain a fixed size when adding multiple tags. task-4164151 Forward-Port-Of: odoo/enterprise#70195
Original PR description
**Version:** - 17.0 **Current Behaviour:** - Whenever tags were added to the document, the saved notification would appear, which looked odd. - Adding multiple tags caused the field size to increase, which was inappropriate. **Updated Behaviour:** - The saved notification will only appear when exiting the document. - A CSS class has been added to maintain a fixed size when adding multiple tags. task-4164151 Forward-Port-Of: odoo/enterprise#70195
Problem: The issue occurs when trying to select a different plan for a recurring product with variants in the e-commerce view. We are not refreshing the list of plans when we select another combination. Steps to reproduce: - Create a recurring product with variants. - Add multiple subscription plans with variants. - Go to the website and view the product page. - The selection of alternative plans is unavailable. opw-4179086 Forward-Port-Of: odoo/enterprise#71347
Original PR description
Problem: The issue occurs when trying to select a different plan for a recurring product with variants in the e-commerce view. We are not refreshing the list of plans when we select another combination. Steps to reproduce: - Create a recurring product with variants. - Add multiple subscription plans with variants. - Go to the website and view the product page. - The selection of alternative plans is unavailable. opw-4179086 Forward-Port-Of: odoo/enterprise#71347
In odoo/odoo#182509, a constraint on the availability_condition was added, where if availability_condition is set to country, the country_id should be set. Therefore, in tests where the availability condition is set to country, the country should be set before. task-4160643 Forward-Port-Of: odoo/enterprise#72523
Original PR description
In odoo/odoo#182509, a constraint on the availability_condition was added, where if availability_condition is set to country, the country_id should be set. Therefore, in tests where the availability condition is set to country, the country should be set before. task-4160643 Forward-Port-Of: odoo/enterprise#72523