Thursday, December 19, 2024
38 changes · saas-17.2
Resolved issues and error corrections
Email campaign reports now exclude messages that failed because of a sending error from the bounce-rate calculation. This makes bounce-rate metrics more accurate by counting only emails where delivery was actually attempted and rejected by the recipient server.
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
This fixes an issue where some pop-up panels could stay open if a user clicked away while their content was still loading. Users now get more predictable behavior, reducing small interface frustrations in Odoo.
Original PR description
Currently, ff a popover uses a component that needs to load data, click away before the component is mounted will not make the popover close. Here we fix that by adding the listeners at setup (and removing them at destroy).
Miscellaneous changes
Versions: ---------- - 17.0 Steps to Reproduce ------------ - Create a product and add the template of the field service project. - Create a sale order. - Open the project updates. - We do not see the SO and SOL buttons. Issue ------------ - SO and SOL smart button was removed on project updates in this commit https://github.com/odoo/enterprise/commit/7a82c52fb007ad0f827dd5d124f80d6195bff919 Fix ---------- - We are adding the SO and SOL buttons back. - So the user can at
Original PR description
Versions: ---------- - 17.0 Steps to Reproduce ------------ - Create a product and add the template of the field service project. - Create a sale order. - Open the project updates. - We do not see the SO and SOL buttons. Issue ------------ - SO and SOL smart button was removed on project updates in this commit https://github.com/odoo/enterprise/commit/7a82c52fb007ad0f827dd5d124f80d6195bff919 Fix ---------- - We are adding the SO and SOL buttons back. - So the user can at least see the linked data. task-3887972 Forward-Port-Of: odoo/enterprise#67793
This commit resolves an issue where users encounter a serialization error when attempting to retrieve accounts. The currency_id is now correctly passed and managed to prevent the "currency object is not serializable" error. no task id Forward-Port-Of: odoo/enterprise#75908
Original PR description
This commit resolves an issue where users encounter a serialization error when attempting to retrieve accounts. The currency_id is now correctly passed and managed to prevent the "currency object is not serializable" error. no task id Forward-Port-Of: odoo/enterprise#75908
The related community commit fixed the issue where we forgot to extract terms from spreadsheet files ending in "_dashboard.osheet.json" and were file references were added multiple times in the .pot files. This commit re-exports all spreadsheet pot files again using the fixed code. Related to https://github.com/odoo/odoo/pull/190598 Forward-Port-Of: odoo/enterprise#75605
Original PR description
The related community commit fixed the issue where we forgot to extract terms from spreadsheet files ending in "_dashboard.osheet.json" and were file references were added multiple times in the .pot files. This commit re-exports all spreadsheet pot files again using the fixed code. Related to https://github.com/odoo/odoo/pull/190598 Forward-Port-Of: odoo/enterprise#75605
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
Refactors the button bar component and makes the xlsx button always show on accounting reports. task-4402561 Forward-Port-Of: odoo/enterprise#73580
Original PR description
Refactors the button bar component and makes the xlsx button always show on accounting reports. task-4402561 Forward-Port-Of: odoo/enterprise#73580
The "remaining" value of a budget should be the difference between the amount spent and the amount forecast, not the other way around. Task-4331872 Forward-Port-Of: odoo/enterprise#73742
Original PR description
The "remaining" value of a budget should be the difference between the amount spent and the amount forecast, not the other way around. Task-4331872 Forward-Port-Of: odoo/enterprise#73742
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: 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#75315
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
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
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
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#190893 Forward-Port-Of: odoo/odoo#190782
backport test fixes from https://github.com/odoo/odoo/pull/190453 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190794
Original PR description
backport test fixes from https://github.com/odoo/odoo/pull/190453 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190794
*: 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
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#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#190735
**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"`.
- The two remaining `kanban_view_ref=` from crm are modified here.
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#190842This 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#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#188821
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#191001 Forward-Port-Of: odoo/odoo#190877
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
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#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#185664
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
When adding a reward to an order on a table, if you leave the table and come back to it the reward would be gone Steps to reproduce: ------------------- * Setup a promotion program that give 10% discount * Open a PoS restaurant open a table and add some products * The 10% discount should be applied * Leave the table and come back to it > Observation: The reward is gone Why the fix: ------------ We make sure to update the rewards when selecting the table, because when opening the ta
Original PR description
When adding a reward to an order on a table, if you leave the table and come back to it the reward would be gone Steps to reproduce: ------------------- * Setup a promotion program that give 10% discount * Open a PoS restaurant open a table and add some products * The 10% discount should be applied * Leave the table and come back to it > Observation: The reward is gone Why the fix: ------------ We make sure to update the rewards when selecting the table, because when opening the table we use the one saved on the server. opw-4161408 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183949
When attaching an image in the account module, the `_check_and_decode_attachment` method led to the deletion of non-decodable attachments, causing subsequent access errors in `IrAttachment._post_add_create` since it was trying to use deleted record Reproduce --- - -i ,account - Create new draft invoice (without lines) -> Save - Attach some pdf with invoice - Try attaching some image to the chatter -> BUG: stuck on uploading opw-4144868 Forward-Port-Of: odoo/odoo#181638
Original PR description
When attaching an image in the account module, the `_check_and_decode_attachment` method led to the deletion of non-decodable attachments, causing subsequent access errors in `IrAttachment._post_add_create` since it was trying to use deleted record Reproduce --- - -i ,account - Create new draft invoice (without lines) -> Save - Attach some pdf with invoice - Try attaching some image to the chatter -> BUG: stuck on uploading opw-4144868 Forward-Port-Of: odoo/odoo#181638
The Viva Wallet integration relies on Odoo being called by Viva Wallet via a webhook. There have been many issues of this webhook never being called, and therefore payments getting stuck in Odoo. In this commit, we add a polling fallback. Every 5 seconds we query the Viva Wallet session, and if we get a response (success/failure) then we update the payment state in the PoS. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odo
Original PR description
The Viva Wallet integration relies on Odoo being called by Viva Wallet via a webhook. There have been many issues of this webhook never being called, and therefore payments getting stuck in Odoo. In this commit, we add a polling fallback. Every 5 seconds we query the Viva Wallet session, and if we get a response (success/failure) then we update the payment state in the PoS. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190213
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
Issue: When the product "Service on Timesheet" is linked to company A, archiving products in any other company causes an error to occur. Steps to reproduce: - Install both Sales & Timesheets modules - Create a second company - On the product form, link the "Service on Timesheet" product to the second company - Archive a product from the first company Cause: The "Service on Timesheet" product is necessary for the Timesheets app to work. Having linked it to one company restricts its ac
Original PR description
Issue: When the product "Service on Timesheet" is linked to company A, archiving products in any other company causes an error to occur. Steps to reproduce: - Install both Sales & Timesheets modules - Create a second company - On the product form, link the "Service on Timesheet" product to the second company - Archive a product from the first company Cause: The "Service on Timesheet" product is necessary for the Timesheets app to work. Having linked it to one company restricts its access to others. Solution: While this is expected behaviour, I suggest blocking the user from linking the product to a company to prevent similar issues. I propose doing so since archiving and deletion are already blocked. This change still allows unlinking from the company through the UI. Ticket: opw-4270086 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190894 Forward-Port-Of: odoo/odoo#188251
Before this PR, the `forward_operator` chat bot step was not taking the user lang into account. It uses the `livechat_visitor_id` field which is not available in im_livechat. It should instead use the lang from the context. At the same time, this PR fixes an issue when restarting the chat bot: the lang of the first message following a restart is incorrect. It occurs because the lang is not properly propagated. task-4411088 opw-4341694 Forward-Port-Of: odoo/odoo#190832
Original PR description
Before this PR, the `forward_operator` chat bot step was not taking the user lang into account. It uses the `livechat_visitor_id` field which is not available in im_livechat. It should instead use the lang from the context. At the same time, this PR fixes an issue when restarting the chat bot: the lang of the first message following a restart is incorrect. It occurs because the lang is not properly propagated. task-4411088 opw-4341694 Forward-Port-Of: odoo/odoo#190832
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#189164
Currently, the extractor looking for terms to translate in spreadsheet files was specifically looking for files ending in "_spreadsheet.json". However, since this version there were new spreadsheets added that ended in "_spreadsheet.osheet.json". The translation extractor couldn't find these and the terms were never extracted, resulting in missing translations. This commit searches for both filename patterns to export the terms. We also make sure that file references are only extracted onc
Original PR description
Currently, the extractor looking for terms to translate in spreadsheet files was specifically looking for files ending in "_spreadsheet.json". However, since this version there were new spreadsheets added that ended in "_spreadsheet.osheet.json". The translation extractor couldn't find these and the terms were never extracted, resulting in missing translations. This commit searches for both filename patterns to export the terms. We also make sure that file references are only extracted once per term per file. Related to https://github.com/odoo/enterprise/pull/75605 Forward-Port-Of: odoo/odoo#190598
### Issue: - In 16.0 only, When sending a POS receipt by email, the receipt displays correctly in the preview within the POS app. However, the attached receipt in the email appears cropped, and the company logo is not centered. ### Steps to reproduce: 1. On runbot, go to the POS app. 2. Start a session. add a product, a customer and pay. 3. Click on send by email arrow button. 4. check receipt on mailhog. ### Solution: - I've wrapped the receipt content with a #receipt-wrapper div, a
Original PR description
### Issue: - In 16.0 only, When sending a POS receipt by email, the receipt displays correctly in the preview within the POS app. However, the attached receipt in the email appears cropped, and the company logo is not centered. ### Steps to reproduce: 1. On runbot, go to the POS app. 2. Start a session. add a product, a customer and pay. 3. Click on send by email arrow button. 4. check receipt on mailhog. ### Solution: - I've wrapped the receipt content with a #receipt-wrapper div, allowing you to add a padding (margin). opw-[4140950](https://www.odoo.com/web#id=4140950&view_type=form&model=project.task)  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189290 Forward-Port-Of: odoo/odoo#186852
Previously, settling a sale.order from the POS of a Belgian company would auto check the invoice option before paying. Steps to reproduce: ------------------- * Install `l10n_be_pos_cert` * Switch to the Beligian company * Crete a quotation in **Sale** app * Add any partner and any product, remove all taxes for the product line * Save * Open pos shop * Settle the order * Go to the payment screen > Observation: The invoice button is already selected. Why the fix: ------------ T
Original PR description
Previously, settling a sale.order from the POS of a Belgian company would auto check the invoice option before paying. Steps to reproduce: ------------------- * Install `l10n_be_pos_cert` * Switch to…
Previously, settling a sale.order from the POS of a Belgian company would auto check the invoice option before paying. Steps to reproduce: ------------------- * Install `l10n_be_pos_cert` * Switch to the Beligian company * Crete a quotation in **Sale** app * Add any partner and any product, remove all taxes for the product line * Save * Open pos shop * Settle the order * Go to the payment screen > Observation: The invoice button is already selected. Why the fix: ------------ This invoice option was auto selected since this commit: https://github.com/odoo/odoo/commit/c760fbb1bd2e7725b5e759198684a07060612033 The following commit https://github.com/odoo/odoo/commit/3a5e22218708b4b6c9aedfa965d9f3c279edbd46 updates the previous one as the invoice enforcement is only needed when we have intracom taxes on the SO. Thus when no intracom taxes apply we can still decide wether or not to invoice. We fallback on the default behavior which is to have the invoice button un-selected. opw-4334095 Forward-Port-Of: odoo/odoo#190945 Forward-Port-Of: odoo/odoo#188400
Currently, when using pricelists, if you change the price of a product inside the session, it will show a discount value on the receipt. Steps to reproduce: ------------------- * Activate advanced pricelist * Modify the shop's default pricelist * Discount policy: Show public price & discounts * Add a rule: 10% discount on all products with min qty of 10 * Open shop session * Add any product qty 1 * Manually change price to a higher amount * Pay the order > Observation: On the re
Original PR description
Currently, when using pricelists, if you change the price of a product inside the session, it will show a discount value on the receipt. Steps to reproduce: ------------------- * Activate advanced pricelist * Modify the shop's default pricelist * Discount policy: Show public price & discounts * Add a rule: 10% discount on all products with min qty of 10 * Open shop session * Add any product qty 1 * Manually change price to a higher amount * Pay the order > Observation: On the receipt we can see a negative discount value. Why the fix: ------------ Changing the price of a product through the price button in the session should never be considered as a discount. Lines for which the product price was manually set should not be counted toward overall discount (positive or negative). opw-4366651 Forward-Port-Of: odoo/odoo#191127 Forward-Port-Of: odoo/odoo#190785
When we pass create = false in the action context, a new record cannot be created in the kanban and list views. However, a new record could still be created in the activity view. In this commit, we have prevented that. task-3887972 Forward-Port-Of: odoo/odoo#188378
Original PR description
When we pass create = false in the action context, a new record cannot be created in the kanban and list views. However, a new record could still be created in the activity view. In this commit, we have prevented that. task-3887972 Forward-Port-Of: odoo/odoo#188378