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

RESOLVED FIXED

Status

--
enhancement
RESOLVED FIXED
8 years ago
2 months ago

People

(Reporter: camd, Unassigned)

Tracking

Details

(Reporter)

Description

8 years ago
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
(Reporter)

Comment 1

8 years ago
A Pivotal Tracker story has been created for this Bug: http://www.pivotaltracker.com/story/show/14503085
(Reporter)

Comment 2

8 years ago
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.
(Reporter)

Comment 3

8 years ago
Carl Meyer changed story state to started in Pivotal Tracker
(Reporter)

Comment 4

8 years ago
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.
(Reporter)

Comment 5

8 years ago
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.
(Reporter)

Comment 6

8 years ago
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.
(Reporter)

Comment 7

8 years ago
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.
(Reporter)

Comment 8

8 years ago
Carl Meyer changed story state to finished in Pivotal Tracker
(Reporter)

Comment 9

8 years ago
Carl Meyer changed story state to delivered in Pivotal Tracker
(Reporter)

Comment 10

8 years ago
Cameron Dawson changed story state to accepted in Pivotal Tracker
(Reporter)

Updated

7 years ago
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED

Updated

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.