Friday, September 27, 2024
7 changes · saas-17.4
Resolved issues and error corrections
The point of sale now keeps all missing related records when loading data from multiple sources. This prevents one missing record list from replacing another, reducing the risk of incomplete or lost POS data during synchronization.
Original PR description
When there are multiple missing records for the same relation across different models, only one was being retained. This fix ensures that missing records are merged correctly and no data is overwritten, preventing potential data loss during recursive loading. opw-4183904 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Romanian UBL e-invoice XML files now include the full invoice line description instead of only the product name. This restores the previous behavior and helps ensure recipients and tax systems receive complete item details.
Original PR description
*: l10n_ro_edi When a user generate a UBL XML that inherits from ubl 2.0, the Item/Description xml node will only contain the information about the product name, without any description. This commit aims at restoring the behavior before saas-17.4 and gives the full description on that XML value. To make sure it keeps this new behavior, a test was modified in l10n_ro_edi (the ticket origin) to make sure the Description display the `line.name` The change was previously introduced in https://github.com/odoo/odoo/commit/4f325ef620263c27e095eb49026a677ac617a0ee Similar fix to l10n_es_edi_facturae for reference: https://github.com/odoo/odoo/pull/180315 opw-4213014
Deleting a Point of Sale order now removes connected information first, preventing errors during the deletion process. This helps staff clean up orders more reliably without interruptions.
Original PR description
Before when deleting an order, we removed the order and after related records. This caused an error when trying to remove the order because the related records try to access the order. Now we remove the related records first and then the order. rb err: 98473
This fixes Xendit checkout so non-card payment methods can start the expected redirect flow. Customers using alternative Xendit payment options should no longer be blocked during payment, improving checkout completion.
Original PR description
Currently, for other payment method options in xendit, the redirect flow will not be triggered. method `_get_specific_rendering_values` is supposed to return the API URL when the payment is not 'card'. Currently, it does the opposite, where it will only return the rendering_values when payment is in card (eventhough it won't be triggered when doing direct flow) 4212477 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix stops Odoo from automatically saving certain forms when users switch away from the browser tab. It prevents interrupted workflows and data issues in related-record fields and settings, ensuring changes are only saved through the proper user action.
Original PR description
- one2many field: * On a dirty form view with an one2many filed; * Click the one2many field; * Open load more; * Create a new record; * Change the visibility (change tab on the browser). Before this…
- one2many field: * On a dirty form view with an one2many filed; * Click the one2many field; * Open load more; * Create a new record; * Change the visibility (change tab on the browser). Before this commit, the form view will save and close the load more and the new record dialog. - many2many field: * On a new record form view with a many2many field; * Click the `add` button on the kanban of the many2many field; * Complete the dialog form view; * Change the visibility; * Save the dialog form view. Before this commit, because when changing the visibility, the background form view will save the new record, and the dialog form view (the one opened when clicking the button `add`) will lose the references to it's parent record. - settings: * Open the settings view; * Made a change on a setting; * Change visibility. Before this commit, the settings will be saved without calling the `execute` function. Furthermore, settings should never be saved if it's not an implicit action from the user. The autosave feature really doesn't make sense in any of these cases. opw-[4141005](https://www.odoo.com/web#id=4141005&view_type=form&model=project.task) opw-[4143092](https://www.odoo.com/web#id=4143092&view_type=form&model=project.task) opw-[4177698](https://www.odoo.com/web#id=4177698&view_type=form&model=project.task) opw-[4151462](https://www.odoo.com/web#id=4151462&view_type=form&model=project.task)
Kitchen printers in the self-order kiosk now correctly receive food orders after checkout. This prevents missed preparation tickets caused by category detection and order tracking issues.
Original PR description
The kitchen printing was broken due to a couple of bugs that prevented it from checking the product category correctly, and also using the wrong variable name for the tracking number. This PR fixes those issues. Steps to reproduce: - Go to the settings of default PoS Kiosk - Enable Preparation -> Prepartion Printers, and add a new Printer - Configure either IoT or Epson printer, and add 'Food' product category - Make sure the new printer is added in the Preparation Printers selection for the Kiosk - Open the kiosk session and make an order with a food item - Printer does not print on order confirmation - EXPECTED BEHAVIOR: Printer prints order details on confirmation --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents manufacturing shop floor instruction updates from failing when similar steps already exist or multiple manufacturing orders are open for the same bill of materials. Users can now add improvement suggestion steps to the correct order without encountering blocking errors.
Original PR description
Steps: - create a bom for product A with 1 operation - add 2 steps to that operation with the same title, the same test_type_id and the same component(s) - create a 2 MOs for that bom - in the shopfloor, go on the workcenter for the operation - do: Update Instructions > Improvement Suggestion > Add a Step > validate - do the same for the other MO Issue 1: you get a traceback 'Expected singleton' because it cannot differentiate between the 2 pre-existing steps (same title, same test_type_id, same component(s)) Issue 2: you get a traceback 'Expected singleton' because with at least 2 open MOs, it will select all checks without `previous_check_id` across all MOs of the same bom Fix: 1) if more than 1 step can be selected, take the first and remove it from the `points` list all the points in that list will be processed only once so it's ok to remove them after using them. 2) make sure that the selected check corresponds to the MO on which we are adding a step.