Wednesday, August 7, 2024
11 changes · saas-17.2
Miscellaneous changes
`install` alias could not mount `/proc` as it was performed using 'sudo', which is unavailable as root is `/root_bypass_ramdisks` at this time. Forward-Port-Of: odoo/odoo#175297
Original PR description
`install` alias could not mount `/proc` as it was performed using 'sudo', which is unavailable as root is `/root_bypass_ramdisks` at this time. Forward-Port-Of: odoo/odoo#175297
… when the package type is scanned using the barcode Description of the issue this PR addresses: This PR aims to resolve the issue where the IoT scale is connected but unable to retrieve the weight from the scale. Steps to reproduce: 1. Enable packaging configuration. 2. Create a sales order and confirm it; this will generate a delivery. 3. Find that delivery in the ‘Barcode’ app. 4. Add/scan the product. 5. Scan the package type. Current behavior before PR: Following the above
Original PR description
… when the package type is scanned using the barcode Description of the issue this PR addresses: This PR aims to resolve the issue where the IoT scale is connected but unable to retrieve the weight…
… when the package type is scanned using the barcode Description of the issue this PR addresses: This PR aims to resolve the issue where the IoT scale is connected but unable to retrieve the weight from the scale. Steps to reproduce: 1. Enable packaging configuration. 2. Create a sales order and confirm it; this will generate a delivery. 3. Find that delivery in the ‘Barcode’ app. 4. Add/scan the product. 5. Scan the package type. Current behavior before PR: Following the above steps, when the package type is scanned using the barcode, the scanned package type is not populated in the opened package wizard. Consequently, the shipping weight field is not visible, preventing the retrieval of the weight from the IoT scale. Please refer to the screen recording before the PR: https://github.com/user-attachments/assets/e4764005-6758-4f80-a189-e27e8897f853 Desired behavior after PR is merged: After merging this PR, when the package type is scanned using the barcode, the scanned package type will be correctly populated in the opened wizard. As a result, the shipping weight will be visible, and it will be able to retrieve the scale weight from IoT. Please refer to the screen recording after the PR: https://github.com/user-attachments/assets/f408ee60-2495-48a5-96ea-3ced502c85dc --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173949
Description of the issue/feature this PR addresses: - Commit [1] changed `getDeepestPosition` to let it change the selection to its next block. This commit partially reverts commit [1] and ensures that it only changes blocks when the node is invisible. - Commit [2] changed the behavior of Ctrl+A when the first child of an editor was contenteditable false element, causing it to not select the first element. This behavior is incorrect, as Ctrl+A should always select all contents. This co
Original PR description
Description of the issue/feature this PR addresses: - Commit [1] changed `getDeepestPosition` to let it change the selection to its next block. This commit partially reverts commit [1] and ensures…
Description of the issue/feature this PR addresses: - Commit [1] changed `getDeepestPosition` to let it change the selection to its next block. This commit partially reverts commit [1] and ensures that it only changes blocks when the node is invisible. - Commit [2] changed the behavior of Ctrl+A when the first child of an editor was contenteditable false element, causing it to not select the first element. This behavior is incorrect, as Ctrl+A should always select all contents. This commit partially reverts commit [2] and provides an alternative solution to the original issue. - Inserting a horizontal rule was only possible on paragraph related elements. This PR makes sure horizontal rule can be inserted directly to block elements such as div. task-3850023 [1]: https://github.com/odoo/odoo/commit/ddc8587f8a712fdddaa714bee2931cb149c03a38 [2]: https://github.com/odoo/odoo/commit/530f102720458e5e1c224bf38073cd763309bf0a --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173729 Forward-Port-Of: odoo/odoo#164345
In Luxembourg, the "Société national des chemins de Fer Luxembourgeois" expects the `PartyLegalEntity/CompanyID` to be filled with the "Registre de Commerce et des Sociétés" (RCS), which is normally filled on the `company_registry` of the supplier company. Before this commit, we filled this tag with the VAT (which is also filled in the `PartyTaxScheme/CompanyID`). The peppol official documentation states: 1. `PartyTaxScheme/CompanyID`: "The Seller's VAT identifier (also known as Seller
Original PR description
In Luxembourg, the "Société national des chemins de Fer Luxembourgeois" expects the `PartyLegalEntity/CompanyID` to be filled with the "Registre de Commerce et des Sociétés" (RCS), which is normally…
In Luxembourg, the "Société national des chemins de Fer Luxembourgeois" expects the `PartyLegalEntity/CompanyID` to be filled with the "Registre de Commerce et des Sociétés" (RCS), which is normally filled on the `company_registry` of the supplier company. Before this commit, we filled this tag with the VAT (which is also filled in the `PartyTaxScheme/CompanyID`). The peppol official documentation states: 1. `PartyTaxScheme/CompanyID`: "The Seller's VAT identifier (also known as Seller VAT identification number) or the local identification (defined by the Seller’s address) of the Seller for tax purposes or a reference that enables the Seller to state his registered tax status." [1] 2. `PartyLegalEntity/CompanyID`: "An identifier issued by an official registrar that identifies the Seller as a legal entity or person." [2] Consequently, it is not certain whether the company_registry should always be used to fill the element `PartyLegalEntity/CompanyID` or not, hence we only use it in Luxembourg for now. [1] https://docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/cac-AccountingSupplierParty/cac-Party/cac-PartyTaxScheme/cbc-CompanyID/ [2] https://docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/cac-AccountingSupplierParty/cac-Party/cac-PartyLegalEntity/cbc-CompanyID/ opw-4075457 Forward-Port-Of: odoo/odoo#175379
Steps ----- 1. Have a product of type "Service" with "Subcontract Service" activated on the Purchase page and with at least a vendor. 2. Create a Sales Order with this product. When confirming it, a PO will be automatically created. 3. Create another Sales Order with the product. 4. The PO now has 2 lines, but the "Source Document" in "Other Information" of the PO only contains the name of the first SO. Cause ----- Refactor e54b57ee74893170134438a9b5873db4dfd03ddc changed the logic. If
Original PR description
Steps ----- 1. Have a product of type "Service" with "Subcontract Service" activated on the Purchase page and with at least a vendor. 2. Create a Sales Order with this product. When confirming it, a PO will be automatically created. 3. Create another Sales Order with the product. 4. The PO now has 2 lines, but the "Source Document" in "Other Information" of the PO only contains the name of the first SO. Cause ----- Refactor e54b57ee74893170134438a9b5873db4dfd03ddc changed the logic. If a PO is found by _purchase_service_match_purchase_order, it should have its origin modified to include the new SO (not the case currently). opw-4049834 Forward-Port-Of: odoo/odoo#174051
Before this commit, when a reward eligible for multiple products was claimed, only one product was added to the order regardless of the reward's configuration. opw-4066760 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175259 Forward-Port-Of: odoo/odoo#174176
Original PR description
Before this commit, when a reward eligible for multiple products was claimed, only one product was added to the order regardless of the reward's configuration. opw-4066760 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175259 Forward-Port-Of: odoo/odoo#174176
When creating an expense to be paid to the employee, if the employee's contact had a parent_id, then when trying to register a payment for that expense, the bank account of the parent company was used instead. In https://github.com/odoo/odoo/commit/1ed71ba1fa176de9b0100b96f5af7d76c224e1a2 a fix was made to use the employee's bank account. That fix is now being reverted and being replaced with this commit instead. If we're creating an expense to be paid to the employee, we show a warning ban
Original PR description
When creating an expense to be paid to the employee, if the employee's contact had a parent_id, then when trying to register a payment for that expense, the bank account of the parent company was used instead. In https://github.com/odoo/odoo/commit/1ed71ba1fa176de9b0100b96f5af7d76c224e1a2 a fix was made to use the employee's bank account. That fix is now being reverted and being replaced with this commit instead. If we're creating an expense to be paid to the employee, we show a warning banner on the vendor bill and the expense sheet that they're invoicing their own company. task-3955593 Forward-Port-Of: odoo/odoo#175416 Forward-Port-Of: odoo/odoo#167816
Before this commit, it was possible to delete an accrual plan while it was referenced by an allocation. This commit introduces an error message if the user tries to delete an accrual plan in those conditions. task-4023187 Also updates the `hr_holidays.pot` file Forward-Port-Of: odoo/odoo#175553 Forward-Port-Of: odoo/odoo#171403
Original PR description
Before this commit, it was possible to delete an accrual plan while it was referenced by an allocation. This commit introduces an error message if the user tries to delete an accrual plan in those conditions. task-4023187 Also updates the `hr_holidays.pot` file Forward-Port-Of: odoo/odoo#175553 Forward-Port-Of: odoo/odoo#171403
Description of the issue/feature this PR addresses: Current l10n_sa_edi module does not affect POS behavior, such as forcing Invoice creation on POS orders for Saudi companies Current behavior before PR: Invoicing on POS orders is not enforced for Saudi Companies Desired behavior after PR is merged: Invoicing on POS orders is enforced for Saudi Companies --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170303 Fo
Original PR description
Description of the issue/feature this PR addresses: Current l10n_sa_edi module does not affect POS behavior, such as forcing Invoice creation on POS orders for Saudi companies Current behavior before PR: Invoicing on POS orders is not enforced for Saudi Companies Desired behavior after PR is merged: Invoicing on POS orders is enforced for Saudi Companies --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170303 Forward-Port-Of: odoo/odoo#124300
**Before commit** - When the electronic scale is disconnected, its connection status is not updated. **After commit** - When the electronic scale is disconnected, the status of the electronic scale will be updated. **Error Description** - If you have a digital scale that is connected and selected for use in POS. - The status of IoT devices is updated via the router `/hw_proxy/status_json` and the function `get_status()` - However, the status of the digital scale is not updat
Original PR description
**Before commit** - When the electronic scale is disconnected, its connection status is not updated. **After commit** - When the electronic scale is disconnected, the status of the electronic scale…
**Before commit** - When the electronic scale is disconnected, its connection status is not updated. **After commit** - When the electronic scale is disconnected, the status of the electronic scale will be updated. **Error Description** - If you have a digital scale that is connected and selected for use in POS. - The status of IoT devices is updated via the router `/hw_proxy/status_json` and the function `get_status()` - However, the status of the digital scale is not updated when it is disconnected. This leads to the scale still reporting that it is connected when calling the `get_status()` function. The scale status is updated via `self._status` https://github.com/odoo/odoo/blob/8ff2381901e4920434eaee73f8c265fc67271c99/addons/hw_drivers/iot_handlers/drivers/SerialScaleDriver.py#L110-L114 However `self._status` is not updated when disconnected. https://github.com/odoo/odoo/blob/8ff2381901e4920434eaee73f8c265fc67271c99/addons/hw_drivers/iot_handlers/drivers/SerialBaseDriver.py#L129-L144 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175063
**Steps to reproduce the bug:** - Create a storable product "A1" and "A2". - Update their available quantity to 5. - Create a picking with 5 units of "A1" and another picking with 5 units of "A2". - Confirm both pickings. - Create a new wave transfer and add both pickings. - Update the quantity of "A1" to 0 units. - Try to validate the wave. **Problem:** A user error is triggered: "You cannot validate a transfer if no quantities are reserved. To force the transfer, encode quantities."
Original PR description
**Steps to reproduce the bug:** - Create a storable product "A1" and "A2". - Update their available quantity to 5. - Create a picking with 5 units of "A1" and another picking with 5 units of "A2". - Confirm both pickings. - Create a new wave transfer and add both pickings. - Update the quantity of "A1" to 0 units. - Try to validate the wave. **Problem:** A user error is triggered: "You cannot validate a transfer if no quantities are reserved. To force the transfer, encode quantities." **Solution:** When the quantity of "A1" is updated to 0, the state of the picking becomes "confirmed" instead of "assigned" and as all the moves in this picking have a 0 quantity, we can exclude it from the wave and allow the wave validation. opw-4016209 Forward-Port-Of: odoo/odoo#175888