Filtering cases into a new suite is not functioning



5 years ago
2 months ago


(Reporter: echang, Unassigned)




(3 attachments)



5 years ago
Created attachment 8429981 [details]
Filter doesn't seem to be working

### STR
1. Search for tag "edward.2.0" in Manage -> Cases.
2. 77 results shown.
3. Manage -> Suites 
4. Filtering "edward.2.0" or anything in cases.
5. <ISSUE> Unrelated cases shown, and it doesn't work if we need to put 2nd word to search, maybe it is due to timeout, and returns whatever it has at that moment. Because it returns the same thing no matter what keyword is provided.
6. Select all cases with "edward.2.0" to the new suite.
7. only 32 cases found in that suite.

Comment 1

5 years ago
Created attachment 8429982 [details]
77 found in cases with "edward.2.0"

Comment 2

5 years ago
Created attachment 8429983 [details]
Only can be found from list and added to the new suite

Comment 3

5 years ago

After you land some of the performance improvements, can you have a look at this issue as well?
Sure can. Rushing to finish Q goals at the moment followed by a slight backlog pushed back due to mentioned goals.
Any update on this? Currently the filtering is pretty bad in MozTrap and it is making it very difficult to create new Test Suites and add test cases to them.
Hi Marcia - Peter and I just had a meeting about this.  We can reproduce the problem and have a solution in mind.  

Peter is going to work on this to get the filtering working.  In addition, we're going to change that page so that it doesn't load EVERY available test case when you first load it.  In fact, it won't load any available cases until you click the new "Load Cases" button.  This will allow you to add your filter criteria before hand.  This will save you from waiting through an unfiltered load every time you create a new suite.
Mainly some note-to-selfs (and camd):
The mysql query to fetch all them cases for "Firefox OS" takes 1-2 seconds, serializing the objects to JSON takes 1 second but the whole request takes about ~50 seconds on my fast laptop. 
There is a very "angry" issue on tastypie [0] which would make it roughly half the 50 seconds but that's still crazy-slow. 
We could probably move this query away out of tastypie screwing it up and writing our own view function that just selects the objects as pure dicts and serializes that. We'll still have a 1Mb JSON blob at worst but at least we should be able to generate it in about 2-3 seconds. 

This was fixed by peterbe.  Pushed to prod
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1023439
Bumping to verified duplicate


2 months ago
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in before you can comment on or make changes to this bug.