Prevent deleting worker results when filters are applied
https://redmine.teklia.com/issues/7691
The worker results deletion does not, and cannot for various reasons, filter elements as much as the element list APIs. However, because some other actions like process creation are synchronized to the filter bar, some deletions have been executed while having some filter bar filters applied in an attempt to restrict them. This came with delightful consequences.
A new navigationStore.canDeleteWorkerResults getter should be added. It returns true when appliedFilters does not include any key that is not page, order, order_direction or any with_* option. This means that exactly zero filters must be applied to the filter bar to allow deleting worker results.
When:
- the
DeleteResultsModal.vueis opened; - it is not opened in the context of the selection (the
selectionprop is false); - the current route name is
'navigation'(the corpus elements list page) or'element-details'(the folder elements page), meaning that there is a FilterBar and the navigation store is being used; -
navigationStore.canDeleteWorkerResultsisfalse;
The worker results deletion modal should disable every Delete button everywhere, and return early on any attempt to call the deletion code. It should also show a warning notification at the top of the modal, visible in both normal and advanced modes, explaining that some filters are set in the current navigation page and that they will not be applied when deleting worker results. To prevent accidental deletions, users must first clear all filters in the filter bar and preview the element count.
As a convenience, we can add an extra Clear all filters button within this warning. Clicking it calls this.$router.push({ ...this.$route, query: {} }) and immediately closes the modal. This removes all filters, causing the navigation components to update themselves and list all affected elements. This may encourage users to contemplate the consequences before opening the modal again.