Closed Bug 688275 Opened 13 years ago Closed 12 years ago

Add the snazzy two-part search-and-multi-select widget for included test cases for suites

Categories

(Mozilla QA Graveyard :: MozTrap, enhancement)

Product:
Mozilla QA Graveyard
Component:
MozTrap
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: camd, Unassigned)

References

Details

This covers ONLY the selection of test cases for a Test Suite.
A Pivotal Tracker story has been created for this Bug: http://www.pivotaltracker.com/story/show/18618311
Cameron Dawson added a comment in Pivotal Tracker:   
   
This is the first part of the story to use this in User selection and Test Suite selection for Test Runs, which is handled in this story: https://www.pivotaltracker.com/story/show/12968421
Blocks: 645904
Target Milestone: --- → 0.6
Eric Meyer changed story state to started in Pivotal Tracker
Carl Meyer added a comment in Pivotal Tracker:   
   
wireframe is visible at /manage/testsuite/add
Cameron Dawson added a comment in Pivotal Tracker:   
   
Eric:  This looks really great.  I think the fields you show are about right.  I have had it requested to add the testcase_id back in to parts of the product (like filtering and viewing details) but I don't think it's appropriate in this widget.  I wish there was some way to show the "meaningful" environment values here (like whether it's mac or windows) but I don't think that's possible.  Unless there is some way to show the env values that the test case has been narrowed to (if anything), rather than what it inherits from above.

i.e.: as a part of Product X, these tests apply to Mac, Windows, and Linux.  However, this one test case has been narrowed to specifically just "Mac"  We could possibly show the "narrowing" value.  Hmm, or if that's too busy, we could show the env icon next to any case that has had specific narrowing on it.  And if the user hovers over that icon, it shows what the narrowing was?  Thoughts?
Carl Meyer added a comment in Pivotal Tracker:   
   
The environment stuff sounds like a great idea for post-1.0. At this point I don't have a reasonable way to detect that a test case's environments are "narrowed".
Carl Meyer added a comment in Pivotal Tracker:   
   
Cam: by reassigning to Eric and not checking off your approve task, were you asking for wireframe updates before approval? Or just forgot to check off the task?
Cameron Dawson added a comment in Pivotal Tracker:   
   
Carl: I just wanted to ask his opinion on the env stuff before approving.  but your point is well taken, and I agree.  If it's not trivial to get the info right now, then let's punt.  I'll create another post-1.0 story for that.  And approve it as is.
Jonny Gerig Meyer added a comment in Pivotal Tracker:   
   
Cam: In regard to Eric's second question (in his email), I assume we're filtering by multiple fields, and therefore using filter chicklets? (As opposed to doing live filtering if we're only filtering by a single field [title].)
Cameron Dawson added a comment in Pivotal Tracker:   
   
Jonny and Eric:  yeah, I think multiple filter / chicklet is the right way to go.  I think the filterable fields should be just what's shown.  Though I also think we should show one additional field: status.
So, filter on: status, name and author

Reason: we used to ONLY allow adding active test case to suites, but that's no longer the case.  We can now add cases in draft status, too.  I know it uses real-estate, but I feel it's important.

Also: since the filtering here is smaller, can we just update the list on each filter change, rather than the orange thing and "click to update list" button and all?  I'm hoping since the list will be narrowed quite a bit by only what applies to this product that the speed won't be too bad?  If it's easier to do it the other way (with secondary update button) then go for it.
Jonny Gerig Meyer added a comment in Pivotal Tracker:   
   
Eric: Given Cam's comment, can you mock this up to include some applied filter chicklets? Esp. multiples filters of different types (status, author, name).
Eric Meyer added a comment in Pivotal Tracker:   
   
jonny: we don't currently distinguish chicklets between the fields the apply to. maybe we should, but that's a different issue across the site. for now I mocked it in the way we have been doing it.
Jonny Gerig Meyer added a comment in Pivotal Tracker:   
   
Eric: Well, we do by having multiple categories of filters in manage-results advanced filtering. I thought you might want to take a similar approach here, but that's up to you.
Jonny Gerig Meyer added a comment in Pivotal Tracker:   
   
Carl: I've copied in some advanced filtering markup from manage-results (labeled in _case_select.html with @@@). I think it should create three lists of filters: one for status, one for name (empty), and one for author. Plz make it work, kthxbai!
Carl Meyer added a comment in Pivotal Tracker:   
   
Ok @j, the filters stuff is live now. The _case_select.html template is also moved, it's now forms/_filtered_select_multiple.html. And it's no longer a simple template include, it's back to being a form field rendered like any other form field in the suite_form.html template, and the form widget renders the forms/_filtered_select_multiple.html template. That latter part shouldn't really impact you though.
Jonny Gerig Meyer added a comment in Pivotal Tracker:   
   
Eric: I have a few remaining UI questions about this multi-select widget.

1) Is filtering included test cases really necessary? It seems potentially confusing if someone has a filter applied there and saves the form, because test cases that may not be visible (because they're filtered out) will be included as well. I think it makes sense to ignore filters when submitting the form, but even having filters there at all might lead to some confusion. Or maybe on-submit you get a warning telling you that there are applied filters, and you aren't seeing all of the test cases that will be submitted?

2) What should happen to filters when you drag-n-drop or bulk-move test cases from one side to the other? Either they need to be re-applied (in which case the test cases you just moved over might disappear), or they need to be removed (in which case the list might expand significantly). I think the latter makes more sense, so that's what I did for now.

3) Shift-select works, but it was a bit confusing for me to think through how it should work for selecting and deselecting groups of test cases. Play with what I have, and see if it makes sense. Basically, if you just selected an input, shift-clicking another input will select both of those and all the ones in between. But if you just deselected an input, shift-clicking another input will deselect both and all in-between. I think it's intuitive, but let me know if you want to see something different.
Cameron Dawson added a comment in Pivotal Tracker:   
   
