663872 - users should see "owned" items when they expand a list item to see detail

Status: RESOLVED FIXED

(Mozilla QA Graveyard :: MozTrap, enhancement)

Description

[Cameron Dawson [:camd]]

When you click a list item to expand and see detail, it should list the items it is associated as "owning"

For example: 
Test Cycles should show the Test Runs they own.
Test Runs should show the test suites they contain.
Test Suites should show the test cases they contain

Comment 1

[Cameron Dawson [:camd]]

A Pivotal Tracker story has been created for this Bug: http://www.pivotaltracker.com/story/show/14503085

Comment 2

[Cameron Dawson [:camd]]

Eric Meyer added a comment in Pivotal Tracker:   
   
Are we sure we want this? These will likely be very long lists. I'm not sure they belong in the parent's list view - that's why we allow you to drill-down to them in a new list.

Comment 3

[Cameron Dawson [:camd]]

Carl Meyer changed story state to started in Pivotal Tracker

Comment 4

[Cameron Dawson [:camd]]

Carl Meyer added a comment in Pivotal Tracker:   
   
Gah. So I failed to realize until I was working on this that the platform doesn't actually let us filter suites by "in-a-given-test-run" or cases by "in-a-given-test-suite", because both of these are non-exclusive containment: i.e. a suite can be in multiple runs, a case can be in multiple suites (there isn't a reason why the platform couldn't support this type of filtering, but that's why it doesn't).

For the moment, I've made the drilldown suites-in-a-run links use a hack; the drilldown URL actually appends an exact name filter for the name of each suite. This could be workable, though it's not entirely intuitive when you get to the filtered page.

I just removed the cases-in-a-suite drilldown link, because that hack won't work with really long lists (the URL will get too long). We do need a solution for viewing cases in a suite, particularly once the suite is active and therefore you can't visit its edit page. But this solution can't simply reuse the testcases manage list, it will have to be something dedicated. We should discuss options here at our next checkin.

Comment 5

[Cameron Dawson [:camd]]

Carl Meyer added a comment in Pivotal Tracker:   
   
This also needs a new JS feature on manage lists. If the list page loads with a hash id (say #cycle-id-1 on the cycles list), the JS should auto-click that row to expand its details sections.

Comment 6

[Cameron Dawson [:camd]]

Carl Meyer added a comment in Pivotal Tracker:   
   
Cam and I discussed a workaround here that should be sufficient, hoping we get this platform filtering at some point.

Comment 7

[Cameron Dawson [:camd]]

Carl Meyer added a comment in Pivotal Tracker:   
   
Ok, I got creative and found a way to make this work without the limitation of not being able to combine any other filters; basically I do a pre-filter API call to get the entire list of suite IDs for suites in a given run, say, and then on the real suite-filtering API call I filter by any of those suite IDs.

It's possible that if we get really long lists of test cases in a suite, the filtering URL for the backend API call will get too long listing all those IDs and will break. Hopefully if that ever happens, by that time we'll have the filtering native in the platform and won't need this workaround anymore.

Comment 8

[Cameron Dawson [:camd]]

Carl Meyer changed story state to finished in Pivotal Tracker

Comment 9

[Cameron Dawson [:camd]]

Carl Meyer changed story state to delivered in Pivotal Tracker

Comment 10

[Cameron Dawson [:camd]]

Cameron Dawson changed story state to accepted in Pivotal Tracker