Daily updates from Odoo
Navigate
Branch
Thursday, December 26, 2024
42 changes
4 changes
Miscellaneous changes
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#189566**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
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#190608Three commits are included in this PR. - One adds a base module for all Nilvera modules - One adds a module to handle sending and receiving E-Invoices and E-Archives to and from Nilvera. - One adds general improvements to UBL. task-3952234 Forward-Port-Of: odoo/odoo#180283
Original PR description
Three commits are included in this PR. - One adds a base module for all Nilvera modules - One adds a module to handle sending and receiving E-Invoices and E-Archives to and from Nilvera. - One adds general improvements to UBL. task-3952234 Forward-Port-Of: odoo/odoo#180283
10 changes
Enhancements to existing features
Product public descriptions are now available directly in the Point of Sale product information popup. This helps store staff see customer-facing product details in the PoS terminal without needing extra self-order or delivery integrations installed.
Original PR description
Before this commit: ========== - The public description field is only visible in the product form after the `pos_self_order` or `pos_urban_piper` modules have been installed. - We are not providing a public description in the product information popup for the PoS terminal. After this commit: ========== - The public description field is visible after the `point_of_sale` module is installed in the product form view. - Public description is available in the product information popup for the PoS terminal. task- 4337758 Related: https://github.com/odoo/odoo/pull/189122
Resolved issues and error corrections
Duplicated shifts in Planning now recalculate allocated hours when assigned to a different employee. This prevents employees with different working schedules from receiving incorrect planned hours, improving schedule accuracy and payroll-related planning data.
Original PR description
Steps to reproduce: ------------------- 1. Install Planning app 2. Have an employee A with 40h/week working schedule and an employee B with 35h/week working schedule 3. Create a shift and assign it to employee A, the default allocated hours should be 8h 4. From the Gantt view, duplicate this shift and assign it to employee B (use drag and drop) 5. Problem: The allocated hours of the duplicated shift are not recomputed, they are equal to 8h instead of 7h Fix: ------------------- When duplicating a shift and assigning it to another resource, the copy() method is called with the resource_id of the target resource (an employee in this case). But _compute_allocated_hours() is not called so we have to call it explicitly in this case. task-3978590
Miscellaneous changes
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#76194 Forward-Port-Of: odoo/enterprise#75756
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
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
Steps to reproduce ================== - Archive default "Projects" workspace - Create a new Project - Create a task and attach a file - Click on the smart button to view the document - Go back to the home menu and open the documents app => `Cannot read properties of undefined (reading 'id')` Solution ======== Prevent the archiving of the projects workspace opw-4308132 Forward-Port-Of: odoo/enterprise#76153 Forward-Port-Of: odoo/enterprise#75659
Original PR description
Steps to reproduce ================== - Archive default "Projects" workspace - Create a new Project - Create a task and attach a file - Click on the smart button to view the document - Go back to the home menu and open the documents app => `Cannot read properties of undefined (reading 'id')` Solution ======== Prevent the archiving of the projects workspace opw-4308132 Forward-Port-Of: odoo/enterprise#76153 Forward-Port-Of: odoo/enterprise#75659
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
…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
Implement delivery guide functionality for Ecuador. - Added a new "Delivery Guide" group within the "Other Info" tab to record details such as transporter, plate number, transfer reason, and delivery dates. - Enabled the generation and electronic submission of the delivery guide document. - Added functionality to cancel the electronic delivery guide if needed. - Provided the option to download the generated XML in case of any submission issues. - Included the ability to send the delivery
Original PR description
Implement delivery guide functionality for Ecuador. - Added a new "Delivery Guide" group within the "Other Info" tab to record details such as transporter, plate number, transfer reason, and delivery dates. - Enabled the generation and electronic submission of the delivery guide document. - Added functionality to cancel the electronic delivery guide if needed. - Provided the option to download the generated XML in case of any submission issues. - Included the ability to send the delivery guide by email to the partner for their records.  Forward-Port-Of: odoo/enterprise#68468
Community: https://github.com/odoo/odoo/pull/191697 Design Themes: https://github.com/odoo/design-themes/pull/1038 Forward-Port-Of: odoo/enterprise#76159
Original PR description
Community: https://github.com/odoo/odoo/pull/191697 Design Themes: https://github.com/odoo/design-themes/pull/1038 Forward-Port-Of: odoo/enterprise#76159
added a session key to indicate if the current session is connected to an Italian company. Related: https://github.com/odoo/odoo/pull/189610 Forward-Port-Of: odoo/enterprise#75147
Original PR description
added a session key to indicate if the current session is connected to an Italian company. Related: https://github.com/odoo/odoo/pull/189610 Forward-Port-Of: odoo/enterprise#75147
26 changes
Enhancements to existing features
The IoT Box homepage now shows a clearer warning when the HTTPS certificate is missing or has an issue, helping users understand that their subscription may not be linked. The technical view still provides detailed error information so support teams can diagnose certificate problems faster.
Original PR description
In this commit: =============== - Display a warning alert on the homepage when no HTTPS certificate is linked or there's an issue with the certificate, and the technical tab is inactive. - The alert notifies the user that their IoT Box subscription is not linked and advises contacting the account manager to unlock full potential. - On opening the technical tab, show a detailed error code retrieved from the IoT Box to assist in diagnosing HTTPS certificate issues. Task-4364406 Related enterprise PR-https://github.com/odoo/enterprise/pull/74949 
Point of Sale settings now include a documentation link for configuring Razorpay payment terminals. This makes it easier for businesses to find setup guidance directly from the configuration screen, reducing confusion during payment terminal onboarding.
Original PR description
In this commit: =============== Added documentation link in pos.config for Razorpay terminal Task-4431707
The IoT setup flow now uses clearer wording when guiding users through connecting an IoT box. This should reduce confusion during setup and help users understand connection steps or issues more easily.
Original PR description
In this commit: ================ This commit updates text strings Task-4364406 Related community PR-https://github.com/odoo/odoo/pull/189263
Resolved issues and error corrections
CRM pipeline stages now show helpful tooltip text again when users hover over a stage that has requirements set. This restores expected guidance in the Kanban view, helping sales teams understand stage criteria without opening the stage settings.
Original PR description
**Issue:** No tooltips are displayed on hovering CRM leads stages in Kanban view. **Expected:** As for versions up to 17.4, on hovering the stage, if requirements are set, a tooltip box should appear. **Steps to reproduce:** - Activate CRM app; - Open a CRM leads pipeline in Kanban view; - Edit a stage by adding a requirement text and save; - Place the mouse over the stage and wait. **Cause:** The tooltip box display has been removed for over simplification. **Fix:** Add a tooltip box display based on stage title hover and reverting 1 line of https://github.com/odoo-dev/odoo/commit/232c218d87a94e1d77fc69afdbfd77e340504cad#diff-62eff7f830df5fbafad68abd5de0373654a620f6685cbcf3a4b8c20db64f0b7cL540. opw-4359292 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes website navigation so mega menu headings and links are highlighted when visitors are on a matching page. It makes menus behave consistently with regular navigation items, helping visitors better understand where they are on the site.
Original PR description
The active CSS class was not applied to parent items of the mega menu or their child items, resulting in the corresponding menu item not being highlighted in the navigation bar. This commit ensures that the active class is correctly applied to mega menu items, providing consistent highlighting behavior similar to regular pages. Steps to reproduce: - Open the Website Editor. - Navigate to Site > Menu Editor. - Add a Mega Menu and save the changes. - Edit the page. - Open the Mega Menu. - Change any link to /contactus-thank-you. - Save the changes. - Visit /contactus-thank-you. - Observe that the Mega Menu title does not appear as active opw-4383641 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
Brazilian customers can now properly choose a city when adding or editing a delivery address during checkout. This prevents checkout validation errors caused by an empty city list and avoids asking for VAT details where they are not needed for delivery addresses.
Original PR description
In BR localization, when a logged user tries to edit the delivery address during checkout it may occur that the city field is missing the selection list, causing the form to always return a validation error Steps to reproduce (with a BR company setup) - In Website > Configuration > Settings, set BR company as owner of website - Log in as new user - Add an item to the cart - Go to checkout and add all the address info - In the addresses selection page, uncheck 'Same as delivery address' and add a new delivery address Issue: City selection list will be empty This occurs because, when user is editing the delivery address without 'Save as delivery address' the system won't provide the city list. Moreover it will attempt to validate VAT info (fields `vat` and `l10n_latam_identification_type_id`) for delivery addresses opw-4411470
This update makes an internal point-of-sale QR payment test more consistent by ensuring it uses only the intended test product. It helps prevent random automated test failures, improving confidence in system validation without changing customer-facing behavior.
Original PR description
Prevent random runbot error by making sure only the Hand Bag product is available.
Point of Sale receipt printing has been corrected so receipts no longer produce an extra empty page at the end. This reduces paper waste and avoids confusion for staff and customers when printing receipts.
Original PR description
Before this commit, printing a receipt would result in an empty page at the end. This commit ensures that the receipt is printed correctly without any additional empty pages. opw-4389871 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents payroll contract names from being unintentionally overwritten when work schedule-related changes are copied or applied. It helps keep contract information consistent when other payroll or HR processes have already set a specific name.
Original PR description
- adapt the `copy_data` to not override the name set by another module Task: 4391527
The journal dashboard now includes credit notes and refunds when showing open sales and purchase journals. The Bills to Validate filter has also been aligned with the dashboard logic, helping finance teams see consistent and accurate pending bill information.
Original PR description
Update the open sale/purchase journals query to include credit notes/refunds, and override the 'Bills to validate' filter to be consistent with the dashboard query which is overridden for `account_3way_match`
Italian Point of Sale now relies on standard accounting tax calculations so it better matches fiscal printer totals when products are sold with tax included. Businesses using Italian POS should configure tax-included pricing, with a pricelist and fiscal position workaround available for tax-excluded catalog prices.
Original PR description
Remove patches around tax calculations. Use the accounting calculations natively. As a result, there will be a limitation to use the `l10n_it_pos` properly. The taxes should be price-included when selling products in pos, otherwise, the system's calculations will deviate from the connected fiscal printer's calculations. The accounting team is looking for a native solution to make the fiscal printer work with price-excluded taxes. A workaround for the limitation is to introduce pricelist and fiscal position. The pricelist maps the originally tax-excluded price to tax-included price, and the fiscal position maps the price-excluded tax to price-included equivalent.
Users creating purchase requests from the Approvals app can no longer trigger an error when adding a new vendor for a product. The vendor field now guides users to the full creation form, ensuring required vendor, price, and quantity details are entered correctly.
Original PR description
Steps to reproduce: 1. Open the `Approvals` app. 2. Select `Create RFQs`. 3. Add any product. 4. Try to create a new vendor for the added product. 5. An error will occur. Explanation of the bug: In order to specify a vendor, one needs to specify the vendor data, the price of the product and the quantity of the product sold for that price. So, when the user starts typing to create a new vendor and then presses on `Create`, an error occurs because it can't be determined which field should be filled with the entered data. i.e. will the entered data be used to fill the vendor data, the product price or the product quantity? This commit fixes the bug by only allowing `Create and Edit` option for the vendor column. task-4337135
Miscellaneous changes
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 Forward-Port-Of: odoo/odoo#191774
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 Forward-Port-Of: odoo/odoo#191774
Before this commit, when loading a partner, it was possible to load programs that were not available. opw-4339514 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191704
Original PR description
Before this commit, when loading a partner, it was possible to load programs that were not available. opw-4339514 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191704
The informations displayed on journal dashboard on sale/purchase journals should include both invoices/bills and credit notes/refunds, as well as the moves shown in the list view when coming from the journal card hyperlinks. opw-4328137 Forward-Port-Of: odoo/odoo#187692
Original PR description
The informations displayed on journal dashboard on sale/purchase journals should include both invoices/bills and credit notes/refunds, as well as the moves shown in the list view when coming from the journal card hyperlinks. opw-4328137 Forward-Port-Of: odoo/odoo#187692
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#190608This PR aims to improve the color of the file input field that did not change when the theme color or input color was updated. With this PR, the file input field color will now adjust according to the background color of the input field and the theme color. task-4174112 Forward-Port-Of: odoo/odoo#184814
Original PR description
This PR aims to improve the color of the file input field that did not change when the theme color or input color was updated. With this PR, the file input field color will now adjust according to the background color of the input field and the theme color. task-4174112 Forward-Port-Of: odoo/odoo#184814
For an expense report paid by an employee, the bank account set on the employee form should be used to create the Journal Entry and as a default bank account in Register Payment Wizard. task-4379148 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191546 Forward-Port-Of: odoo/odoo#189967
Original PR description
For an expense report paid by an employee, the bank account set on the employee form should be used to create the Journal Entry and as a default bank account in Register Payment Wizard. task-4379148 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191546 Forward-Port-Of: odoo/odoo#189967
Fix blank screen when going on receipt screen. That was due to the creation of a new order on websocket messages. Forward-Port-Of: odoo/odoo#191526
Original PR description
Fix blank screen when going on receipt screen. That was due to the creation of a new order on websocket messages. Forward-Port-Of: odoo/odoo#191526
**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
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#76087 Forward-Port-Of: odoo/enterprise#75756
Issue: ------ When migrating a database having 'Documents' module installed and also having empty/blank spreadsheets created in version saas-17.2 or lower will lead to a JSON decoder error. This happens when the 'spreadsheet_data' value become an empty `b''` because of empty spreadsheets. Here : https://github.com/odoo/enterprise/blob/17.0/spreadsheet_edition/models/spreadsheet_mixin.py#L224 Solution: ----------- Passing an empty dictionay '{}' if it gets empty quotes as `b''` during pr
Original PR description
Issue: ------ When migrating a database having 'Documents' module installed and also having empty/blank spreadsheets created in version saas-17.2 or lower will lead to a JSON decoder error. This…
Issue:
------
When migrating a database having 'Documents' module installed and also having empty/blank spreadsheets created in version saas-17.2 or lower will lead to a JSON decoder error. This happens when the 'spreadsheet_data' value become an empty `b''` because of empty spreadsheets.
Here :
https://github.com/odoo/enterprise/blob/17.0/spreadsheet_edition/models/spreadsheet_mixin.py#L224
Solution:
-----------
Passing an empty dictionay '{}' if it gets empty quotes as `b''` during processing.
Steps to reproduce:
------------------------
1. Create a database in version 17.2 or lower and install Documents module.
2. Create empty/blank spreadsheets (we can manually upload an empty spreadsheet).
3. Migrate the database to version saas~17.4 or above.
4. Finally, during testcases one of the test case will fail. Because of empty quotes.
Traceback:
```
File "/home/odoo/src/enterprise/saas-17.4/spreadsheet_edition/models/spreadsheet_mixin.py", line 44, in _compute_current_revision_uuid
snapshot = spreadsheet._get_spreadsheet_snapshot()
File "/home/odoo/src/enterprise/saas-17.4/spreadsheet_edition/models/spreadsheet_mixin.py", line 234, in _get_spreadsheet_snapshot
return json.loads(self.spreadsheet_data)
File "/usr/lib/python3.10/json/__init__.py", line 346, in loads
return _default_decoder.decode(s)
File "/usr/lib/python3.10/json/decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib/python3.10/json/decoder.py", line 355, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
```
UPG - 2263261
TBG - 1416
Forward-Port-Of: odoo/enterprise#74685…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
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
2 changes
Resolved issues and error corrections
This update fixes an issue where the kitchen display incorrectly reduced quantities after a POS order change. Now, the system prioritizes quantity reductions based on the display line's current stage, ensuring accurate updates in the kitchen preparation view. This improves order fulfillment efficiency.
Original PR description
In a POS restaurant order, when reducing the product quantity of an order line, the reduced display line in the preparation display was always the first one created, regardless of which order line…
In a POS restaurant order, when reducing the product quantity of an order line, the reduced display line in the preparation display was always the first one created, regardless of which order line was changed. Steps to reproduce: 1. In the POS restaurant, add a product with a quantity of 2 and an internal note. Confirm the order. 2. Add another order with the same product and internal note but with a quantity of 5. 3. In the kitchen display, change the stage of the first display line (quantity 2) from "To Cook" to "Ready." 4. In the POS, reduce the quantity of the second order line (quantity 5) to 4. Issue: The system reduces the quantity of the first display line (the one in the "Ready" stage). Cause: In `_process_preparation_changes` of `pos_order.py` in the `pos_preparation_display` module, display lines are filtered and sorted based on their creation order. However, since there is no 1-to-1 relation between display lines and order lines, it is impossible to directly target specific display lines. Fix: After this commit, display lines are now sorted based on their stage. Priority for quantity reduction is given to the line in the earliest stage. opw-4354093
This update simplifies the process of generating credit notes (CN) and debit notes (DN) in Uruguay. By removing a previous requirement for accepted original documents, users can now create credit notes immediately after invoice errors, and generate CN/DNs even when the original invoice was created with different software. This streamlines workflows and reduces delays.
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