Wednesday, April 24, 2024
2 changes · saas-17.2
Resolved issues and error corrections
This fixes an error that could appear when a user tried to add a bank account again after closing the first connection window. The change keeps the saved connection action intact so users can retry bank linking without hitting an internal server error.
Original PR description
### Steps to reproduce: 1. Install Accounting 2. Configuration 3. Add a new bank 4. Close the iframe 5. Configuration 6. Add a new bank 7. Internal Sever Error ### Explanation Since…
### Steps to reproduce: 1. Install Accounting 2. Configuration 3. Add a new bank 4. Close the iframe 5. Configuration 6. Add a new bank 7. Internal Sever Error ### Explanation Since f49e97e9ad41c1c5e7123bad9c429a9af2732b73, when a server action is loaded, it is executed directly and stored in the actionCache to avoid back and forth between the client side and server side. However, on OdooFin's side, one of the params (`includeParam`) of the action is stringified. Since OdooFin's iframe is loaded in Odoo, the actionCache now stores `includeParam` as a string too instead of as an Object. The next time we try to link a new bank, we'll fetch the cached action where `includeParam` is a string. This will be sent to OdooFin which will parse it partially (the Object is OK, but not the sub-Object which is now a string). Then we trying to get a value from `includeParam`, we'll be met with a the following exception on OdooFin's side `AttributeError: 'str' object has no attribute 'get'` and an Internal Server Error on Odoo's side. ### Fix Instead of sending the real Object `params` to OdooFin which will get modified, we now send a deepcopy of it. Odoo's Object shouldn't be altered by OdooFin. task-id/opw: none
Stock operation types must now have default source and destination locations set when configured. This prevents inventory moves from being created without a valid destination, reducing errors in warehouse processing after recent routing changes.
Original PR description
Since the pull&push refactor, the `location_dest_id` of a stock.move is now computed, based on its picking or picking type. It raises an issue, as a picking type can be created without a `default_location_dest_id`. This implies that a move can be created without any destination (no picking yet and picking type has no default dest), which makes no sense. Since we're in stable version, we can only enforce it on the client-side, a real requirement will be set in master. As we enforce the `default_location_dest_id`, we also enforce it for `default_location_src_id` for consistency's sake, even though it is far less critical. Doing so also means providing a compute that will give a default source/destination location regardless of the picking.type's `code`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr