Daily updates from Odoo
Navigate
Branch
Wednesday, July 31, 2024
56 changes
2 changes
Miscellaneous changes
Before this commit, loading an attribute value with an image would cause a TypeError due to the image data being of bytes type, which is not JSON serializable. This commit prevents this error by removing the image data before serialization. opw-3957587 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167765
Original PR description
Before this commit, loading an attribute value with an image would cause a TypeError due to the image data being of bytes type, which is not JSON serializable. This commit prevents this error by removing the image data before serialization. opw-3957587 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167765
Before this commit, an error occurred in the following scenario: - Open Point of Sale and sell a product with lot tracking - Close/Post the Point of Sale session - Open the product record and disable tracking in the inventory tab - Start a new session, click on Orders and sort for Paid orders opw-3921893 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168078 Forward-Port-Of: odoo/odoo#166915
Original PR description
Before this commit, an error occurred in the following scenario: - Open Point of Sale and sell a product with lot tracking - Close/Post the Point of Sale session - Open the product record and disable tracking in the inventory tab - Start a new session, click on Orders and sort for Paid orders opw-3921893 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168078 Forward-Port-Of: odoo/odoo#166915
28 changes
Resolved issues and error corrections
Indian invoice previews now calculate the HSN Summary taxable value after applying line discounts. This prevents overstated taxable amounts in customer invoice documents and helps keep tax reporting figures accurate.
Original PR description
### Steps to reproduce: - Install l10n_in module and switch to an Indian company - Create a new customer invoice - Add a line with a discount - Click "Preview" - In the document under HSN Summary the "Taxable Value" does not take the discount into account ### Cause: To form the hsm_summary table, only the price_unit is given without taking the discount into account. ### Solution: Instead of giving the price_unit, we can calculate the price_unit with discount. opw-4045609
This fix ensures that when a service product is added to an already confirmed sales order, the related project receives the required analytic account for tracking costs and revenue. This prevents missing project financial tracking in cases where the original order only contained non-service products.
Original PR description
### Steps to reproduce: - Install Sale and Project modules - Create a Service product that creates a project when ordered - Create a SO with a non-service product and confirm it - Add a SOL with a…
### Steps to reproduce: - Install Sale and Project modules - Create a Service product that creates a project when ordered - Create a SO with a non-service product and confirm it - Add a SOL with a service product - Navigate to the created project settings and check AA ### Current behavior before PR: No AA is generated for the project when adding a SOL with a service product to a confirmed SO. This issue has been introduced after this commit https://github.com/odoo/odoo/pull/154934/commits/ffb3fe1b81a41b6462fd6eaae837f8e806da0d51 as it is now generating AA only when we confirm the SO 'action_confirm' so if you are confirming the SO with no service products it won't generate an AA so self.order_id.analytic_account_id will be false and when add a service product and preparing the values to create its project https://github.com/odoo/odoo/blob/saas-17.2/addons/sale_project/models/sale_order_line.py#L176 there will be no AA in SO ### Desired behavior after PR is merged: with reverting this diff https://github.com/odoo/odoo/pull/154934/commits/ffb3fe1b81a41b6462fd6eaae837f8e806da0d51#diff-54515e6934b8a75befb26b76cc09b04f898281f6fcfc3f32ac4b1afdd17004b2 we are no checking before creating the project if we have a service product in the SO and there is not AA already generated we will create it before creating the project. opw-4045976
India HSN summaries now use the discounted item price instead of the original unit price. This ensures tax and invoice summaries better match the actual amounts charged, including in point-of-sale orders.
Original PR description
*Before this commit:* - The HSN summary was calculated based on the unit price of the line items, even if a discount was applied. *After this commit:* - The HSN summary is now calculated based on the discounted price of the line items. opw: 4040478
Miscellaneous changes
Before this commit: Any printer connected to a windows IoT was always set to "network" connection type. Apart from wrong information on odoo's backend, it also create issues as the backend filter network printer with the same name to appear only once, see: https://github.com/odoo/enterprise/blob/221a94164b558bc997328331c48cbc1213b895d2/iot/controllers/main.py#L109-L112 So if 2 USB printer of the same model are plugged to 2 distinct windows IoT, only one of them would appear with no way to print
Original PR description
Before this commit: Any printer connected to a windows IoT was always set to "network" connection type. Apart from wrong information on odoo's backend, it also create issues as the backend filter network printer with the same name to appear only once, see: https://github.com/odoo/enterprise/blob/221a94164b558bc997328331c48cbc1213b895d2/iot/controllers/main.py#L109-L112 So if 2 USB printer of the same model are plugged to 2 distinct windows IoT, only one of them would appear with no way to print to the one missing (apart from renaming the printer to avoid printer name clash). After this commit: Determine the type of connection based on the printer port. Additionally, virtual printers (like "Microsoft Print to PDF") are now discarded to avoid triggering dialog boxes prompts which will block the printing operation process opw-3801703 Forward-Port-Of: odoo/odoo#174245
Task Adhoc side: 34375 Task Latam side: 1177 Modify "help" attribute of l10n_ar_special_purchase_document_type_ids (Other Purchase Documents) field on model res.partner to tell that it will be deprecated on next version. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162812
Original PR description
Task Adhoc side: 34375 Task Latam side: 1177 Modify "help" attribute of l10n_ar_special_purchase_document_type_ids (Other Purchase Documents) field on model res.partner to tell that it will be deprecated on next version. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162812
…ds) account move line text, based on pos orders **Description of the issue/feature this PR addresses:** During the close of the PoS session, account move are generated. the text of the lines depends on the sales (and refund). for the time being, some part of text are not translatable. **Current behavior before PR:**  **Desired behavior after PR is merged:** Text can be translated. + fre
Original PR description
…ds) account move line text, based on pos orders **Description of the issue/feature this PR addresses:** During the close of the PoS session, account move are generated. the text of the lines depends on the sales (and refund). for the time being, some part of text are not translatable. **Current behavior before PR:**  **Desired behavior after PR is merged:** Text can be translated. + french translation added. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174647 Forward-Port-Of: odoo/odoo#174511
Pension Fund tax was incorrectly applied at the invoice level instead of the line level. When importing it as a vendor bill, this caused incorrect amounts due to the tax being applied to all lines. This commit exports TipoDato = "AswCassPre" for lines with the pension fund applied. During XML import, it checks which lines should have the "pension fund" tax and applies it accordingly. task-3969730 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
Pension Fund tax was incorrectly applied at the invoice level instead of the line level. When importing it as a vendor bill, this caused incorrect amounts due to the tax being applied to all lines. This commit exports TipoDato = "AswCassPre" for lines with the pension fund applied. During XML import, it checks which lines should have the "pension fund" tax and applies it accordingly. task-3969730 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170012
This commit does three things: 1) Global Discounts: When creating an invoice with a negative line, such as a Tax Invoice with global discount, we process the line as a document level allowance as required by ZATCA, and remove it from the lines sent in the UBL. This allows us to provide support for global discounts, such as those applied by promotion programs 2) Add support for down-payment document type in _l10n_sa_get_invoice_type method: 386 3) Trim spaces from phone numbers b
Original PR description
This commit does three things: 1) Global Discounts: When creating an invoice with a negative line, such as a Tax Invoice with global discount, we process the line as a document level allowance as…
This commit does three things:
1) Global Discounts: When creating an invoice with a negative line, such as a Tax Invoice with global discount, we process the line as a document level allowance as required by ZATCA, and remove it from the lines sent in the UBL. This allows us to provide support for global discounts, such as those applied by promotion programs
2) Add support for down-payment document type in _l10n_sa_get_invoice_type method: 386
3) Trim spaces from phone numbers before submission to avoid receiving warnings from ZATCA
Description of the issue/feature this PR addresses:
Process global discounts into AllowanceCharge values for ZATCA saudi eInvoicing.
Avoid warnings regarding spaces in phone numbers.
Add support for down-payment invoice type code.
Current behavior before PR:
If a promotions program is applied on a sale order or POS order, or a line with a negative amount is added on an invoice, the line is sent as is to the authorities, which triggers an error as ZATCA only accepts positive amount lines.
If a phone number is provided, ZATCA returns a warning regarding the phone number format.
Desired behavior after PR is merged:
Negative lines on an invoice, that are not related to a down-payment, should be processed as document level allowances.
Phone numbers are correctly formatted prior to sending to ZATCA.
Down-payment invoices use the appropriate document type code.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#154608
Forward-Port-Of: odoo/odoo#153379Currently when importing an order from sale to pos, if the price was set manually, changing the partner associated with the order will set back the price to the original product sale price. Steps to reproduce: ------------------- * Make a new quotation in **sales** * Change the unit price of a product * Confirm quotation * Open the pos shop session * Import the newly created quotation to be settled * Change the partner > Observation: The price set manually changes to the product sale
Original PR description
Currently when importing an order from sale to pos, if the price was set manually, changing the partner associated with the order will set back the price to the original product sale price. Steps to…
Currently when importing an order from sale to pos, if the price was set manually, changing the partner associated with the order will set back the price to the original product sale price. Steps to reproduce: ------------------- * Make a new quotation in **sales** * Change the unit price of a product * Confirm quotation * Open the pos shop session * Import the newly created quotation to be settled * Change the partner > Observation: The price set manually changes to the product sale price Why the fix: ------------ When changing the partner of a sale order we compute all the line that have to recompute their prices: https://github.com/odoo/odoo/blob/57f1b0bd502938a6d50244896e71df73705584b5/addons/point_of_sale/static/src/js/models.js#L2918-L2920 We see that when we settle an order, `price_manually_set` is set to false. In this example, if we set it to true it would solve the issue but we cannot use it, see with https://github.com/odoo/odoo/commit/70668ee3c3e2c1dd213903b44f4d36cc8ac9fa29 . Instead what we can do is to use `price_automatically_set` and set it to true. This does not undo the previously mentionned commit and fixes this current issue. This variable was created in https://github.com/odoo/odoo/commit/067299539116b55a449f022706c395dda2177829 opw-4001497 Forward-Port-Of: odoo/odoo#174649 Forward-Port-Of: odoo/odoo#172205
`odoo` alias on IoTBox is meant to start Odoo with cli. It used to restart the service before starting by cli, causing a `address already in use` error. Replaced `restart` by `stop` to avoid restarting the service. Forward-Port-Of: odoo/odoo#174619
Original PR description
`odoo` alias on IoTBox is meant to start Odoo with cli. It used to restart the service before starting by cli, causing a `address already in use` error. Replaced `restart` by `stop` to avoid restarting the service. Forward-Port-Of: odoo/odoo#174619
This PR bugfix an error: "Error: Finalized Order cannot be modified" during a pos session. Steps to reproduce: 1. Install `pos_loyalty` module 2. Use any loyalty program (in video I used a gift card) on a pos order 3. Paid order but stay on "ReceiptScreen" 4. Click on "Orders" ("TicketButton") 5. Click on "New Order" 6. Click again on "Orders" and select paid order in status "Receipt" 7. "Error: Finalized Order cannot be modified" is shown Video of steps: https://www.loom.com/sha
Original PR description
This PR bugfix an error: "Error: Finalized Order cannot be modified" during a pos session.
Steps to reproduce:
1. Install `pos_loyalty` module
2. Use any loyalty program (in video I used a gift card) on a pos order
3. Paid order but stay on "ReceiptScreen"
4. Click on "Orders" ("TicketButton")
5. Click on "New Order"
6. Click again on "Orders" and select paid order in status "Receipt"
7. "Error: Finalized Order cannot be modified" is shown
Video of steps: https://www.loom.com/share/6ea8c86ebd994ce0958f42b6eb12c5db
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#172582
Forward-Port-Of: odoo/odoo#168142In this commit https://github.com/odoo/odoo/pull/157503/commits/98368c363bf4cb9604948a52196c6a61985dc34d we added the bank account (if present) next to the communication printed on the invoice. This commit apply the same logic to the "send and print" template task: 4048178 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174549 Forward-Port-Of: odoo/odoo#172775
Original PR description
In this commit https://github.com/odoo/odoo/pull/157503/commits/98368c363bf4cb9604948a52196c6a61985dc34d we added the bank account (if present) next to the communication printed on the invoice. This commit apply the same logic to the "send and print" template task: 4048178 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174549 Forward-Port-Of: odoo/odoo#172775
Currently the logs are being spammed with warning messages which shouldn't be warnings as it's a normal behavior 1) When no database is connected we log "warning invalid ssl certificate" 2) When no database is connected we log "warning odoo server not set" I log both as info level to still keep this information but avoid spamming useful error logs with it Forward-Port-Of: odoo/odoo#174702
Original PR description
Currently the logs are being spammed with warning messages which shouldn't be warnings as it's a normal behavior 1) When no database is connected we log "warning invalid ssl certificate" 2) When no database is connected we log "warning odoo server not set" I log both as info level to still keep this information but avoid spamming useful error logs with it Forward-Port-Of: odoo/odoo#174702
**Steps to reproduce:** - Install l10n_ar and website_sale - Switch to an Argentinian company - Create a product with a customer tax (e.g. IVA 21%) With a public user or a user without "AFIP Responsibility": - Go to eShop and add the created product to the cart - Go to the cart **Issue:** No tax is applied. **Cause:** There are some fiscal positions from Argentinian localization that map IVA 21% to IVA Exento (i.e. 0%). These fiscal positions are linked to specific "AFIP Respons
Original PR description
**Steps to reproduce:** - Install l10n_ar and website_sale - Switch to an Argentinian company - Create a product with a customer tax (e.g. IVA 21%) With a public user or a user without "AFIP…
**Steps to reproduce:** - Install l10n_ar and website_sale - Switch to an Argentinian company - Create a product with a customer tax (e.g. IVA 21%) With a public user or a user without "AFIP Responsibility": - Go to eShop and add the created product to the cart - Go to the cart **Issue:** No tax is applied. **Cause:** There are some fiscal positions from Argentinian localization that map IVA 21% to IVA Exento (i.e. 0%). These fiscal positions are linked to specific "AFIP Responsibility" types and should only be applied for users having these "AFIP Responsibility" types configured on their contact form. However, when this field is not set, it is ignored in the domain computing the fiscal position and one of these Argentinian fiscal positions satisfies the resulting domain. **Solution:** Filter on "AFIP Responsibility" in the domain computing the fiscal position if "l10n_ar_afip_responsibility_type_id" key is present in the context, no matter what its value. opw-3943108 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171923
Specification: The ribbon overlaps with the dropdown menu.  Expected behavior: The ribbon should not overlap with the dropdown menu. Task-3940927 Forward-Port-Of: odoo/odoo#172102
Original PR description
Specification: The ribbon overlaps with the dropdown menu.  Expected behavior: The ribbon should not overlap with the dropdown menu. Task-3940927 Forward-Port-Of: odoo/odoo#172102
Steps to reproduce: - Create a product with MTO & Buy routes. - Define a vendor for the product. - Create a sale order for this product. - Go to the related purchase order and confirm it. - Decrease the quantity of the PO line. - Go to the related receipt picking. (Do the above steps or any action that leads to logging an activity that has links to records). Expected behavior: Clicking on the record names in the logged exception redirects to these records. Current behavior: Not
Original PR description
Steps to reproduce: - Create a product with MTO & Buy routes. - Define a vendor for the product. - Create a sale order for this product. - Go to the related purchase order and confirm it. - Decrease the quantity of the PO line. - Go to the related receipt picking. (Do the above steps or any action that leads to logging an activity that has links to records). Expected behavior: Clicking on the record names in the logged exception redirects to these records. Current behavior: Nothing happens. opw-4045174 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174907 Forward-Port-Of: odoo/odoo#174497
In this PR: https://github.com/odoo/odoo/pull/172760 the check_vat_il function is calling `self.company`. It appears it was not a good idea and several things were not done well: - It could lead to errors as run_vat_test can be called on multiple partners: https://github.com/odoo/odoo/blob/16.0/addons/base_vat/models/res_partner.py#L170. - The previous PR is also checking the VAT number depending on the field is_company but did not put it as a constraint. This can be fixed, but with more ch
Original PR description
In this PR: https://github.com/odoo/odoo/pull/172760 the check_vat_il function is calling `self.company`. It appears it was not a good idea and several things were not done well: - It could lead to errors as run_vat_test can be called on multiple partners: https://github.com/odoo/odoo/blob/16.0/addons/base_vat/models/res_partner.py#L170. - The previous PR is also checking the VAT number depending on the field is_company but did not put it as a constraint. This can be fixed, but with more changes than needed. It has been decided to use the `idnr` check for all Israeli VAT numbers, regardless of the partner type. With this change the VAT check for companies is not complete: it is not tested that they begin by a 5. But it is good enough. opw-3954674 Forward-Port-Of: odoo/odoo#174817
This commit modifies the AddInternalNotes tour method to support empty internal note. Related enterprise PR: https://github.com/odoo/enterprise/pull/66145 sentry-5494183916 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174107 Forward-Port-Of: odoo/odoo#172730
Original PR description
This commit modifies the AddInternalNotes tour method to support empty internal note. Related enterprise PR: https://github.com/odoo/enterprise/pull/66145 sentry-5494183916 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174107 Forward-Port-Of: odoo/odoo#172730
Since we are using an existing record as `mail_message_id` in `_notify_thread_by_email`, and we need to allow the creation of new `mail.mail` that will add new values to the `mail.message`, as long as it doesn't modify existing values. We are already writing on `subject` only if it was different than previously, but we are not forbidding to write on it only if there was a previous value set. Forward-Port-Of: odoo/odoo#173366
Original PR description
Since we are using an existing record as `mail_message_id` in `_notify_thread_by_email`, and we need to allow the creation of new `mail.mail` that will add new values to the `mail.message`, as long as it doesn't modify existing values. We are already writing on `subject` only if it was different than previously, but we are not forbidding to write on it only if there was a previous value set. Forward-Port-Of: odoo/odoo#173366
Problem: For a gift card with 0 points which have its price changed a popup error is displayed saying the gift card has already been sold Steps to reproduce: - Install "point_of_sale" app and "pos_loyalty" module - Select "Scan existing cards" in the promotions settings - Generate a gift card with a value of 0.00 $ and copy its code - Start a shop session - Select the gift card product and enter the code - Change the price of the gift card (must be an integer < 10) - Proceed to the pa
Original PR description
Problem: For a gift card with 0 points which have its price changed a popup error is displayed saying the gift card has already been sold Steps to reproduce: - Install "point_of_sale" app and…
Problem: For a gift card with 0 points which have its price changed a popup error is displayed saying the gift card has already been sold Steps to reproduce: - Install "point_of_sale" app and "pos_loyalty" module - Select "Scan existing cards" in the promotions settings - Generate a gift card with a value of 0.00 $ and copy its code - Start a shop session - Select the gift card product and enter the code - Change the price of the gift card (must be an integer < 10) - Proceed to the payment - See the popup error Cause: As the gift card has no points, `couponPointChanges` stays empty. But when the price is modified, `couponPointChanges` is updated but has no giftCardId so the error is triggered (see `validateOrder` in PaymentScreen.js). There is no issue if the price is > 10 or is not an integer because `_updatePrograms` is called after each click on the numpad and `changesPerProgram` gets the values of `couponPointChanges` which are the saved in `oldChanges` which is modified by getting the values of `pointsAdded` which has `giftCardId` so `couponPointChanges` get the `giftCardId` opw-3909019 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174982 Forward-Port-Of: odoo/odoo#174538
When exporting fec file, data from child companies should be included in the file. opw-4014583 Forward-Port-Of: odoo/odoo#174572
Original PR description
When exporting fec file, data from child companies should be included in the file. opw-4014583 Forward-Port-Of: odoo/odoo#174572
Prior to this commit, performing a search in the PoS and selecting "Search more" would load products not belonging to the restricted categories. opw-4061359 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174729 Forward-Port-Of: odoo/odoo#173885
Original PR description
Prior to this commit, performing a search in the PoS and selecting "Search more" would load products not belonging to the restricted categories. opw-4061359 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174729 Forward-Port-Of: odoo/odoo#173885
In list views, the label of a field, displayed in the thead, is sometimes truncated (especially as we apply our own column widths logic). Moreover, fields might sometimes be unclear to the user, and in the list view we don't benefit from the "help" that might be defined on the field. This commit helps with those two issues. In non debug mode, there's now a tooltip on the field's label. This tooltip contains the (never truncated) label and the help when there's one. Note that in debug, noth
Original PR description
In list views, the label of a field, displayed in the thead, is sometimes truncated (especially as we apply our own column widths logic). Moreover, fields might sometimes be unclear to the user, and in the list view we don't benefit from the "help" that might be defined on the field. This commit helps with those two issues. In non debug mode, there's now a tooltip on the field's label. This tooltip contains the (never truncated) label and the help when there's one. Note that in debug, nothing changes: we still display a big tooltip with a lot more information. task 4049882 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#175020 Forward-Port-Of: odoo/odoo#173178
When a tax ID is displayed on a report, pingen is failing because the tax ID is rendered in pingen's postable area. This commit adds a margin after the address to ensure nothing disturbs the address area for pingen. Target 17 -> 17.4, to be adapted for master in https://github.com/odoo/odoo/pull/174635 . task-4080193 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174830
Original PR description
When a tax ID is displayed on a report, pingen is failing because the tax ID is rendered in pingen's postable area. This commit adds a margin after the address to ensure nothing disturbs the address area for pingen. Target 17 -> 17.4, to be adapted for master in https://github.com/odoo/odoo/pull/174635 . task-4080193 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174830
Currently, when buying a gift card through the website and choosing the options to pick up in store and pay in store, the quantity set when settling the order is zero. Steps to reproduce (initial): ----------------------------- * Go to the **website** app * Select **configuration** > **Payment Providers** * Make sure `Pay in store` is published and enabled/or in test mode * Select **configuration** > **Shipping methods** * Make sure that a shipping method `Pick in store` is set up and p
Original PR description
Currently, when buying a gift card through the website and choosing the options to pick up in store and pay in store, the quantity set when settling the order is zero. Steps to reproduce (initial):…
Currently, when buying a gift card through the website and choosing the options to pick up in store and pay in store, the quantity set when settling the order is zero. Steps to reproduce (initial): ----------------------------- * Go to the **website** app * Select **configuration** > **Payment Providers** * Make sure `Pay in store` is published and enabled/or in test mode * Select **configuration** > **Shipping methods** * Make sure that a shipping method `Pick in store` is set up and published for your shop * Now make an order on the website for a gift card and any storable product * Choose the options to pick and pay in store * Go to the **Point of sale** app * Open shop session * Settle the order just created > Observation: The quantity for the gift card is 0 Steps to reproduce (alternative): --------------------------------- * Go to **Sale** App * Create a quotation for a gift card and any storable product * Save the quotation (not confirm) * Go to the **Point of sale** app * Open shop session * Settle the order just created Why the fix: ------------ The issue is not specific to the gift card product, it affects all `'service'` products. https://github.com/odoo/odoo/blob/7be2770f2a8dc26f7aa0c539b878b258e94592c8/addons/pos_sale/static/src/js/models.js#L85-L91 We notice that, if the order was paid instead of choosing the option to pay in store, the quantity on the pos order when settling it is 1. This is because the order not yet paid is still considered as a quotation. While if it is paid through the website it is considered as a sale order and thus `qty_to_invoice` has been computed. The same behaviors can be replicated through the **Sale** app. If a quotation is only saved we also have a quantity of 0. If it is confirmed, the quantity is 1. As discussed with DALA, using `qty_to_invoice` to set up the quantity in POS only makes sense when we deal with sale orders. When dealing with quotations we should set the quantities in the shop order depending on the quantities of the quotation. opw-4003749 Forward-Port-Of: odoo/odoo#175000 Forward-Port-Of: odoo/odoo#173146
Steps to reproduce: - Set delivery in 2 steps - Create a sales - Validate the transfer from Stock to Output. The delivery status changes from "not delivered" to "partially delivered" even though nothing has been delivered to the customer. After the fix: If a picking is validated but nothing was delivered to the customer yet, the delivery status is set to "Started". OPW-3948025 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-
Original PR description
Steps to reproduce: - Set delivery in 2 steps - Create a sales - Validate the transfer from Stock to Output. The delivery status changes from "not delivered" to "partially delivered" even though nothing has been delivered to the customer. After the fix: If a picking is validated but nothing was delivered to the customer yet, the delivery status is set to "Started". OPW-3948025 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174986 Forward-Port-Of: odoo/odoo#169194
Steps to reproduce ================== In 17.2: - Install calendar,hr_homeworking - Use the emulated mobile view from the devtools - Go to calendar - Swipe horizontally to change the displayed week => A crash occurs here https://github.com/odoo/odoo/blob/saas-17.2/addons/hr_homeworking/static/src/calendar/common/calendar_common_renderer.js#L108 Cause of the issue ================== The `AttendeeCalendarCommonRenderer` is rendered before the data for the next week has been loa
Original PR description
Steps to reproduce ================== In 17.2: - Install calendar,hr_homeworking - Use the emulated mobile view from the devtools - Go to calendar - Swipe horizontally to change the displayed week => A crash occurs here https://github.com/odoo/odoo/blob/saas-17.2/addons/hr_homeworking/static/src/calendar/common/calendar_common_renderer.js#L108 Cause of the issue ================== The `AttendeeCalendarCommonRenderer` is rendered before the data for the next week has been loaded. This means that `this.props.model.worklocations` has no entry for the `parsedDate`. Solution ======== Await the action before modifying the ActionSwiper state opw-4047632 Forward-Port-Of: odoo/odoo#174825 Forward-Port-Of: odoo/odoo#173305
If there is a user that sends and/or receives lots of Peppol messages, we send a request to fetch documents/messages for all of them at once. This can result in low performance or memory errors. It is better to batch messages into a reasonable number of messages. no task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175057 Forward-Port-Of: odoo/odoo#175003
Original PR description
If there is a user that sends and/or receives lots of Peppol messages, we send a request to fetch documents/messages for all of them at once. This can result in low performance or memory errors. It is better to batch messages into a reasonable number of messages. no task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175057 Forward-Port-Of: odoo/odoo#175003
15 changes
Enhancements to existing features
Subscription tax estimates now use the current date instead of the original order date when checking taxes with Avalara. This helps portal totals reflect current tax rules or exemption changes, so customers see amounts closer to what they will actually be charged.
Original PR description
By default, we send date_order to Avatax when asking to calculate taxes. Avatax calculates the right taxes for that point in time. For non-recurring orders this is ok, but subscriptions are paid multiple times and date_order will remain the confirmation date of the subscription. This leads to confusion as taxes change over time (e.g. tax laws change or an exemption certificate is added with an effective date after date_order). Because customers are charged based on invoices we always charge them correctly, but the subscription total may not match what they're being charged. To solve this, always send the current date for subscriptions. This way customers can accurately see what they'll be charged in the portal. task-4078473
This update prevents certain background notifications from being triggered multiple times after a reset, reducing unnecessary processing. It helps improve reliability and efficiency across messaging, spreadsheet documents, live chat helpdesk, and WhatsApp-related flows without changing user-facing features.
Original PR description
\* = documents_spreadsheet, whatsapp Enterprise counter-part. After a reset, the last id is always 0. https://github.com/odoo/odoo/pull/174874
Payment method configuration now uses a clearer “none” value for refund support instead of the confusing “empty” label. This makes refund capabilities easier for users and administrators to understand when configuring online sales payments.
Original PR description
-> This commit improves the clarity and usability of the payment method configurations, specifically focusing on refund options. Before this commit: -> The type of refund supported was 'empty' which led to confusion. After this commit: -> Replace the support_refund field to 'none' from 'empty' which make more intuitive for users. Check the community PR for more details. task-3974054 See also: - https://github.com/odoo/odoo/pull/169473 - https://github.com/odoo/upgrade/pull/6162
Knowledge hierarchy views are now loaded only when needed, reducing initial loading work. This should make the Knowledge app feel more responsive while preserving the same user-facing functionality.
Original PR description
We make the hierarchy view and its extensions to be lazy loaded. Task ID: `3546321`
The Discuss app now shows who is currently in an active call directly in the sidebar, including each participant's call status such as speaking, muted, or deafened. This makes it easier for users to understand call activity at a glance without opening additional views.
Original PR description
This commit provides the Call Participants in the sidebar of the Discuss app. When a call is active, the sidebar will show the participants of the call, as well as the status of the participants (e.g. isTalking, isMuted, isDeafened). https://github.com/odoo/odoo/pull/174965
Point of Sale users now receive a confirmation when WhatsApp or email marketing actions are successfully sent. They can also launch standalone marketing directly from a PoS order, making customer outreach clearer and easier to manage.
Original PR description
Before this commit: ========== - There is no confirmation notification while using WhatsApp and Email marketing. - Also, there is no option for standalone marketing from the PoS order form view. After this commit: ========== - Confirmation notification appears after successfully triggering WhatsApp and Email marketing. - Now, we have an option for standalone marketing from the PoS order form view. task-4037963
Resolved issues and error corrections
A recent merge introduced a conflict that prevented the tax report from opening. This fix removes the outdated logic and calculates the taxable amount directly, restoring access for users who rely on tax reporting.
Original PR description
Two commit have been merged together causing a conflict on a function not present anymore `_prepare_dict_for_taxes_computation`. The fix is to remove that old function and compute the tax applied amount directly conflicting pr's: - https://github.com/odoo/enterprise/commit/29e30f5d941f2c9989833237dd7aade29e00a4c2 - https://github.com/odoo/odoo/commit/cd76aec1f722d32d2bc6c1a13ef73296ce00ecc5 task-4086928
This fixes an internal guided tour used in the Documents Accounting area after a related setting name changed. It helps keep automated checks and user guidance reliable, reducing the chance of broken onboarding or validation issues.
Original PR description
From https://github.com/odoo/odoo/pull/174548, tooltip has been renamed in tooltipPosition. This conversion for this tour has been missed. In https://github.com/odoo/odoo/pull/171756, the step schema is validated when a tour is added to the registry. This is why this bug was detected. task~3974087
Miscellaneous changes
## Before this commit: The schedule date is converted into a string in SQL and then parsed in Python using `Datetime.to_string`. However, it does not support parsing datetime with trailing milliseconds, such as '2024-05-22 10:09:45.5'. ## After this commit: Do not convert the schedule date to a string but put it in a PostgreSQL Array instead. Psycopg2 will convert it into a datetime object automatically, similar to the ORM's behaviour. opw-3932891 Forward-Port-Of: odoo/enterprise#67593
Original PR description
## Before this commit: The schedule date is converted into a string in SQL and then parsed in Python using `Datetime.to_string`. However, it does not support parsing datetime with trailing milliseconds, such as '2024-05-22 10:09:45.5'. ## After this commit: Do not convert the schedule date to a string but put it in a PostgreSQL Array instead. Psycopg2 will convert it into a datetime object automatically, similar to the ORM's behaviour. opw-3932891 Forward-Port-Of: odoo/enterprise#67593 Forward-Port-Of: odoo/enterprise#63065
When switching a bank journal to the new SEPA Pain version, existing payments in the batch may lack required data, such as the UETR field. ### Steps to Reproduce 1. Install `l10n_be`, `account_accountant`, and `account_sepa_pain_001_001_09`. 2. In the settings, enable 'SEPA Credit Transfer (SCT)'. 3. Switch to a Belgian company. 4. Set up an IBAN bank account on the bank journal. 5. Ensure a partner has an IBAN bank account defined. 6. Create and confirm an outgoing payment for that p
Original PR description
When switching a bank journal to the new SEPA Pain version, existing payments in the batch may lack required data, such as the UETR field. ### Steps to Reproduce 1. Install `l10n_be`,…
When switching a bank journal to the new SEPA Pain version, existing payments in the batch may lack required data, such as the UETR field. ### Steps to Reproduce 1. Install `l10n_be`, `account_accountant`, and `account_sepa_pain_001_001_09`. 2. In the settings, enable 'SEPA Credit Transfer (SCT)'. 3. Switch to a Belgian company. 4. Set up an IBAN bank account on the bank journal. 5. Ensure a partner has an IBAN bank account defined. 6. Create and confirm an outgoing payment for that partner, setting the payment method to 'SEPA Credit Transfer'. 7. In the Outgoing Payments tab of the bank journal, set the SEPA Pain Version to 'New generic version'. 8. Create a batch payment with the payment you just created. 9. Attempt to validate it. ### Expected Result The payment should be validated successfully. ### Actual Result A traceback occurs: `TypeError: Argument must be bytes or unicode, got 'bool'` ### Cause The payment in the batch was created before the SEPA PAIN version was updated on the bank journal. Consequently, the payment is missing some necessary data (specifically, the UETR field is not set) required for the new SEPA version. opw-3973374 Forward-Port-Of: odoo/enterprise#67665 Forward-Port-Of: odoo/enterprise#65614
When having multiple companies selected and that their tax id are not the same, then we put a banner on top of the tax report to warn the user that the companies selected don't have the same tax id. task: 3909005 Forward-Port-Of: odoo/enterprise#67576 Forward-Port-Of: odoo/enterprise#63275
Original PR description
When having multiple companies selected and that their tax id are not the same, then we put a banner on top of the tax report to warn the user that the companies selected don't have the same tax id. task: 3909005 Forward-Port-Of: odoo/enterprise#67576 Forward-Port-Of: odoo/enterprise#63275
The amount to settle was not shown in the tree view for the older column due to the [domain prepared](https://github.com/odoo/enterprise/blob/17.0/account_reports/models/account_aged_partner_balance.py#L380-L392) for the older column being capped between 30 days, similar to the other columns(1-30, 31-60, etc.) in the Aged Receivable report. **Step to reproduce:** - create an invoice with due date 150 days back - open the Aged receivable report and find that invoice - The record of `acco
Original PR description
The amount to settle was not shown in the tree view for the older column due to the [domain…
The amount to settle was not shown in the tree view for the older column due to the [domain prepared](https://github.com/odoo/enterprise/blob/17.0/account_reports/models/account_aged_partner_balance.py#L380-L392) for the older column being capped between 30 days, similar to the other columns(1-30, 31-60, etc.) in the Aged Receivable report. **Step to reproduce:** - create an invoice with due date 150 days back - open the Aged receivable report and find that invoice - The record of `account.move.line` will not be shown in the tree view (Amount to settle) This patch handle the domain for `period5`. **Before fix:**   **After fix:**  OPW - 4048535 Forward-Port-Of: odoo/enterprise#66884
Before this commit, the 'no content' message was showing in the entire display, taking the employee panel account. Now, it is fixed, the message just stay at the disabled workorders, and when the screen is less than md, the message is hidded. Previous PR: https://github.com/odoo/enterprise/pull/62997 ### Before  ### After  ### After  task: 3794286 Forward-Port-Of: odoo/enterprise#64435
Before this commit, when posting a manually modified closing entry, the entire move would be refreshed, and all user-modified information would be erased. This occurred because, when accessing the action_periodic_vat_entries, the current tax closing move was overwritten. This commit changes this behavior by adding a flag to the method, indicating whether it is called from the _close_tax_period function. If so, it only updates moves that are different from the tax closing of the current compan
Original PR description
Before this commit, when posting a manually modified closing entry, the entire move would be refreshed, and all user-modified information would be erased. This occurred because, when accessing the action_periodic_vat_entries, the current tax closing move was overwritten. This commit changes this behavior by adding a flag to the method, indicating whether it is called from the _close_tax_period function. If so, it only updates moves that are different from the tax closing of the current company. Additionally, when selecting only one company within a tax unit, it sometimes happened that, when closing the main company, the dependent closings to post (depending_closings_to_post) were empty because the moves were not generated yet for the other companies. Task: 3987807 Forward-Port-Of: odoo/enterprise#67299 Forward-Port-Of: odoo/enterprise#65645
**[FIX] stock_barcode_picking_batch: scan lots with multiple pickings** > How to reproduce: > - Create a product tracked by lots and set a barcode for this product; > - Create a receipt for this product, with at least 2 quantities and confirm it; > - Create a second similar receipt (you can duplicate the first one) and confirm it; > - Add these two receipt in a new batch and confirm the batch; > - Go in the Barcode App and open the batch, you should have two lines, one for each picking; >
Original PR description
**[FIX] stock_barcode_picking_batch: scan lots with multiple pickings** > How to reproduce: > - Create a product tracked by lots and set a barcode for this product; > - Create a receipt for this…
**[FIX] stock_barcode_picking_batch: scan lots with multiple pickings** > How to reproduce: > - Create a product tracked by lots and set a barcode for this product; > - Create a receipt for this product, with at least 2 quantities and confirm it; > - Create a second similar receipt (you can duplicate the first one) and confirm it; > - Add these two receipt in a new batch and confirm the batch; > - Go in the Barcode App and open the batch, you should have two lines, one for each picking; > - Scan the product -> the first line should be selected; > - Scan a lot -> the lot is set on the first line and its qty is incremented; > - Scan another lot -> the lot is set on the second line and its qty is incremented. That's the issue. > > Expected behavior: When another lot is scanned after the first one, since we are picking quantity for the first picking, the line for the second picking shouldn't be selected until the first one is processed. To fix that, the search for a line following the scan will avoid to take a tracked line if its `picking_id` is not the same than the selected line and if the selected line is not completed. **[FIX] stock_barcode: increment right qty** > When a product tracked by lots is reserved and multiple lots are reserved, in the Barcode App, each line has a "+ qty" button where the quantity is the remaining quantity. That said, this remaining quantity was always computed regarding the difference between the move line's done and reserved quantity which means if the user scans a not reserved lot, those buttons aren't reliable anymore. > > How to reproduce: > - Create a product tracked by lots and set a barcode; > - Update the quantity on hand for this product like following: > - 3x lot1 > - 3x lot2 > - 3x lot3 > - Create a delivery for 6x this product and confirm it; > - Open the delivery in the Barcode App, unfold the line for the tracked product, you should have: > - 0/3 lot1, [+3] > - 0/3 lot2, [+3] > - Scan lot1 one time and lot3 three times, you now have: > - 3 lot3, [+1] > - 1/3 lot1, [+2] > - 0/3 lot2, [+3] > -> Since the total demand is 6 and 4 quantities have been processed, no button should display a quantity greater than 2 since it's the remaining quantity. > > To fix that, the quantity used by the increment button is also computed regarding the parent line's quantity. task-3688770 Forward-Port-Of: odoo/enterprise#67479 Forward-Port-Of: odoo/enterprise#54589
11 changes
New functionality added to Odoo
A new electronic invoicing module for Uruguay (l10n_uy_edi) has been added to Odoo Enterprise. This module enables electronic document submission and management for Uruguayan businesses, including support for invoices, currency handling, and compliance with local tax requirements. This expansion allows Odoo to better serve customers operating in Uruguay.
Original PR description
LATAM TASK 1105 ADHOc TASK 34125
Resolved issues and error corrections
This update fixes how Spanish tax reports (libros XLSX) handle pro rata taxes, which are used when companies have mixed deductible and non-deductible VAT activities. The system now correctly calculates deductible tax amounts by only including taxes that have been assigned to a tax grid, rather than including the full tax amount. This ensures accurate tax reporting for Spanish businesses using pro rata tax systems.
Original PR description
This commit implements the functionality to support exporting libros XLSX with some line using a tax of type Prorrata. Prorrata is a fiscal system here in Spain, in which companies who have…
This commit implements the functionality to support exporting libros XLSX with some line using a tax of type Prorrata. Prorrata is a fiscal system here in Spain, in which companies who have activities where they can deduct IVA, and activities where they don´t have that right, the fiscal Agency gives you a formula you can use to simplify the process, and deduct the percentage you get from that formula from the IVA amount of an invoice. For example, on an invoice with tax 21% IVA, from that amount we can apply the prorrata percentage, and get a deductable and non deductable amount. The deductable amount should go to the normal IVA account, and the non deductable should go to the same account as the tax base. To simulate Prorrata tax in Odoo, we can create a new tax with only partial of the tax percentage is applied an account, tax grid, and checked in 'use in tax closing'. When we create invoice/bill with this tax, only those partial amount should be included in the tax_deductible field of the libros XLSX. Before this commit: tax_deductible amount include the full tax amount. After this commit: tax_deductible amount only include the tax amount if the line have a tax grid. task-id: 3955233
This fix resolves a crash that occurred in the Report Editor when users repeatedly reset reports. The issue happened because the system was trying to update the report display before it was fully loaded. The fix ensures the report is completely loaded before attempting to refresh it, preventing the application from crashing.
Original PR description
Steps to reproduce ================== - Go to Accounting > Customer Invoices - Open studio - Switch to the Reports tab - Open the Invoices report - Click on "Reset Report" a few times => Eventually, OdooEditor will crash with an error like `Cannot read properties of undefined (reading 'innerHTML')` Cause of the issue ================== `onIframeLoaded` was called before the default report has been loaded. Solution ======== only update the render key after the report has been reset opw-3821992
This update resolves critical errors that occurred when creating or editing appointment events with missing start dates or when start and end times were identical. Users will no longer experience system crashes when managing appointments with these edge cases, making the appointment scheduling feature more reliable and user-friendly.
Original PR description
ISSUE 1 ======= **Steps to reproduce** 1). Create an event in any appointment type 2). Remove the start date from it -> Traceback occurs **video ref** - https://youtu.be/5NpfiKNdjbc **Technical** in the interval_from_events function when the end time or start time is not defined, it will not be able to unpack the values to their appropriate variables, due to this error occurred. ISSUE 2 ======= **How to reproduce** Step 1) Create an event on resources and set the start time = end time Step 2) Click on the edit button -> Traceback video ref - https://youtu.be/csFkJjO6hMQ **Technical** When we set the start = stop then we won't be able to find the interval so we failed to assign the value of the field due to this traceback occurs. **After this PR** Now traceback will not occur. Task-4010880
This fix resolves an issue where recurring invoices created for subscriptions in company branches were left in draft status due to a mismatch between the invoice company and the deferred accounting entries. The fix ensures that when the automated recurring invoice generation runs, all related accounting records are properly aligned with the correct company, allowing invoices to be successfully created and processed.
Original PR description
Steps to reproduce: - Install Subscriptions - Create a new branch for your main company - Switch to that branch and create a subscription - On the "Company" field set it to the branch - Add a subscription with the new product - Confirm it - Switch to the main company and untick the branch - Schedule action -> "Sale Subscription: generate recurring invoices and payments" - Run it Issues: A traceback is shown in the logs, an invoice is created but left on draft. This is because the deferred moves created is with the main company while the invoice is set to the branch which causes a mismatch. opw-3879384
This fix resolves an issue where the time portion of datetime fields wasn't properly hiding when toggling the "Show time" option in Studio's visual editor. Users can now drag and drop datetime fields into list views and toggle the time display without needing to reset the widget, providing a smoother field customization experience.
Original PR description
After making changes in community PR: https://github.com/odoo/odoo/pull/161705 The datetime widget was not being applied when we dragged and dropped a datetime field from the studio. Steps to reproduce: - Open the Sales module and toggle Studio. - Drag and drop a datetime field into the list view. - Try to tick and untick the Show time option. Observed behavior: When ticking and unticking the show time option, the time part is not hiding before resetting the widget. Expected behavior: The time part should be hidden when we tick and untick the show time option without resetting the widget. After this commit, the datetime widget will be applied when we drag and drop a datetime field from the studio and untick the show time boolean. Task-3698841
Fixed an issue where WhatsApp message templates were not displaying their quality scores when synced from Meta. Previously, all templates defaulted to 'none' quality status. Now when templates are synced, the system properly retrieves and displays the actual quality score assigned by Meta, giving users accurate information about template performance.
Original PR description
Problem: The quality_score field is not received in the response while syncing all the templates. As a result, the default 'none' quality will be applied to all the templates. And the same goes while syncing a single template. It will only be updated when Meta posts a request on the webhook to update the template quality. Solution: The quality_score field can only be received if we explicitly ask for the quality_score field in an API request, But the problem is that only the quality_score field will be received here. Due to this, the API request to sync a single template and multiple templates are modified, and all the basic fields like name, components, language, status, category, and ID are included along with the quality_score field so we receive all basic fields and quality_score field. Task-3908894
This fix resolves a crash that occurred when users tried to add new fields in the Studio form editor for certain views. The issue happened when a form had fields organized in a group without an outer group structure. The fix improves how the system identifies field locations, preventing the "Xpath resolved to nothing" error and allowing users to successfully add fields in these scenarios.
Original PR description
Steps to reproduce ================== - Install account_accountant,web_studio - Go to Accounting > Configuration > Account Groups - Open studio - Switch to the form view - Show invisible elements -…
Steps to reproduce
==================
- Install account_accountant,web_studio
- Go to Accounting > Configuration > Account Groups
- Open studio
- Switch to the form view
- Show invisible elements
- Add a new field before the invisible Company field
=> Error: Xpath resolved to nothing or multiple nodes
Cause of the issue
==================
The xpath props of the StudioHook is the string "null"
The fields of this view are defined inside an InnerGroup but there is no OuterGroup.
```xml
<form><sheet>
<group>
<field .../>
...
</group>
</sheet></form>
```
In the form compiler, when a group does not contain another group, it is an InnerGroup
The form editor compiler uses some `interestingSelector` to compute xpaths.
It assumed that an InnerGroup was always inside an OuterGroup
Solution
========
Since the `:has` selector has not been widely supported for long enough,
we do the equivalent of `:not(field) group:not(:has(> group)) > *` in
javascript to match any group that has no direct group as a child.
opw-4046558Fixed a bug that caused an error when users tried to submit a WhatsApp message template for approval without selecting a category. Previously, the system would crash with a technical error. Now it properly validates the required category field and shows a clear error message if it's missing.
Original PR description
When attempting to create a new template in WhatsApp, leaving the ``Category`` field empty results in an error. Steps to reproduce: - Install the ``WhatsApp`` module - Create a ``WhatsApp Business Account`` - Create a new template and leave the ``Category`` field empty - Click on ``Submit for Approval`` Traceback: ``AttributeError: 'bool' object has no attribute 'upper'`` This error occurs at [1] because ``template_type`` is not found in self. This commit will fix the above error by raising an error if ``template_type`` is not found in self. [1]- https://github.com/odoo/enterprise/blob/d6e3dcc5a37c82a0c1bfc1267c4e088aedfe8632/whatsapp/models/whatsapp_template.py#L512 sentry-5642705166
This fix resolves a system crash that occurred when trying to validate a delivery with a product line that had been reduced to zero quantity. The issue happened because the system attempted to calculate an average product value by dividing by zero, which is mathematically impossible. Now the delivery validation process handles zero-quantity items correctly without crashing.
Original PR description
Steps to reproduce the bug:
- Set up the sendcloud shipping method
- Create two a storable product “P1” and “P2”
- Create a sale order:
- 1 unit of P1 and P2
- add a shipping method: sendcloud
- Confirm the SO > result: a delivery is created
- Update the qty to 0 units of P2
- Go to the delivery and try to validate it
Problem:
A traceback is triggered:
```
File "/home/odoo/src/enterprise/delivery_sendcloud/models/sendcloud_service.py", line 535, in _get_products_values
'avg_value': float(val['tot_value'])/float(val['tot_qty'])
ZeroDivisionError: float division by zero
```
opw-4074859This update resolves a crash that occurred when users attempted to edit certain shipping reports (Shipping Labels and Shipping Documents) in the Web Studio editor. The fix prevents these incompatible reports from appearing in the editor, eliminating the error and improving the user experience.
Original PR description
before commit: while going to edit the report(Shipping Labels and Shipping Documents) this traceback is raised.For preventing from the error adding in rename_black_list to prevent from editing and…
before commit:
while going to edit the report(Shipping Labels and Shipping Documents) this traceback is raised.For preventing from the error adding in rename_black_list to prevent from editing and not showing in editor [these two reports ]( https://github.com/odoo/enterprise/blob/17.0/delivery_iot/report/delivery_carrier_reports.xml#L5-L6)
```
Traceback (most recent call last):
File "/data/build/odoo/odoo/http.py", line 1770, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "/data/build/odoo/odoo/service/model.py", line 133, in retrying
result = func()
File "/data/build/odoo/odoo/http.py", line 1797, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/data/build/odoo/odoo/http.py", line 2001, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/data/build/odoo/addons/website/models/ir_http.py", line 235, in _dispatch
response = super()._dispatch(endpoint)
File "/data/build/odoo/odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "/data/build/odoo/odoo/http.py", line 725, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/data/build/enterprise/web_studio/controllers/report.py", line 474, in load_report_editor
report_qweb = self._get_report_qweb(report)
File "/data/build/enterprise/web_studio/controllers/report.py", line 612, in _get_report_qweb
main_qweb.xpath("//*[@id='wrapwrap']")[0]
IndexError: list index out of range
```