Thursday, December 26, 2024
11 changes · saas-17.4
Resolved issues and error corrections
This fix prevents spreadsheet global filters from being applied to pivot tables that are not connected to Odoo data. As a result, users can update these external or non-Odoo pivot tables without encountering an error.
Original PR description
Steps to reproduce: - Insert a non-odoo pivot table - Try to update it => Traceback This was introduced by fe95f7fa64d6c2694980b4d9f6d03dc744ddaf19 opw-4429514 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
Miscellaneous changes
Tax included in price were not taken into account when using a loyalty program applying on the cheapest product. Steps to reproduce: ------------------- * Create a loyalty program that apply 10% reward on cheapest product * Create a product A that has 10% tax included in price * Open PoS and add this product to the order (make sure this is the cheapest in the order) > Observation: The discount is not taking the tax into account opw-4243827 Forward-Port-Of: odoo/odoo#191382 Forward
Original PR description
Tax included in price were not taken into account when using a loyalty program applying on the cheapest product. Steps to reproduce: ------------------- * Create a loyalty program that apply 10% reward on cheapest product * Create a product A that has 10% tax included in price * Open PoS and add this product to the order (make sure this is the cheapest in the order) > Observation: The discount is not taking the tax into account opw-4243827 Forward-Port-Of: odoo/odoo#191382 Forward-Port-Of: odoo/odoo#189612
### 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#190211 Forward-Port-Of: odoo/odoo#186852
Current behavior before PR: - currently, we directly set the excluded property to 'true', which do not check for 'undefined' values, which are possible in certain cases. This fix ensure to set the property only if it is present. Desired behavior after PR is merged: - excluded property will set only for defined objects. ## steps to reproduce: - create two product, `main` & `optional` - for `main`, add two attribute values : eg height: 20, 30 - for `optional`, add attribute values : e
Original PR description
Current behavior before PR: - currently, we directly set the excluded property to 'true', which do not check for 'undefined' values, which are possible in certain cases. This fix ensure to set the…
Current behavior before PR:
- currently, we directly set the excluded property to 'true', which do not check for 'undefined' values, which are possible in certain cases. This fix ensure to set the property only if it is present.
Desired behavior after PR is merged:
- excluded property will set only for defined objects.
## steps to reproduce:
- create two product, `main` & `optional`
- for `main`, add two attribute values : eg height: 20, 30
- for `optional`, add attribute values : eg width : 100, 200, 300
- set `optional` as optional product for main product
- configure height values for `main` product-> for value 20: exclude `optional` product of attribute 200,300
- create a sale order with `optional` product and attribute 200. ( confirm the SO)
- now remove the attribute value 200 from `optional` product.
- try to create new quotation for main product.(traceback will appear)
## Traceback
```py
TypeError: Cannot set properties of undefined (setting 'excluded')
at ProductConfiguratorDialog._checkExclusions (http://localhost:9000/web/assets/00d1566/web.assets_web_dark.min.js:16288:175)
at ProductConfiguratorDialog._checkExclusions (http://localhost:9000/web/assets/00d1566/web.assets_web_dark.min.js:16291:181)
at ProductConfiguratorDialog._updateProductTemplateSelectedPTAV (http://localhost:9000/web/assets/00d1566/web.assets_web_dark.min.js:16283:100)
at ProductTemplateAttributeLine.updateSelectedPTAV (http://localhost:9000/web/assets/00d1566/web.assets_web_dark.min.js:16310:1317)
at Object.mainEventHandler
```
## Description
the moment we removed 200 attribute from optinal product, it went for check to be [unlink or become archived](https://github.com/odoo/odoo/blob/17.0/addons/product/models/product_template_attribute_value.py#L140-L147).
as it is linked to a SO, it cannot be deleted and simply left to archive.
due to this flow, the related record from product.template.attribute.exclusion still remains,
and when we fetch the list of ids of parent_exclusion, it [return](https://github.com/odoo/odoo/blob/17.0/addons/product/models/product_template.py#L974-L976) the archived value too, which is not present in ptavlist
We cannot simple delete the value from the relation table, as when the ptav 300 is again added, it is reused ( ptav_active sets to true) , and old relation starts to work together
## solution:
ignore the archived ptavs.
opw-4365068
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#190608**Problem**: The function `_getColumnSize` returns the size of the columns. When `gridIndex = columnSize;` is assigned and `columnSize` equals 12, it causes an overflow in the `grid` array. This leads to invalid elements being passed to `_applyColspan`. **Solution**: Ensure `_applyColspan` is only called when `gridIndex` is within valid bounds. **Steps to reproduce**: 1. Open an email marketing template. 2. Extend the "Centered Logo" snippet to the maximum size (`col-12`). 3. Observe
Original PR description
**Problem**: The function `_getColumnSize` returns the size of the columns. When `gridIndex = columnSize;` is assigned and `columnSize` equals 12, it causes an overflow in the `grid` array. This leads to invalid elements being passed to `_applyColspan`. **Solution**: Ensure `_applyColspan` is only called when `gridIndex` is within valid bounds. **Steps to reproduce**: 1. Open an email marketing template. 2. Extend the "Centered Logo" snippet to the maximum size (`col-12`). 3. Observe a traceback error. opw-4381159 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190677
Currently a `ParseError` is arising when user installs the 'website_livechat' module after deleting the 'YourWebsite.com' channel from 'im_livechat' module. To reproduce this error: - Install 'im_livechat' module. - Open the application and delete 'YourWebsite.com' channel by going to 'Configure Channel' - Now try to install the 'website_livechat' module. - The error appears in the log. Error: `ParseError while parsing /home/odoo/src/odoo/18.0/addons/website_livechat/data/ website_li
Original PR description
Currently a `ParseError` is arising when user installs the 'website_livechat' module after deleting the 'YourWebsite.com' channel from 'im_livechat' module.
To reproduce this error:
- Install 'im_livechat' module.
- Open the application and delete 'YourWebsite.com' channel by going to 'Configure Channel'
- Now try to install the 'website_livechat' module.
- The error appears in the log.
Error: `ParseError
while parsing /home/odoo/src/odoo/18.0/addons/website_livechat/data/ website_livechat_data.xml:4, somewhere inside
<record id="website.default_website" model="website">
<field name="channel_id" ref="im_livechat.im_livechat_channel_data"/>
</record>`
This commit solves the above issue by using `forcecreate='False'` to bypass
record creation if it violates checks.
sentry-6107471185
Forward-Port-Of: odoo/odoo#189566We delete a constraint that requires to have an accepted original document in order to be able to generate CN or DN. This is not actually needed: 1. if there is a problem with the original document then DGI response will let us know and will reject our DN/CN 2. In the case I create an invoice, and immediately found an error we can now generate the credit note: not need to wait the invoices has been process. They will process together by the cron. 3. For the case that we need to generate DN
Original PR description
We delete a constraint that requires to have an accepted original document in order to be able to generate CN or DN. This is not actually needed: 1. if there is a problem with the original document then DGI response will let us know and will reject our DN/CN 2. In the case I create an invoice, and immediately found an error we can now generate the credit note: not need to wait the invoices has been process. They will process together by the cron. 3. For the case that we need to generate DN and CN where the original related document was generate with other sofware (for example a DN or CN from an old invoice genrated in previos sofware provider) without this constraint is possible. LATAM 1301 / ADHOC Ticket 46212 Forward-Port-Of: odoo/enterprise#75789
## Issue: - Uploading a Mexican XML file with an 8% tax results in the addition of an extra 8% tax. ## Steps to reproduce: - Create a new invoice and add a line with an 8% tax. - Validate the invoice and export it as XML. - Upload the XML file as a vendor bill. - The vendor bill incorrectly shows two "8% taxes" instead of one. ## Solution: - The issue stems from a forward-port error from `saas-16.4` https://github.com/odoo/enterprise/commit/5681a8d5abee3a8787f3ee8612a8c3b18ed63ee6 to
Original PR description
## Issue: - Uploading a Mexican XML file with an 8% tax results in the addition of an extra 8% tax. ## Steps to reproduce: - Create a new invoice and add a line with an 8% tax. - Validate the invoice…
## Issue: - Uploading a Mexican XML file with an 8% tax results in the addition of an extra 8% tax. ## Steps to reproduce: - Create a new invoice and add a line with an 8% tax. - Validate the invoice and export it as XML. - Upload the XML file as a vendor bill. - The vendor bill incorrectly shows two "8% taxes" instead of one. ## Solution: - The issue stems from a forward-port error from `saas-16.4` https://github.com/odoo/enterprise/commit/5681a8d5abee3a8787f3ee8612a8c3b18ed63ee6 to `17.0` https://github.com/odoo/enterprise/commit/56a2b66d84d8398ea870d559cd55cfeae44019d8 - In `17.0` we introduced this Extract method `_l10n_mx_edi_import_cfdi_get_tax_from_node` to refactor the `_l10n_mx_edi_import_cfdi_fill_invoice_line`. - We should have add the Exento checks in the new method however we mistakenly pushed code from `saas-16.4` to `17.0` without adapting it. - I removed the extra code introduced during the forward-porting. - Refactored the related code to ensure compatibility with the new changes in `17.0`. OPW-4198016 Forward-Port-Of: odoo/enterprise#74602
…ing taxes Steps to reproduce ================== - Create a company in Canada with the canadian fiscal localization - Configure the avatax sandbox credentials - Create a new fiscal position in the USA that uses the avatax API - Create a USD pricelist - Create a warehouse in Cleveland Ohio - Create a salesorder with an Ohio based customer and the USD pricelist - Select a storable product with an invoicing policy on delivered quantity - Set the avatax category of the product to "H
Original PR description
…ing taxes Steps to reproduce ================== - Create a company in Canada with the canadian fiscal localization - Configure the avatax sandbox credentials - Create a new fiscal position in the…
…ing taxes Steps to reproduce ================== - Create a company in Canada with the canadian fiscal localization - Configure the avatax sandbox credentials - Create a new fiscal position in the USA that uses the avatax API - Create a USD pricelist - Create a warehouse in Cleveland Ohio - Create a salesorder with an Ohio based customer and the USD pricelist - Select a storable product with an invoicing policy on delivered quantity - Set the avatax category of the product to "Hand tools" - Select the warehouse just created on the sales order - Click on the "Compute taxes" button => The tax is set to 1% - Confirm the sales order => The tax is still set to 1% - Validate the delivery and create + confirm a new invoice => The tax is now 2.25% Cause of the issue ================== When computing the addresses to send to Avatax, the stock move addresse was used, but at this point, they have not yet been created Solution ======== We now use the warehouse from the sales order. This is only a best-effort estimation of where the products will ship from. It's possible products ship from a different warehouse than warehouse_id. For example, you can change the default delivery route to pull from a source location in a different warehouse. However, this is probably not a common configuration. In the end, the only way to know for sure is to run the inventory-related code, which we want to avoid just for tax computation. Finally, it's also possible for users to change the warehouse manually after the order is confirmed. This can also potentially change taxes, and there's no way to anticipate this. The account.move code will continue to pull the warehouse from the stock.move, because we know it will be created before the invoice. Note that even on account.move the shipping address remains an estimation for products with an “invoice on ordered” invoicing policy. opw-4073701 Forward-Port-Of: odoo/enterprise#75655
Before this commit, when the content of the expense is updated by OCR, the author might not be "OdooBot". This happened because while filling the document with results (in hr_expense._predict_product) there is a savepoint that removes the author. This commit sets the OCR note author after filling the document with results, which makes sure that the correct author (i.e., OdooBot) is always set. Moreover, if the expense receipt has a dot in its name, the _predict_product was never visited.
Original PR description
Before this commit, when the content of the expense is updated by OCR, the author might not be "OdooBot". This happened because while filling the document with results (in hr_expense._predict_product) there is a savepoint that removes the author. This commit sets the OCR note author after filling the document with results, which makes sure that the correct author (i.e., OdooBot) is always set. Moreover, if the expense receipt has a dot in its name, the _predict_product was never visited. So, the attachment name extraction is fixed to make sure that only file extension was removed. This commit also adds unit tests to expense and invoice OCR extract to make sure that their notes are authored by OdooBot. The test was not introduced in hr.applicant, however, since OCR does not change any tracked fields (i.e., OCR never logs a note on the chatter). task-4197413 Forward-Port-Of: odoo/enterprise#75756
The 2 exports have the same name, which is impractical. Let's differentiate them task-4414223 Forward-Port-Of: odoo/enterprise#75957 Forward-Port-Of: odoo/enterprise#75907
Original PR description
The 2 exports have the same name, which is impractical. Let's differentiate them task-4414223 Forward-Port-Of: odoo/enterprise#75957 Forward-Port-Of: odoo/enterprise#75907