Bug 1012214 - No visible feedback to user that a group of records is selected for bulk update
No visible feedback to user that a group of records is selected for bulk update
Status: NEW
Product: PressGang CCMS
Classification: Community
Component: Web-UI (Show other bugs)
1.1
Unspecified Unspecified
low Severity high
: ---
: ---
Assigned To: pressgang-ccms-dev
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-25 23:10 EDT by Ruediger Landmann
Modified: 2013-10-08 21:32 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ruediger Landmann 2013-09-25 23:10:52 EDT
Description of problem:
When you select records for bulk update, the UI provides no feedback that a selection is now in place

Version-Release number of selected component (if applicable):
Build 201309081012

How reproducible:
100%

Steps to Reproduce:
1. Click Advanced -> Bulk Tagging
2. Enter a topic map ID in the "Topic Included In Content Spec" field

Actual results:
No visible change, although potentially hundreds of topics are now selected for bulk editing. 

Expected results:
UI responds to indicate that a selection is now in place; for example, a message like "211 topics selected for bulk update".

Additional info:
When nothing happened, I started hunting for an "apply" button. When I couldn't find anything like that, I started clicking the other tabs to see if any of those would apply my filter. When I clicked "Search topics" that seemed right; at least it produced a visual change. However, I was now in entirely the wrong place to apply a bulk update.
Comment 1 Lee Newson 2013-10-08 19:50:09 EDT
Hmm, I couldn't replicate part of this sorry rudi. Whenever I try to apply a bulk update I always get the message:

This operation will modify <NUM> Topic(s).
This operation can not be cancelled, and can not be undone. Are you sure you wish to continue?

In saying that though there is still the issue that when selecting/adding query parameters they should display somewhere so that you don't have to flick through tabs to find out what you are searching for.
Comment 2 Ruediger Landmann 2013-10-08 21:01:23 EDT
(In reply to Lee Newson from comment #1)
> Hmm, I couldn't replicate part of this sorry rudi. Whenever I try to apply a
> bulk update I always get the message:
> 
> This operation will modify <NUM> Topic(s).
> This operation can not be cancelled, and can not be undone. Are you sure you
> wish to continue?

Right, but I think that's too late. If I select a bunch of records, I would expect:

1. some kind of visual confirmation "59 records selected" -- right now, the UI doesn't react at all and when I was first working with it, I didn't even know that the selection had been applied and was hunting for an "apply" button. 

2. that confirmation to remain visible right up to the time when I hit "Apply Bulk Tags" -- this morning I was inadvertently trying to apply bulk tags to every topic in the database without knowing that my selection had somehow failed or fallen out. 

Right now, users have to guess the state of the selection from the time they create a filter to the time they attempt to apply tags to every topic in a query in an unknown state :)

If they're lucky, the "This operation will modify <NUM> Topic(s)" will be enough to warn them that they're not modifying the topics they think they're modifying. If they're unlucky, it's presently really easy to modify topics that you didn't think you were touching.

> In saying that though there is still the issue that when selecting/adding
> query parameters they should display somewhere so that you don't have to
> flick through tabs to find out what you are searching for.

Yeah, something like that up in a corner of the screen should do the trick.
Comment 3 Lee Newson 2013-10-08 21:32:40 EDT
The main cause here in my opinion is that bulk tagging is done in the wrong order. It really should use the following workflow:

1. Define a search/filter
2. Execute the search to make sure that results are what you'd expect
3. Apply Bulk tags to the search results

That way you get to see the number of results and gives you a chance to make sure nothing extra is included by accident. At the moment as you said you have to guess that the search query you use is correct. In saying that though what I said in comment #1 about displaying what the query as you define it still applies for generic searches as well.

Note You need to log in before you can comment on or make changes to this bug.