Jonny:
1. I agree.  I think only filtering the not-yet-included test cases is what counts.  No filtering at all should be on the ones-to-be-added side, as that would be confusing.

as for the others, IMO, you're on the right track.  :)
Eric Meyer added a comment in Pivotal Tracker:   
   
That all sounds right to me, and I'm pushing an update to remove filtering on the selected side.
Carl Meyer added a comment in Pivotal Tracker:   
   
Jonny: my part of this is active. Couple things back to you:

1. Drag and drop is not working right. Or, it seems to "work", but visually it drops things below the box instead of in them.

2. When you select a product from the product dropdown, it needs to automatically filter down the available test cases to just those for that product. This is implemented in formOptionsFilter in manage-products.js. I managed to make enough small tweaks to formOptionsFilter and its arguments on the suite form to make it work with the new multiselect markup, but it doesn't interact well with filters. Specifically, when you change the product it loads all the test cases for that product, irrespective of any filters you might have applied - but doesn't actually remove the filter chiclet. I think just clearing filters is the right thing to do here, because its going to be an entirely different set of cases for the new product anyway, so your previous filters aren't really relevant anymore. So in that case, the options are behaving correctly as it is, the filters just need to be cleared on product switch.

Made you tasks for both of these.
Jonny Gerig Meyer added a comment in Pivotal Tracker:   
   
Carl: Fixed, but one question. How should this act when switching products if you've already included some test cases? My sense is that both lists get reset (so the included cases get erased)? If so, I need to add that. If not, I need to make the formOptionsFilter smarter so that it doesn't try to add cases that are already included.
Cameron Dawson added a comment in Pivotal Tracker:   
   
jonny: I agree.  If the product changes, then the whole game is reset.  Test cases don't span multiple products, so both lists must be emptied.
Cameron Dawson added a comment in Pivotal Tracker:   
   
eric: I'm liking the snazziness of this widget.  But something isn't right with the aesthetic.  Since we're filtering only on one list, now the headers for both lists don't match up.  I must admit that severely takes away from the aesthetic (for me).  It feels jarring and unpleasant.

I realize that the left column needs two vertical items more than the right: filter field and filter chicklets.  And if we lined up the headers, then there would be a lot of white space on the right between the title and the headers.  But I think this would be better.  

Could we minimize that white space difference by perhaps putting the filter field on the same line as the list title of "Available Cases" ?
Eric Meyer added a comment in Pivotal Tracker:   
   
Cam, after playing with it I agree on the main point, but I find that combining lines adds too much clutter. See what you think after the changes I made.
Carl Meyer changed story state to finished in Pivotal Tracker
Carl Meyer changed story state to delivered in Pivotal Tracker
Cameron Dawson added a comment in Pivotal Tracker:   
   
Tastes great!  Less filling!  Wahoo!!!
Cameron Dawson changed story state to accepted in Pivotal Tracker
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in before you can comment on or make changes to this bug.