Odoo Changelog — 2024-02-13

Tuesday, February 13, 2024

2 changes · saas-17.1

Bug Fixes(2)

Resolved issues and error corrections

[FIX] point_of_sale: traceback when cached order payment method removed

Coresaas-17.1point_of_saleMedium

The Point of Sale now handles saved unpaid orders more safely when a payment method used on them has since been deleted. This prevents an error screen when reopening the POS session, helping staff resume work without disruption.

Original PR description

Steps to reproduce:
-make an order
-make a payment for it but do not validate it
-close de session
-remove the payment method used
-open the pos again
-traceback is shown

Since the payment method is removed, when the session recovers the cached orders an error is raised since the payment method doesn't exist anymore. A try catch is added around the recovery of the cached orders.

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

#pos#payment-methods#session-recovery#cached-orders

[FIX] worksheet, industry_fsm_report: fix closing studio when design a template

PR #56537

Enterprisesaas-17.1industry_fsm_reportworksheetMedium

Users can now leave template design mode without an error or crash. The fix keeps field service-specific behavior separate from the general worksheet flow, so changes are saved reliably for worksheet templates.

Original PR description

description : When a user is trying to deisgn a new template, upon quitting studio mode, an error is trigger, or in some case the studio page is not even opened and crashes. steps to reproduce: on…

description :
When a user is trying to deisgn a new template, upon quitting studio mode, an error is trigger, or in some case the studio page is not even opened and crashes.

steps to reproduce:
on any saas-17.1 -master version
- open quality app
- select configuration then quality worksheet template
- select Design template on any worksheet
- click on the 'close' button to leave studio an error message is displayed.

expected behavior: studio is closed correctly and the changes are saved

source of the issue:
The worksheet_id was added to the context in generic use case to handle a fsm specific one. This was done in order to let the opportunity to later on use the same logic on other module if needed. This id being present in the context is triggering the fsm specific steps when it is unneeded.

Solution:
Remove the id from the generic method 'get_x_model_from_action' and add it in the overwrite inside the fsm module.

note:
No tests were added because the only way to test this use case is to add a js tour, which seemed a bit overkill for such a small fix.

opw-3730854
affected version: saas-17.1 - master

Steps to reproduce: -make an order -make a payment for it but do not validate it -close de session -remove the payment method used -open the pos again -traceback is shown Since the payment method is removed, when the session recovers the cached orders an error is raised since the payment method doesn't exist anymore. A try catch is added around the recovery of the cached orders. 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

description : When a user is trying to deisgn a new template, upon quitting studio mode, an error is trigger, or in some case the studio page is not even opened and crashes. steps to reproduce: on any saas-17.1 -master version - open quality app - select configuration then quality worksheet template - select Design template on any worksheet - click on the 'close' button to leave studio an error message is displayed. expected behavior: studio is closed correctly and the changes are saved source of the issue: The worksheet_id was added to the context in generic use case to handle a fsm specific one. This was done in order to let the opportunity to later on use the same logic on other module if needed. This id being present in the context is triggering the fsm specific steps when it is unneeded. Solution: Remove the id from the generic method 'get_x_model_from_action' and add it in the overwrite inside the fsm module. note: No tests were added because the only way to test this use case is to add a js tour, which seemed a bit overkill for such a small fix. opw-3730854 affected version: saas-17.1 - master