Open rachel3834 opened 3 months ago
These performance issues are particularly noticeable when a couple of commands are running in the background:
@rachel3834 I cannot reproduce this error locally. I'm also not sure why running a management command should lock the DB for more than the fraction of a second it takes to write the final results. I'm not really familiar with these management commands, can you determine which part of them causes this issue and can you describe (or better yet screenshot/copy error messages) what actually happens when you try to open a target detail page? If you have some documentation that says this is done to avoid integrity errors, or have done something for MOP that specifically does this, links would be super useful.
Is your feature request related to a problem? Please describe. My TOM system has a number of management commands running at intervals in the background under the crontab, as well as the UI. When these commands select one of our targets for an operation, that target is locked, so that the user cannot edit the target data while the operation is in progress. This is done to avoid data integrity errors, but has the drawback that the user cannot view the current target information in the UI until the command process and finished and the target is unlocked again.
Describe the solution you'd like A better solution would be to allow the user to view the target detail page while the background command is running, but simply grey-out and deactivate the button that allows editing of the target parameters.
Additional context While this is a general problem, it is probably most important for my particular TOM, so rather than upgrade the Toolkit necessarily, I'd appreciate some guidance on how to address this in my own code.