Module
account_asset_batch_compute, in concordance with account_asset_management
Describe the bug
When using the account.asset.compute wizard, with batch_processing turned on, if the account.move creation of the related depreciations fails, the job can still end up as "Done", even though the create_move instruction on the depreciations lead to an error (ie, a concurrency error : SeralizationError)
This is due to the current implementation of _compute_entries of the account.asset model, which catches the exception and display its error message to the end users only after ending the computation, to not disrupt the computation of all depreciations.
(see account_asset_management/models/account_asset.py:L1229
However, this means that jobs created to batch compute the asset depreciations never catch this exception, and finish the job normally, even if the account.move creation failed, requiring the end user to restart the jobs, either manually or as a batch, to correctly compute all desired entries
To Reproduce
Affected versions: 16.0 (the only one I'm able to vouch for this error atm)
Steps to reproduce the behavior:
- Create more than 300 open
account.asset records.
- Open the "Accounting" -> "Assets" -> "Compute assets" wizard
- Set the "Date" field to a far enough date (one month or two away), and set the "Batch processing" check to True.
- Press "Compute"
- Wait a few seconds or minutes for all jobs to finish, and go to the "Job Queue" menu
- Check
compute_entries jobs and their results - some of them won't have returned ids for newly created account.move records, but only error messages.
Expected behavior
Batch asset computing jobs should fail if the depreciation.create_move raised an Exception, as to be able to restart automatically later.
Module
account_asset_batch_compute, in concordance withaccount_asset_managementDescribe the bug
When using the
account.asset.computewizard, withbatch_processingturned on, if theaccount.movecreation of the related depreciations fails, the job can still end up as "Done", even though thecreate_moveinstruction on the depreciations lead to an error (ie, a concurrency error :SeralizationError)This is due to the current implementation of
_compute_entriesof theaccount.assetmodel, which catches the exception and display its error message to the end users only after ending the computation, to not disrupt the computation of all depreciations.(see
account_asset_management/models/account_asset.py:L1229However, this means that jobs created to batch compute the asset depreciations never catch this exception, and finish the job normally, even if the
account.movecreation failed, requiring the end user to restart the jobs, either manually or as a batch, to correctly compute all desired entriesTo Reproduce
Affected versions: 16.0 (the only one I'm able to vouch for this error atm)
Steps to reproduce the behavior:
account.assetrecords.compute_entriesjobs and their results - some of them won't have returned ids for newly createdaccount.moverecords, but only error messages.Expected behavior
Batch asset computing jobs should fail if the
depreciation.create_moveraised an Exception, as to be able to restart automatically later.