Daily updates from Odoo
Wednesday, July 31, 2024
28 changes · saas-17.2
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