Monday, August 5, 2024
29 changes · saas-17.2
Miscellaneous changes
Before this PR: When we included the ability to create "Facturas de compra" (code 46, needed mainly for the purchase of digital services to foreign vendors), we get schema errors sending these type of invoices to the SII (l10n_cl_reference_doc_type_selection == 46). The use of the tag Exportaciones for document type '46' is not correct. This tag should be used only for foreign customers on Export documents. This case is only for the following codes: '110', '111', '112'. An "Activity descr
Original PR description
Before this PR: When we included the ability to create "Facturas de compra" (code 46, needed mainly for the purchase of digital services to foreign vendors), we get schema errors sending these type of invoices to the SII (l10n_cl_reference_doc_type_selection == 46). The use of the tag Exportaciones for document type '46' is not correct. This tag should be used only for foreign customers on Export documents. This case is only for the following codes: '110', '111', '112'. An "Activity description" is mandatory, as it's not an export document. The country customs code must be included in the Nacionalidad tag as well, as the vendor is foreign. Reference: Law Nº21420, and resolution Nº46 (May 13th, 2022) https://www.bcn.cl/leychile/navegar?idNorma=1172303 https://www.sii.cl/normativa_legislacion/resoluciones/2022/reso46.pdf After this PR: These issues are fixed. Community PR: https://github.com/odoo/odoo/pull/166793 Forward-Port-Of: odoo/enterprise#63244
Add the modelo 130 report for spain localization task-3866238 Linked PR : https://github.com/odoo/odoo/pull/164946 Forward-Port-Of: odoo/enterprise#62197
Original PR description
Add the modelo 130 report for spain localization task-3866238 Linked PR : https://github.com/odoo/odoo/pull/164946 Forward-Port-Of: odoo/enterprise#62197
To reproduce: Activate Avatax (in Sandbox mode) Create an invoice to a partner from Colorado Put the 0F4000000 code on the Avatax Category of a product Create a line with this product Click on "Compute Taxes" => A tax named "Retail Delivery Fee [08] (29.0000 %)" is created The issue is that if you look on Avatax, it's supposed a fixed 0.29 tax. opw-4036105 Forward-Port-Of: odoo/enterprise#67882 Forward-Port-Of: odoo/enterprise#66973
Original PR description
To reproduce: Activate Avatax (in Sandbox mode) Create an invoice to a partner from Colorado Put the 0F4000000 code on the Avatax Category of a product Create a line with this product Click on "Compute Taxes" => A tax named "Retail Delivery Fee [08] (29.0000 %)" is created The issue is that if you look on Avatax, it's supposed a fixed 0.29 tax. opw-4036105 Forward-Port-Of: odoo/enterprise#67882 Forward-Port-Of: odoo/enterprise#66973
Fixed `test_industry_fsm_at_install` by activating the pricelist before creating the sale order to ensure a proper link. task-4070526 Forward-Port-Of: odoo/enterprise#67612
Original PR description
Fixed `test_industry_fsm_at_install` by activating the pricelist before creating the sale order to ensure a proper link. task-4070526 Forward-Port-Of: odoo/enterprise#67612
To reproduce: ============= - on Salary structure type "Worker" change its "Default Scheduled Pay" to another value than monthly (bi-weekly). - on the contract templates, create a new one for that structure and set hourly Wage = 10$ - onrecruitment applications, generate an offer with that template Check the link > It should show 800$ (which is 10$ an hour * 40 hours a week * 2 for the bi-wkeely frequency) but still mention it is the monthly Salary (which should be 1600$) Problem
Original PR description
To reproduce: ============= - on Salary structure type "Worker" change its "Default Scheduled Pay" to another value than monthly (bi-weekly). - on the contract templates, create a new one for that structure and set hourly Wage = 10$ - onrecruitment applications, generate an offer with that template Check the link > It should show 800$ (which is 10$ an hour * 40 hours a week * 2 for the bi-wkeely frequency) but still mention it is the monthly Salary (which should be 1600$) Problem: ======== - the salary displayed on the salary configurator doesn't take into account the frequency of the salary structure Solution: ========= - change the label to mention the frequency of the salary structure opw-3963698 Forward-Port-Of: odoo/enterprise#64105
The message to buy extra credits is escaped and instead of displaying the message with a link it displays the message with a html and a url, not very human user like. We have to unescape the < and > symbols so that the frontend can properly display the message Ticket [link](https://www.odoo.com/web#model=project.task&id=3864033) opw-3864033 Forward-Port-Of: odoo/enterprise#63364
Original PR description
The message to buy extra credits is escaped and instead of displaying the message with a link it displays the message with a html and a url, not very human user like. We have to unescape the < and > symbols so that the frontend can properly display the message Ticket [link](https://www.odoo.com/web#model=project.task&id=3864033) opw-3864033 Forward-Port-Of: odoo/enterprise#63364
In TimerTimesheetGridRenderer, super.onWillStart was not awaited. We take the opportunity to factorize some code and parallelize some rpcs. Forward-Port-Of: odoo/enterprise#67909 Forward-Port-Of: odoo/enterprise#67864
Original PR description
In TimerTimesheetGridRenderer, super.onWillStart was not awaited. We take the opportunity to factorize some code and parallelize some rpcs. Forward-Port-Of: odoo/enterprise#67909 Forward-Port-Of: odoo/enterprise#67864
In this commit, we had the partner information to the receipt header of the CL PoS when the order is a factura. This is needed in order to be compliant with the CL law. task-id: 3747828 Forward-Port-Of: odoo/enterprise#67553 Forward-Port-Of: odoo/enterprise#67168
Original PR description
In this commit, we had the partner information to the receipt header of the CL PoS when the order is a factura. This is needed in order to be compliant with the CL law. task-id: 3747828 Forward-Port-Of: odoo/enterprise#67553 Forward-Port-Of: odoo/enterprise#67168
Steps to reproduce: 1. Create a product and add stock in the following location: WH/Stock/Shelf 2 2. Create a field service task and add this product 3. validate the task, the transfer will happen from WH/Stock Bug: If you validate the Sale Order, then the transfer, then the field service task, then transfer will happen from WH/Stock/Shelf 2 (as expected) Fix: apply same logic as for serial tracked products opw-3835698 Forward-Port-Of: odoo/enterprise#67450 Forward-Port-Of: odoo/e
Original PR description
Steps to reproduce: 1. Create a product and add stock in the following location: WH/Stock/Shelf 2 2. Create a field service task and add this product 3. validate the task, the transfer will happen from WH/Stock Bug: If you validate the Sale Order, then the transfer, then the field service task, then transfer will happen from WH/Stock/Shelf 2 (as expected) Fix: apply same logic as for serial tracked products opw-3835698 Forward-Port-Of: odoo/enterprise#67450 Forward-Port-Of: odoo/enterprise#65316
This commit's purpose is to disable the helpdesk ticket creation command when there are no teams available for the current connected user. Currently, using this command this way will create a new ticket without any team attached, rendering it useless. step to reproduce: - install helpdesk application - open helpdesk - open confifuration menu, select helpdesk team - select 'customer care' - activate the livechat option and saves - leave helpdesk - change from the current active company
Original PR description
This commit's purpose is to disable the helpdesk ticket creation command when there are no teams available for the current connected user. Currently, using this command this way will create a new…
This commit's purpose is to disable the helpdesk ticket creation command when there are no teams available for the current connected user. Currently, using this command this way will create a new ticket without any team attached, rendering it useless. step to reproduce: - install helpdesk application - open helpdesk - open confifuration menu, select helpdesk team - select 'customer care' - activate the livechat option and saves - leave helpdesk - change from the current active company to any other company that doesn't have any helpdesk team with the livechat feature enabled - open the discuss app and select the 'general' discussion - type /helpdesk your_ticket a new ticket will be created without any team linked to it. source of the issue: when a team has the livechat option enable, the command is added to the livechat regardless of the connected user's access right to the team. solution: Only add the command to the list of livechat command if the user has access to at least one team with the livechat feature enable. affected version : 15.0 - master task - 3631682 https://www.odoo.com/web#id=3631682&menu_id=4720&cids=1&action=333&active_id=4105&model=project.task&view_type=form Forward-Port-Of: odoo/enterprise#65838 Forward-Port-Of: odoo/enterprise#53510
### Steps to Reproduce 1. Install the `account_reports` module. 2. Enable Analytic Accounting in the settings. 3. Create a new field for the Journal Items model with a name containing uppercase characters (e.g., `x_TEST`). 4. Navigate to the 'Profit and Loss' report and attempt to use the 'Analytic Group by' feature. ### Current Behavior The following error occurs: ``` psycopg2.errors.UndefinedColumn: column account_move_line.x_test does not exist ``` ### Cause In PostgreSQL, unqu
Original PR description
### Steps to Reproduce 1. Install the `account_reports` module. 2. Enable Analytic Accounting in the settings. 3. Create a new field for the Journal Items model with a name containing uppercase characters (e.g., `x_TEST`). 4. Navigate to the 'Profit and Loss' report and attempt to use the 'Analytic Group by' feature. ### Current Behavior The following error occurs: ``` psycopg2.errors.UndefinedColumn: column account_move_line.x_test does not exist ``` ### Cause In PostgreSQL, unquoted identifiers are automatically converted to lowercase, leading to issues when fields contain uppercase characters. opw-4086902 opw-4082082 opw-4086627 Forward-Port-Of: odoo/enterprise#67807
This commit is a follow up of its enterprise part. We add the user_context to the the params of the function to have access to the allowed_companies of the current user later on in the process. affected version: 15.0- master task - 361682 https://www.odoo.com/web#id=3631682&menu_id=4720&cids=1&action=333&active_id=4105&model=project.task&view_type=form Forward-Port-Of: odoo/odoo#171436 Forward-Port-Of: odoo/odoo#147768
Original PR description
This commit is a follow up of its enterprise part. We add the user_context to the the params of the function to have access to the allowed_companies of the current user later on in the process. affected version: 15.0- master task - 361682 https://www.odoo.com/web#id=3631682&menu_id=4720&cids=1&action=333&active_id=4105&model=project.task&view_type=form Forward-Port-Of: odoo/odoo#171436 Forward-Port-Of: odoo/odoo#147768
Steps to reproduce the issue: - Debug mode > Settings > Technical > Decimal Precision > Product Price - Set to another number - Purchase > Any Purchase order - Mobile view, puchased item has a decimal precision of 2 Why is this a bug: Kanban view is the only one to disregard Product Price Precision setting What this fix does: Update the display with correct decimal precision opw-3984082 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr F
Original PR description
Steps to reproduce the issue: - Debug mode > Settings > Technical > Decimal Precision > Product Price - Set to another number - Purchase > Any Purchase order - Mobile view, puchased item has a decimal precision of 2 Why is this a bug: Kanban view is the only one to disregard Product Price Precision setting What this fix does: Update the display with correct decimal precision opw-3984082 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172049
Currently, when a loyalty program has a reward of type product and uses `reward_product_tag_id` (set up for at least 2 products), the addition of rewards to the pos order will have mismatched reward lines when adding the second free product (the first product needed to be added first). Steps to reproduce: ------------------- * Go to **Point of Sale** App * Go to **Products** and add a tag (the same) for two products * Under **Products** select `Discount & Loyalty` * Create a new program
Original PR description
Currently, when a loyalty program has a reward of type product and uses `reward_product_tag_id` (set up for at least 2 products), the addition of rewards to the pos order will have mismatched reward…
Currently, when a loyalty program has a reward of type product and uses `reward_product_tag_id` (set up for at least 2 products), the addition of rewards to the pos order will have mismatched reward lines when adding the second free product (the first product needed to be added first).
Steps to reproduce:
-------------------
* Go to **Point of Sale** App
* Go to **Products** and add a tag (the same) for two products
* Under **Products** select `Discount & Loyalty`
* Create a new program of type **Buy X Get Y**
* Rule:
* Min qty: 2 products $0.00
* Among Products: Put all chairs products for example
* Reward:
* Type: Free Product
* Product: None
* Product tag: The tag put on the products previously
* Open shop session
* Add 2 chairs
* Select reward, add the first one
> Everything ok until now
* Add 2 chairs
* Select reward, add the second one
> Observation: Reward computation is wrong we have the following lines:
```
4 Chairs,
Reward 1,
Reward 2,
Free product reward 1
```
> We are missing the free product line related to the second product added and the button to select reward is still highlighted.
Why the fix:
------------
To explain this fix I will use the example given above.
Here are the steps that have been executed already
* Add 2 chairs
* Add the first reward product
* Add 2 chairs
We are currently in the middle of the step "Add second reward product". During that process, we end up in the function `_computeUnclaimedFreeProductQty` while computing values for the reward line. At this very moment in time, the order has the following lines:
* 4 Chairs
* Product 1
* Free product (related to Product 1)
* Product 2
Where Product 1 and Product 2 are the reward products, having the same tag.
Let's focus on this piece of code, with the current example: https://github.com/odoo/odoo/blob/76023820c4d725c81677d2bf3e010c8cee1edd19/addons/pos_loyalty/static/src/js/Loyalty.js#L1464-L1475
Where `product` in this case is `Product 2`. What is happening here at the end is that we have `available = 1` because of line 4 and `claimed = 1` because of line 3. The program considers that we have already claimed the quantity and is the reason why it is not adding the reward line.
The first idea to fix this issue was to write the condition:
```js
if (reward.reward_product_ids.includes(product.id) && reward.reward_product_ids.includes(line.product.id)) {
```
instead of this one
```js
if (line.get_product().id === product.id) {
```
Now both line 2 and 4 are counted toward the `available` quantity. This way the code knows that we have two availaible free product but only 1 was claimed.
While this fixed the original issue, a new issue was created. Now, when we add the second product, the two reward lines were grouped together, using the price of the first free product added. Why was this happening?
Well, once the fist call to the function `_computeUnclaimedFreeProductQty` was done and the reward line was added we had the following order (temporarily)
* 4 Chairs
* Product 1
* Free product (related to Product 1)
* Product 2
* Free product (related to Product 2)
Which is what we expect but we face an issue when the loyalty programs are updated. When the programs update, we go through the function `_updateRewardLines`. In this function we discard the reward lines from the order and then for each claimed reward (Product 1 and Product 2) we re-apply the reward.
While applying the reward for Product 1, we again go through the function `_computeUnclaimedFreeProductQty`. In this case, the order looks like this:
* 4 Chairs
* Product 1
* Product 2
and the function will say that there are 2 available free product and 0 claimed. Were it is technically true, in this case we want to have the available quantity to 1. We want the initial condition:
```js
if (line.get_product().id === product.id) {
```
In the second passage, for product 2, we have `available = 2` and `claimed = 2`.
opw-3587020
Forward-Port-Of: odoo/odoo#175514
Forward-Port-Of: odoo/odoo#173529Steps to reproduce the bug: - In Website edit mode. - Drag and drop enough snippets to have a vertical scrollbar. - Scroll the page to the top. - Drag and drop a dynamic snippet (e.g. Products) at the bottom of the viewport. - Bug: The page doesn't scroll to the dynanmic snippet. The bug was due to the fact that we needed to know the top position of the snippet to set the scroll value. However, it wasn't possible to get the offset of the element because the dynamic snippets were set to
Original PR description
Steps to reproduce the bug: - In Website edit mode. - Drag and drop enough snippets to have a vertical scrollbar. - Scroll the page to the top. - Drag and drop a dynamic snippet (e.g. Products) at…
Steps to reproduce the bug: - In Website edit mode. - Drag and drop enough snippets to have a vertical scrollbar. - Scroll the page to the top. - Drag and drop a dynamic snippet (e.g. Products) at the bottom of the viewport. - Bug: The page doesn't scroll to the dynanmic snippet. The bug was due to the fact that we needed to know the top position of the snippet to set the scroll value. However, it wasn't possible to get the offset of the element because the dynamic snippets were set to "display: none" when this calculation was made. It's a bug we had before and fixed with this commit [1]. It worked. But since this other commit [2] where dynamic snippets are no longer hidden with the Bootstrap class "d-none" but with the class "o_dynamic_empty", the fix no longer works. [1]: https://github.com/odoo/odoo/commit/963f0ed02eba929fcbc65fe51bef95c2a1dcf2ea [2]: https://github.com/odoo/odoo/commit/63def9c87305dd7773e0592a28fe19d0b63c0878 task-4072655 Forward-Port-Of: odoo/odoo#175207
This fix removes the analytic account distribution as a criteria to split down payments lines (like the taxes are) and weight its distribution according to the line amounts and analytic account distributions. opw-4033706 Forward-Port-Of: odoo/odoo#175513 Forward-Port-Of: odoo/odoo#175078
Original PR description
This fix removes the analytic account distribution as a criteria to split down payments lines (like the taxes are) and weight its distribution according to the line amounts and analytic account distributions. opw-4033706 Forward-Port-Of: odoo/odoo#175513 Forward-Port-Of: odoo/odoo#175078
Avoid setting default value of zero for Integer/Float fields or False for Boolean fields (those are already the fields default) This avoid triggering write on the related models (on multi-companies database with millions on journal entries this speedup the installation of modules from ~8-9 minutes to ~15 seconds) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175597 Forward-Port-Of: odoo/odoo#175585
Original PR description
Avoid setting default value of zero for Integer/Float fields or False for Boolean fields (those are already the fields default) This avoid triggering write on the related models (on multi-companies database with millions on journal entries this speedup the installation of modules from ~8-9 minutes to ~15 seconds) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175597 Forward-Port-Of: odoo/odoo#175585
Numerous terms were missing from the translation template file. Forward-Port-Of: odoo/odoo#175393 Forward-Port-Of: odoo/odoo#175206
Original PR description
Numerous terms were missing from the translation template file. Forward-Port-Of: odoo/odoo#175393 Forward-Port-Of: odoo/odoo#175206
**Description** - From 16.0, while opening invoices of accounting and clicking on the web studio button, it is showing traceback for French localization of the "l10n_fr" module. As per [this](https://github.com/odoo/odoo/pull/171275) file in V16, module [l10n_fr_invoice_addr] has been optimized to adapt the documents as per new French law. Although, the traceback is showing due to the fact that while performing the "l10n_fr_invoice_addr" module's view, the "shipping_field" has set the groups
Original PR description
**Description** - From 16.0, while opening invoices of accounting and clicking on the web studio button, it is showing traceback for French localization of the "l10n_fr" module. As per…
**Description** - From 16.0, while opening invoices of accounting and clicking on the web studio button, it is showing traceback for French localization of the "l10n_fr" module. As per [this](https://github.com/odoo/odoo/pull/171275) file in V16, module [l10n_fr_invoice_addr] has been optimized to adapt the documents as per new French law. Although, the traceback is showing due to the fact that while performing the "l10n_fr_invoice_addr" module's view, the "shipping_field" has set the groups to null in this [account_move.py](https://github.com/odoo/odoo/pull/171275/files#diff-5125aad1cd2220c7e0c4cfe80ec0541acf5e9f4dbce46fb370e94cd281012b36R17) file which should not be the case. Due to this, as per this [condition](https://github.com/odoo/odoo/blob/16.0/odoo/models.py#L1464), it is trying to find groups in V16.0, which will lead to traceback as the groups are set null here. Whereas in stable version 15.0, it was working due to the fact that previously the groups were set to null through the [account_move.xml](https://github.com/odoo/odoo/blob/15.0/addons/l10n_fr_invoice_addr/views/account_move_views.xml#L9) file. - As a result, to resolve this issue this commit will pop the groups of "shipping_field" instead of setting it to null to bypass the traceback for the invoices of "l10n_fr" localization. **Steps to Reproduce (V16.0)** - Change the language to French. - Install "l10n_fr" module - Get an FR company. - Create an invoice, it's partner(customer) should be of FR , then confirm the invoice. - Open the invoice and then click on the web studio button. **Solution** - To resolve this issue this commit will pop the groups of "shipping_field" instead of setting it to null to bypass the traceback for the invoices of "l10n_fr" localization. **Current behavior before PR:**  --- opw-[4044861](https://www.odoo.com/odoo/project.task/4044861?cids=2) I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173162
Previously, there was no clean way to redirect old URLs like /xx.asp?id=xx with the correct HTTP status code. This update adds support for such redirects, allowing people to migrate to Odoo more easily. fiximp-realife --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175188
Original PR description
Previously, there was no clean way to redirect old URLs like /xx.asp?id=xx with the correct HTTP status code. This update adds support for such redirects, allowing people to migrate to Odoo more easily. fiximp-realife --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175188
Add the modelo 130 report for spain localization task-3866238 Linked PR : https://github.com/odoo/enterprise/pull/62197 Forward-Port-Of: odoo/odoo#164946
Original PR description
Add the modelo 130 report for spain localization task-3866238 Linked PR : https://github.com/odoo/enterprise/pull/62197 Forward-Port-Of: odoo/odoo#164946
Description of the issue/feature this PR addresses: Before this fix, It was not possible to issue a credit note code 61 to be applied to an invoice of type '46' when the vendor was foreign. Typically, credit notes for foreign vendors are code 112; however, code 61 is necessary to reverse a type 46 invoice. After this PR: In the validation included in this PR, we allow this credit note type 61, provided there is a reference to a code '46' invoice, included in the document reference model.
Original PR description
Description of the issue/feature this PR addresses: Before this fix, It was not possible to issue a credit note code 61 to be applied to an invoice of type '46' when the vendor was foreign. Typically, credit notes for foreign vendors are code 112; however, code 61 is necessary to reverse a type 46 invoice. After this PR: In the validation included in this PR, we allow this credit note type 61, provided there is a reference to a code '46' invoice, included in the document reference model. This PR corresponds to the odoo/enterprise PR enabling the issuance of type 46 invoices referenced below: this PR replaces: https://github.com/odoo/odoo/pull/166400 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166793
The purpose of this PR is to be able to process a lot of serial numbers at once. In receipt and deliveries In the current situation, the number of serial already in stock has an impact on the perf (due to `update_available_quantity` that do a `_gather` on current stock). All the metrics below are made with 50 000 SN already in stock Before (in seconds): || Receipt | Delivery | |--------|--------|--------| |100| 1.63 | 34.21 | |5000| 87.04 | 242.56 | |30 000| 563.75 | T.O. | After:
Original PR description
The purpose of this PR is to be able to process a lot of serial numbers at once. In receipt and deliveries In the current situation, the number of serial already in stock has an impact on the perf…
The purpose of this PR is to be able to process a lot of serial numbers at once. In receipt and deliveries In the current situation, the number of serial already in stock has an impact on the perf (due to `update_available_quantity` that do a `_gather` on current stock). All the metrics below are made with 50 000 SN already in stock Before (in seconds): || Receipt | Delivery | |--------|--------|--------| |100| 1.63 | 34.21 | |5000| 87.04 | 242.56 | |30 000| 563.75 | T.O. | After: || Receipt | Delivery | |--------|--------|--------| |100| 0.91 | 5.62 | |5000| 47.21 | 56.28 | |30 000| 195.27 | 307.80 | By operations/ receipts (for 5000): | | action_assign | button_validate | total | |--------|--------|--------|--------| | Before patch | 5.38 | 82.02 | 87.04 | | After patch | 3.82 | 43.39 | 47.21 | By operations/ deliveries (for 5000): | | action_assign | button_validate | total | |--------|--------|--------|--------| | Before patch | 180.06 | 62.50 | 242.56 | | After patch | 20.51 |35.77 | 56.28 | The main issues: - The constraint check on quant/stock.move.line are done one by one since there is nothing done in batch, same for computed field (Not fixed here)  - The put away takes an important amount of times without any putaways rules  - The optimisation made in #116803 was a good idea but it was only use in action_assign. `_action_assign` use strict=False in `_gather` (mts case). It means a child_of operator is in the domain, and it will perform an extra query anyway - The lot_name matching to lot_id is made `stock.move.line` by `stock.move.line` on 30 000, half of the time is spent to find them.  After some testing. The quant_cache could contain too many items than needed by the current operation. Example receive 1 serial number (that will not have an existing quant) will use a quant_cache with all the serial number of the products. As a result, the group by will be super slow. Allow to add an extra domain, to limit the cache size. /!\ could be dangerous if it filter out too much  Forward-Port-Of: odoo/odoo#163799 Forward-Port-Of: odoo/odoo#146494
When a downpayment was made in the sales app, it was not imported correctly in PoS when importing the order. Steps to reproduce: ------------------- * Create a sale order * Make a downpayment for the sale order (Create invoice -> downpayment) * Pay the downpayment * Open PoS and try to settle the order > Observation: The downpayment doesn't appear in the PoS Why the fix: ------------ Since this PR #148732 the downpayment product has been removed when doing a downpayment in PoS. It
Original PR description
When a downpayment was made in the sales app, it was not imported correctly in PoS when importing the order. Steps to reproduce: ------------------- * Create a sale order * Make a downpayment for the sale order (Create invoice -> downpayment) * Pay the downpayment * Open PoS and try to settle the order > Observation: The downpayment doesn't appear in the PoS Why the fix: ------------ Since this PR #148732 the downpayment product has been removed when doing a downpayment in PoS. It was causing the downpayment line to be filtered out when importing the order in PoS here https://github.com/odoo/odoo/blob/0592aa98bc582dab6ac739a82bf3f6d9ec372ec8/addons/pos_sale/models/sale_order.py#L61 opw-4021708 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172302
If for some reason you want to apply taxes on the gift card reward, they were not correctly applied. Steps to reproduce: ------------------- * Create a gift card program * Find the gift card reward product in the program * Add some taxes to it * Open a PoS session, add some product and use a gift card > Observation: The tax on the gift card product is not taken into account Why the fix: ------------ When generating the gift card we force all taxes to be included in price this wa
Original PR description
If for some reason you want to apply taxes on the gift card reward, they were not correctly applied. Steps to reproduce: ------------------- * Create a gift card program * Find the gift card reward product in the program * Add some taxes to it * Open a PoS session, add some product and use a gift card > Observation: The tax on the gift card product is not taken into account Why the fix: ------------ When generating the gift card we force all taxes to be included in price this way the value of the gift card is not modified, but the taxes are applied opw-3916989 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173712 Forward-Port-Of: odoo/odoo#170590
Description of the issue/feature this PR addresses: This commit fixes a read access error on the field employee_ids of hr_leave when a user, who is not in group_hr_holidays_user, tries to cancel/refuse a timeoff. The bug only appears when the timeoff crosses a public holiday. Current behavior before PR: An access error pops up when an user , who is not a timeoff officer/admin, tries to cancel a timeoff. The timeoff should cross a public holiday in order for the bug to appear. Desired
Original PR description
Description of the issue/feature this PR addresses: This commit fixes a read access error on the field employee_ids of hr_leave when a user, who is not in group_hr_holidays_user, tries to cancel/refuse a timeoff. The bug only appears when the timeoff crosses a public holiday. Current behavior before PR: An access error pops up when an user , who is not a timeoff officer/admin, tries to cancel a timeoff. The timeoff should cross a public holiday in order for the bug to appear. Desired behavior after PR is merged: The user is able to cancel its timeoff even if he/she is not a timeoff officer/admin. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174682
Filtering devices by name fails if `devices_list` is empty. Type check on devices should prevent from trying to get the value of `name` on a string. PR being fixed: [https://github.com/odoo/odoo/pull/175277](https://github.com/odoo/odoo/pull/175277) Forward-Port-Of: odoo/odoo#175434 Forward-Port-Of: odoo/odoo#175356
Original PR description
Filtering devices by name fails if `devices_list` is empty. Type check on devices should prevent from trying to get the value of `name` on a string. PR being fixed: [https://github.com/odoo/odoo/pull/175277](https://github.com/odoo/odoo/pull/175277) Forward-Port-Of: odoo/odoo#175434 Forward-Port-Of: odoo/odoo#175356
Contact widget was causing a schema.org error on safari for mobile versions in checkout and in payment confirmation, which caused customers to be weary of paying on odoo. Removed the use of contact widget and displayed the address instead opw-4062917 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175524
Original PR description
Contact widget was causing a schema.org error on safari for mobile versions in checkout and in payment confirmation, which caused customers to be weary of paying on odoo. Removed the use of contact widget and displayed the address instead opw-4062917 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175524
### Steps to reproduce * install `l10n_sa` * create a new invoice and add a line with a product and a custom label. * print the invoice You will see in the 'Description' column that the product's display name is shown instead of the label you set opw-4071925 Forward-Port-Of: odoo/odoo#175025
Original PR description
### Steps to reproduce * install `l10n_sa` * create a new invoice and add a line with a product and a custom label. * print the invoice You will see in the 'Description' column that the product's display name is shown instead of the label you set opw-4071925 Forward-Port-Of: odoo/odoo#175025