Thursday, December 19, 2024
27 changes · saas-17.4
Resolved issues and error corrections
The website product carousel no longer starts rotating automatically after a visitor interacts with it. This restores the previous behavior and helps prevent products from moving unexpectedly while users browse.
Original PR description
In 17.2 and prior, the product carousel did not auto slide. However, after upgrading to Bootstrap 3.5.5 in 17.4, this commit 7da319c81f0a0 changed the behavior of the carousel and made it auto slide after user interactions, using `data-bs-ride="true"` attribute. This issue is known, and fixes were provided for some carousels in 9eff9ae and 1db386b. Here we apply the same fix for the products carousel. opw-4391294 opw-4404683
Point of Sale users can now open the printer selection popup when printing a daily sales report without seeing a dependency error. This removes a small blocker in the daily reporting workflow and helps staff complete end-of-day tasks smoothly.
Original PR description
PoS was displaying a dependency error when trying open the printer selection popup to print a daily sale report. opw-4171163
Miscellaneous changes
Currently, when searching the through the customers loaded in pos you can search using the zip code but if the customer is not loaded you cannot search those in db using the zip code. Steps to reproduce: ------------------- * Create a customer and set his zip code. * Open pos shop * Search for customers * Enter the zip code, normally you shouldn't see the customer * Select "Search more" > Observation: No customer found Note: If you search with the customer name it will find it. W
Original PR description
Currently, when searching the through the customers loaded in pos you can search using the zip code but if the customer is not loaded you cannot search those in db using the zip code. Steps to reproduce: ------------------- * Create a customer and set his zip code. * Open pos shop * Search for customers * Enter the zip code, normally you shouldn't see the customer * Select "Search more" > Observation: No customer found Note: If you search with the customer name it will find it. Why the fix: ------------ Adding a few search values when loeading customers in the session. opw-4334412 Forward-Port-Of: odoo/odoo#191131 Forward-Port-Of: odoo/odoo#189164
Let say we have two record with a reference field with char type. Record X with reference A Record Y with reference B If we open the record x form view directly from the list view the fetch will works as wanted (reference A) But if we use the pager to navigate to record Y, the reference field will not be correct, it will dispay the old one (reference A instead of B) This is because in the `ReferenceField` setup method we use an `useRecordObserver` to track record changes and update refer
Original PR description
Let say we have two record with a reference field with char type. Record X with reference A Record Y with reference B If we open the record x form view directly from the list view the fetch will works as wanted (reference A) But if we use the pager to navigate to record Y, the reference field will not be correct, it will dispay the old one (reference A instead of B) This is because in the `ReferenceField` setup method we use an `useRecordObserver` to track record changes and update reference data. But before this commit, we passed the wrong `props` to `_fetchReferenceCharData` `useRecordObserver` has a second argument, which is the new `props`, so we can use it instead of `this.props` still referring to the previous record This can be reproduced on `External Identifiers` view (accessible with debug) opw-4349296 Forward-Port-Of: odoo/odoo#191038 Forward-Port-Of: odoo/odoo#190970
Versions -------- - 17.0+ Steps ----- 1. Use COP, HLN or NIO as currency; 2. create a SO or invoice with a non-integer amount total; 3. create a payment link; 4. pay using Mercado Pago. Issue ----- > Error processing payment > Prices in COP currency must be expressed with integer values Cause ----- Our currency defaults follow the ISO 4217 standard for minor units. For three currencies (COP, HLN & NIO), Mercado Pago only accepts integer amounts instead of the standard 2 deci
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Use COP, HLN or NIO as currency; 2. create a SO or invoice with a non-integer amount total; 3. create a payment link; 4. pay using Mercado Pago. Issue ----- > Error processing payment > Prices in COP currency must be expressed with integer values Cause ----- Our currency defaults follow the ISO 4217 standard for minor units. For three currencies (COP, HLN & NIO), Mercado Pago only accepts integer amounts instead of the standard 2 decimals, resulting in a failed payment transaction. Solution -------- In the payload sent to Mercado Pago, round the amount down if it uses one of the affected currencies. opw-4191877 Forward-Port-Of: odoo/odoo#191084 Forward-Port-Of: odoo/odoo#185664
Commit [1] broke the tooltip about domain configuration on the website switcher. They just did not appear ever anymore. At the same time, it moved a translatable term from XML to JS, which apparently works without losing translations... but it also changed the actual term by removing the "." at the end, losing the translations. This commit also restore that ".", making existing translations work again automatically, and it also patches the ".pot" to notify about the translatable term move.
Original PR description
Commit [1] broke the tooltip about domain configuration on the website switcher. They just did not appear ever anymore. At the same time, it moved a translatable term from XML to JS, which apparently works without losing translations... but it also changed the actual term by removing the "." at the end, losing the translations. This commit also restore that ".", making existing translations work again automatically, and it also patches the ".pot" to notify about the translatable term move. [1]: https://github.com/odoo/odoo/commit/dbd2f89b4fe88488d3b02e475fae6ac8878694ae Forward-Port-Of: odoo/odoo#191077 Forward-Port-Of: odoo/odoo#190877
This test is linked to this commit: https://github.com/odoo/odoo/commit/42eb159b6adb668d26cfb31aec2a59a1fd4d3a00 Related PR: https://github.com/odoo/odoo/pull/188204 opw-4352799 Forward-Port-Of: odoo/odoo#190906 Forward-Port-Of: odoo/odoo#188821
Original PR description
This test is linked to this commit: https://github.com/odoo/odoo/commit/42eb159b6adb668d26cfb31aec2a59a1fd4d3a00 Related PR: https://github.com/odoo/odoo/pull/188204 opw-4352799 Forward-Port-Of: odoo/odoo#190906 Forward-Port-Of: odoo/odoo#188821
When selling a product that use automated valuation in the PoS, and shipping it later, the expense account would be debited 2 times. Steps to reproduce: ------------------- * Create a product category that use AVCO and automated valuation * Create a product that uses this category * Activate the ship later option in the PoS settings * Open PoS and sell this product using the ship later option * Validate the picking created for the order > Observation: Go in the session journal items, t
Original PR description
When selling a product that use automated valuation in the PoS, and shipping it later, the expense account would be debited 2 times. Steps to reproduce: ------------------- * Create a product category that use AVCO and automated valuation * Create a product that uses this category * Activate the ship later option in the PoS settings * Open PoS and sell this product using the ship later option * Validate the picking created for the order > Observation: Go in the session journal items, the expense account is debited two times Why the fix: ------------ Because we create the expense moves when validating the ship later picking, we shouldn't do it when closing the session. opw-4338182 Forward-Port-Of: odoo/odoo#188097
Add a check on Viva Wallet callback when paying. Verify if the pending payment line exist before processing the callback. Adapted from: https://github.com/odoo/odoo/pull/186580 opw-4242322 opw-4374450 Forward-Port-Of: odoo/odoo#190983 Forward-Port-Of: odoo/odoo#190735
Original PR description
Add a check on Viva Wallet callback when paying. Verify if the pending payment line exist before processing the callback. Adapted from: https://github.com/odoo/odoo/pull/186580 opw-4242322 opw-4374450 Forward-Port-Of: odoo/odoo#190983 Forward-Port-Of: odoo/odoo#190735
Currently, mailing traces that have error'd due to an exception during sending still count as 'sent' for the purposes of calculating email bounce rates. This makes it so that error'd email traces (those that have encountered an exception during the sending process) no longer count as sent for the purposes of calculating email bounce rates (the rate of emails whose delivery was attempted, but were rejected by the destination email server. task-4380451 Forward-Port-Of: odoo/odoo#190070
Original PR description
Currently, mailing traces that have error'd due to an exception during sending still count as 'sent' for the purposes of calculating email bounce rates. This makes it so that error'd email traces (those that have encountered an exception during the sending process) no longer count as sent for the purposes of calculating email bounce rates (the rate of emails whose delivery was attempted, but were rejected by the destination email server. task-4380451 Forward-Port-Of: odoo/odoo#190070
### Initial issue: On a stock move, when using a lot from a sub-location, the created SML will still start from SM's source location instead of lot's location ### This issue was fixed in: - 17.0 by: https://github.com/odoo/odoo/commit/6b158aa333cf111472e4b850543b8379f0e998b7 - saas-17.2+ by: https://github.com/odoo/odoo/commit/8dec391fff243b4d079ceafd6c19b84008d2fe36 However, there is a tiny corner case where the fix of 17.0 is better than the one of saas-17.2: If you were to put hal
Original PR description
### Initial issue: On a stock move, when using a lot from a sub-location, the created SML will still start from SM's source location instead of lot's location ### This issue was fixed in: - 17.0 by:…
### Initial issue: On a stock move, when using a lot from a sub-location, the created SML will still start from SM's source location instead of lot's location ### This issue was fixed in: - 17.0 by: https://github.com/odoo/odoo/commit/6b158aa333cf111472e4b850543b8379f0e998b7 - saas-17.2+ by: https://github.com/odoo/odoo/commit/8dec391fff243b4d079ceafd6c19b84008d2fe36 However, there is a tiny corner case where the fix of 17.0 is better than the one of saas-17.2: If you were to put half of a lot in a pack in a sublocation and the other half eslewhere, the current fix of saas-17.2 would not use the sublocation that is however available as it relies on the 'location_id' field of the `stock.lot` model which will not be set in that valid use case: https://github.com/odoo/odoo/blob/d9cca6201a39c431deaf13891a314dde2db7e82e/addons/stock/models/stock_lot.py#L155-L159 The purpose of the present PR is to reconcile both fix by reverting the current one and by adapting the test to both usecases. Revert "[FIX] stock: start SML from sub location" This reverts commit https://github.com/odoo/odoo/commit/8dec391fff243b4d079ceafd6c19b84008d2fe36. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189009 Forward-Port-Of: odoo/odoo#188840
Since https://github.com/odoo/odoo/pull/152498, we invalidate the 'templates' orm cache when we load the registry if there is an onchange trigger automation exists. Every time that a worker takes its first request or that the registry is reloaded, it will then invalidate this long-term (we try anyway) cache, reducing its efficiency depending on worker recycling. Forward-Port-Of: odoo/odoo#190393
Original PR description
Since https://github.com/odoo/odoo/pull/152498, we invalidate the 'templates' orm cache when we load the registry if there is an onchange trigger automation exists. Every time that a worker takes its first request or that the registry is reloaded, it will then invalidate this long-term (we try anyway) cache, reducing its efficiency depending on worker recycling. Forward-Port-Of: odoo/odoo#190393
Steps to reproduce: - Insert a list in a spreadsheet (e.g. CRM Lead) - Create a global filter, set a value on it (filter on CRM Stages -> Select new) - Open the list side panel, update the domain (add Marc Demo as Salesperson) - Save => The domain does not take the global filter into account Task:4398467 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
Original PR description
Steps to reproduce: - Insert a list in a spreadsheet (e.g. CRM Lead) - Create a global filter, set a value on it (filter on CRM Stages -> Select new) - Open the list side panel, update the domain (add Marc Demo as Salesperson) - Save => The domain does not take the global filter into account Task:4398467 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#191039 Forward-Port-Of: odoo/odoo#190782
In https://github.com/odoo/odoo/pull/113577 this view was added in the wrong module. Not only people using `l10n_it_edi` need to debug this information, but also those using EDI for other countries. I know this PR kinda violates the stability guidelines. However, #113577 also did, and here I'm fixing a bug that landed there. I hope you can still consider the PR for merging. Please tell me if there are any changes needed for making it better suited for merge if needed. Thanks! @moduon MT
Original PR description
In https://github.com/odoo/odoo/pull/113577 this view was added in the wrong module. Not only people using `l10n_it_edi` need to debug this information, but also those using EDI for other countries. I know this PR kinda violates the stability guidelines. However, #113577 also did, and here I'm fixing a bug that landed there. I hope you can still consider the PR for merging. Please tell me if there are any changes needed for making it better suited for merge if needed. Thanks! @moduon MT-8204 OPW-4362382 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191028 Forward-Port-Of: odoo/odoo#189673
We get an access error when trying to register a vendor payment with a user having access only to a branch company. Steps: - Create a branch B - Create a user U with company_id and company_ids being B - Log as user U - Create and confirm a vendor bill - Open the 'Register payment' wizard and try to create a payment -> Access Error on company id opw-4317289 Forward-Port-Of: odoo/odoo#191063 Forward-Port-Of: odoo/odoo#188512
Original PR description
We get an access error when trying to register a vendor payment with a user having access only to a branch company. Steps: - Create a branch B - Create a user U with company_id and company_ids being B - Log as user U - Create and confirm a vendor bill - Open the 'Register payment' wizard and try to create a payment -> Access Error on company id opw-4317289 Forward-Port-Of: odoo/odoo#191063 Forward-Port-Of: odoo/odoo#188512
**Current behavior:** On the Mobile view, when modifying the Sales Team field of a Partner (team_id field), an error is raised: "Undefined graph model for Sales Team:". **Expected behavior:** The user should be able to modify the Sales Team field of a Partner without any error. **Steps to reproduce:** 1. Install the `sales_team` & `contacts` modules. 2. Create a new Partner. 3. Go to the Mobile view. 4. Click on the Sales Team field and select a Sales Team. 5. The error is immediate
Original PR description
**Current behavior:** On the Mobile view, when modifying the Sales Team field of a Partner (team_id field), an error is raised: "Undefined graph model for Sales Team:". **Expected behavior:** The…
**Current behavior:**
On the Mobile view, when modifying the Sales Team field of a Partner (team_id field), an error is raised: "Undefined graph model for Sales Team:".
**Expected behavior:**
The user should be able to modify the Sales Team field of a Partner without any error.
**Steps to reproduce:**
1. Install the `sales_team` & `contacts` modules.
2. Create a new Partner.
3. Go to the Mobile view.
4. Click on the Sales Team field and select a Sales Team.
5. The error is immediately raised.
**Cause of the issue:**
The `kanban_view_ref="%(sales_team.crm_team_view_kanban)s"` added to the `team_id` field is not applied, as `kanban_view_ref=` has become deprecated. The kanban view `sales_team.crm_team_view_kanban_dashboard` is loaded instead as it has a lower priority.
**Fix:**
- Use `context="{'kanban_view_ref': 'sales_team.crm_team_view_kanban'}` instead of `kanban_view_ref="%(sales_team.crm_team_view_kanban)s"`.
opw-4413594
Related PRs: #116031, #126044
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#190842Steps to reproduce: - Insert a pivot in a spreadsheet (e.g. CRM Lead) - Create a global filter, set a value on it (filter on CRM Stages -> Select new) - Open the pivot side panel, update something (move up a dimension) - Save => The domain does not take the global filter into account Task: 4398645 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 guid
Original PR description
Steps to reproduce: - Insert a pivot in a spreadsheet (e.g. CRM Lead) - Create a global filter, set a value on it (filter on CRM Stages -> Select new) - Open the pivot side panel, update something (move up a dimension) - Save => The domain does not take the global filter into account Task: 4398645 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#190951 Forward-Port-Of: odoo/odoo#190781
*: mass_mailing Users with website_designer permissions but without access to the email marketing app (mass_mailing.group_mass_mailing_user) encountered an access error when editing pages with "Newsletter" blocks. This commit fixes the issue by granting read-only access to the mailing.list model for the website_designer group. This ensures they can edit pages containing "Newsletter" blocks without exposing full email marketing functionality or compromising security. Steps to reproduce:
Original PR description
*: mass_mailing Users with website_designer permissions but without access to the email marketing app (mass_mailing.group_mass_mailing_user) encountered an access error when editing pages with "Newsletter" blocks. This commit fixes the issue by granting read-only access to the mailing.list model for the website_designer group. This ensures they can edit pages containing "Newsletter" blocks without exposing full email marketing functionality or compromising security. Steps to reproduce: - Install the website and mass_mailing modules. - Remove the "Email Marketing: User" access rights from a user in Settings > Users. - Open the Website Editor. - Add a "Newsletter" block to a page. - Observe: An access error is triggered. opw-4201455 Forward-Port-Of: odoo/odoo#190188
The PR [1] fixes a memory leak in the tooltip service. The `Map` was used with `HTMLElement` as key. These elements were not removed and so never garbage collected. A more important issue is that these elements could retain info from components like views with models. In a forward port, the change `Map` to `WeakMap` dispeared. This PR just re-adds this diff. [1]: https://github.com/odoo/odoo/pull/186579 Forward-Port-Of: odoo/odoo#190954
Original PR description
The PR [1] fixes a memory leak in the tooltip service. The `Map` was used with `HTMLElement` as key. These elements were not removed and so never garbage collected. A more important issue is that these elements could retain info from components like views with models. In a forward port, the change `Map` to `WeakMap` dispeared. This PR just re-adds this diff. [1]: https://github.com/odoo/odoo/pull/186579 Forward-Port-Of: odoo/odoo#190954
Before this commit: When user created Sales Credit Note, and send it for E-waybill. On the portal, it shows as a Supple Type as `Inward` instead of `Outward`. In this commit: We fix the above issue. opw-4402929 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190878 Forward-Port-Of: odoo/odoo#190805
Original PR description
Before this commit: When user created Sales Credit Note, and send it for E-waybill. On the portal, it shows as a Supple Type as `Inward` instead of `Outward`. In this commit: We fix the above issue. opw-4402929 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190878 Forward-Port-Of: odoo/odoo#190805
A stock valuation issue occurs when a landed cost is present in a bill lines of a purchase order (without the `stock.landed_cost` created) and the receipt note is validated after confirming the bill. Steps to reproduce: - Create a product with automated inventory valuation and AVCO. - On the purchase tab, set the control policy to “on ordered quantity”. - Create a purchase order with this product: * Quantity: 1 * Unit cost: $10 - Validate the PO. - Create a bill and add a landed co
Original PR description
A stock valuation issue occurs when a landed cost is present in a bill lines of a purchase order (without the `stock.landed_cost` created) and the receipt note is validated after confirming the bill.…
A stock valuation issue occurs when a landed cost is present in a bill lines of a purchase order (without the `stock.landed_cost` created) and the receipt note is validated after confirming the bill. Steps to reproduce: - Create a product with automated inventory valuation and AVCO. - On the purchase tab, set the control policy to “on ordered quantity”. - Create a purchase order with this product: * Quantity: 1 * Unit cost: $10 - Validate the PO. - Create a bill and add a landed cost line: * Quantity: 1 * Cost: $25 - Validate the bill. - Validate the receipt note. - Check the valuation: * The unit value will be incorrect, calculated as $17.5 ((10 + 25) / 2). This issue is caused by commit https://github.com/odoo/odoo/commit/5d067851248aaadf4f447f144a22553f9b188b71. The solution is to include only landed cost lines from bills where the `stock.landed.cost` is created and validated. opw-4384070 opw-4383063 Forward-Port-Of: odoo/odoo#191000 Forward-Port-Of: odoo/odoo#190815
Forward-Port-Of: odoo/enterprise#75570
Original PR description
Forward-Port-Of: odoo/enterprise#75570
Users only need the computation of the document type field for customer invoices. As a result, this fix restricts the assignment of document types to customer invoices, while preserving the standard functionality for all other document types. task-4299210 This is a fix for #73945 Forward-Port-Of: odoo/enterprise#75335
Original PR description
Users only need the computation of the document type field for customer invoices. As a result, this fix restricts the assignment of document types to customer invoices, while preserving the standard functionality for all other document types. task-4299210 This is a fix for #73945 Forward-Port-Of: odoo/enterprise#75335
Steps to reproduce: 1) Via Studio, modify the 'Journal Items' tab to add 'Start date' and 'End date' to the list view 2) Create a purchase tax 3) Create a bill with the tax created in the previous step 4) Select deferred dates in the future 5) Check the journal items (two lines with deferred dates) 6) Go back to the 'Invoice lines' tab, delete the deferred dates and check the journal items again => one line still present the deferred dates!! Reason: When removing the `deferred_start_da
Original PR description
Steps to reproduce: 1) Via Studio, modify the 'Journal Items' tab to add 'Start date' and 'End date' to the list view 2) Create a purchase tax 3) Create a bill with the tax created in the previous…
Steps to reproduce: 1) Via Studio, modify the 'Journal Items' tab to add 'Start date' and 'End date' to the list view 2) Create a purchase tax 3) Create a bill with the tax created in the previous step 4) Select deferred dates in the future 5) Check the journal items (two lines with deferred dates) 6) Go back to the 'Invoice lines' tab, delete the deferred dates and check the journal items again => one line still present the deferred dates!! Reason: When removing the `deferred_start_date` and the `deferred_end_date` from the invoice line, the newly computed `tax_key` for the tax line(s) will not have the `deferred_start_date` and the `deferred_end_date` fields, by [_get_deferred_tax_key](https://github.com/odoo-dev/enterprise/blob/c2c3a8591b3a5dfa402acb981564e46e0ff4ced9/account_accountant/models/account_move.py#L582). However, since when updating the tax line(s), we merge the old values with the new values (obtained in part from the before mentioned updated key), by this code in [_sync_dynamic_line](https://github.com/odoo/odoo/blob/f3d3e0c612392f1a35b9c131d29b4f3bd70a9d36/addons/account/models/account_move.py#L2599-L2602), and since the new key values of the tax line(s) does not have the `deferred_start_date` and the `deferred_end_date` explicitly set to `False`, and since the old key values have those fields set, merging new values with the old values will keep the old `deferred_start_date` and the `deferred_end_date`, resulting in a mismatch between the deferred dates on the invoice line and the tax lines. Fix: Now, `_get_deferred_tax_key` explicitly set `deferred_start_date` and the `deferred_end_date` to `False` when `tax_repartition_line_id ` is defined, to make sure they override any old `deferred_start_date` and the `deferred_end_date` existing in the old keys. opw-4328465 Forward-Port-Of: odoo/enterprise#75860 Forward-Port-Of: odoo/enterprise#75315
This commit updates the process to pass the company's currency code to the `_get_accounts` route. By doing so, the server can accurately identify the company's currency. This change is particularly important for supporting testing banks. task-4293992 Forward-Port-Of: odoo/enterprise#75735 Forward-Port-Of: odoo/enterprise#75372
Original PR description
This commit updates the process to pass the company's currency code to the `_get_accounts` route. By doing so, the server can accurately identify the company's currency. This change is particularly important for supporting testing banks. task-4293992 Forward-Port-Of: odoo/enterprise#75735 Forward-Port-Of: odoo/enterprise#75372
Currently a traceback is occurring when there is no working time (calendar_id) in resource, while creating a planning slot. To reproduce this issue: 1) Install planning 2) Open any planning slot in Gantt view and redirect to resource from the slot 3) Remove the Working Time of that resource 4) Now try to create a new planning slot for that resource from Gantt view Error:- ``` ValueError: Expected singleton: resource.calendar() ``` Here, `calendar_id` is not required in the r
Original PR description
Currently a traceback is occurring when there is no working time (calendar_id) in resource, while creating a planning slot. To reproduce this issue: 1) Install planning 2) Open any planning slot in…
Currently a traceback is occurring when there is no working time (calendar_id) in resource, while creating a planning slot. To reproduce this issue: 1) Install planning 2) Open any planning slot in Gantt view and redirect to resource from the slot 3) Remove the Working Time of that resource 4) Now try to create a new planning slot for that resource from Gantt view Error:- ``` ValueError: Expected singleton: resource.calendar() ``` Here, `calendar_id` is not required in the resource. So, when the user removes the calendar_id from the resource and tries to create a new planning slot, it leads to the above traceback. In the below line, we try to get calendar_d from the resource if it is available. https://github.com/odoo/enterprise/blob/7847510dc6ad8dec73f01470714aacb0c3510769/planning/models/planning.py#L611-L612 We can resolve this issue by taking calendar_id from the company as it is required. If it fails to get the value from the resource. sentry-6150920391 Forward-Port-Of: odoo/enterprise#75713
Steps to reproduce: - Install helpdesk_stock and Studio - Create 3 contacts, 1 company and two child employees - Create a quotation for each contact with a different product - Helpdesk app > Create a ticket - Add the Product ('product_id') field with studio - (Under 'Existing Fields' search product) - (View tab > Show invisible elements > Find product field > untick invisible) The products from contacts linked to the parent company should appear, but only those related to SOs from the
Original PR description
Steps to reproduce:
- Install helpdesk_stock and Studio
- Create 3 contacts, 1 company and two child employees
- Create a quotation for each contact with a different product
- Helpdesk app > Create a ticket
- Add the Product ('product_id') field with studio
- (Under 'Existing Fields' search product)
- (View tab > Show invisible elements > Find product field > untick invisible)
The products from contacts linked to the parent company should appear, but only those related to SOs from the contact itself or its parent company are shown (i.e. We should see all 3 products no matter which contact is set as customer).
This is related to https://github.com/odoo/enterprise/pull/73391, which was a step in the right direction but still insufficient. Unlike that fix however this one is relevant up to master.
opw-4285382
Forward-Port-Of: odoo/enterprise#75766
Forward-Port-Of: odoo/enterprise#74361