I have been thinking about a user friendly way to delete a large number of openscap reports from UI. The workflow we currently use is essentially the same as for host bulk actions in the hosts/index:
Select reports in a table by checking a checkbox for each report you want to delete
Choose bulk action by clicking a button above the table
Modal with selected reports shows, users clicks ‘Submit’ button
This approach is limited by the number of items displayed on the page - it is possible to delete only one page at the time, which may be a problem when users have large number of reports - 1000 and more.
The best thing I could come up with was a slight modification of the workflow, which could be used for bulk actions in general:
Choose action from ‘Select action’ dropdown menu - ‘Change power state’ for example
Modal with search shows, users search for records, search results are shown in a table with client-side pagination. All records are selected by default, users can deselect them.
When users are happy with selection, they choose additional values specific for given action (desired power state for ‘Change power state’) and submit
I realize selecting hundreds or thousands of hosts for a bulk action would be a rare case, but maybe it is worth having in core.
I am wondering whether this is something our community would be interested in and if/how much effort we should invest in this area.
Yes, I want this in core. I am willing to help with implementation/testing/reviewing.
Yes, I want this in core. Due to $reason, I will not be able to help with implementation/testing/reviewing.
No, I do not want this in core, because bulk actions in core work fine. If plugins need something special, they have to deal with it on their own.
No, this is not worth spending time on. Tell users to go to Administer -> Settings, General tab. Increase ‘Entries per page’ setting to 100 000. Then use the current workflow to select and delete all the desired reports on the page. When done, revert the setting to original value. This approach is user friendly enough, close the bug.
No, I will explain my reasons in a comment below
Something else - I will explain in a comment below
I would be happy to see the table we introduced at the hw model page enhanced and enable bulk actions (e.g. bulk delete is probably relevant for nearly every resource).
I have been thinking about a user friendly way to delete a large
number of openscap reports from UI. The workflow we currently use is
essentially the same as for host bulk actions in the hosts/index:
Select reports in a table by checking a checkbox for each report
you want to delete
Choose bulk action by clicking a button above the table
Modal with selected reports shows, users clicks ‘Submit’ button
This approach is limited by the number of items displayed on the page
it is possible to delete only one page at the time, which may be a
problem when users have large number of reports - 1000 and more.
The best thing I could come up with was a slight modification of the
workflow, which could be used for bulk actions in general:
Katello has handled this for a while via our api, you can see the
response that is accepted here:
It was created to mimic gmail’s select all, in that you can:
select a page of results from a search
once that is done, an action appears that lets you click to ‘select
all’ from those results
You can unselect one or more records on the page.
The client then sends up a search param, plus a list of any unselected
entries, so the server can re-build the list of all selected items.
Choose action from ‘Select action’ dropdown menu - ‘Change power
state’ for example
Modal with search shows, users search for records, search results
are shown in a table with client-side pagination. All records are
selected by default, users can deselect them.
Does this mean the client needs to fetch the ENTIRE list of results?
That doesn’t seem scalable if so.
Also having a second list with a search box and select box seems kinda
strange, why not do it all in the initial list?
I would like to delete all the items that match the search, not just one page. Doing it in the initial list is what we now have for host list and openscap reports have that as well, but you can only delete one page at a time.
But you are right, fetching all the matching results may cause performance issues.
That user can after selecting all on one page use appearing button and select all the records matching the search, which is than translated to the api call with included[search]='some funny openscap search'.
And I really like the solution!
I would just disable the option of deselecting once whole search is used, as that most likely means, that user do not understand even items out of the view are going to be affected, I believe this case should be everything or nothing.
Justin_Sherrill:
The client then sends up a search param, plus a list of any unselected
entries, so the server can re-build the list of all selected items.
That user can after selecting all on one page use appearing button and
select all the records matching the search, which is than translated
to the api call with |included[search]=‘some funny openscap search’|.
And I really like the solution!
I would just disable the option of deselecting once whole search is
used, as that most likely means, that user do not understand even
items out of the view are going to be affected, I believe this case
should be everything or nothing.
Yep exactly! And i kinda agree, when we were originally designing this
feature, we debated whether to add the ‘unselect’ items feature and
ended up going with it. I’ve not actually seen anyone use it, and it
can easily add confusion. It could always be added on later if we
REALLY decided users needed it.
The one caveat with this is that you need to make sure the appearing
button/bar/link that lets the user select ALL results its very apparent
and clear. I think katello’s is not super obvious at the moment and has
some room for minor improvement.
Thanks for suggestions! I started working on something that would mimic how gmail and katello tackle this. I will post an update when there is a progress.
This UI has been tested and approved by UX (@Roxanne_Hoover) if you want to use it in foreman. If you’re feeling extra adventurous it would be great to have something like this written as a react component so we can use it in katello in the future
The most important thing imho is to agree on one implementation and use it everywhere, so we don’t have 3 different ones in different places. I also agree that doing it similar to how gmail works is best - esp. with regards to selecting all on all pages that we had lots of bugs with in the past.
