Closed Bug 897139 Opened 11 years ago Closed 11 years ago

[supersearch] Links to /report/list don't work

Categories

(Socorro :: Webapp, task, P2)

Product:
Socorro
Component:
Webapp
Type:
task

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: adrian, Assigned: adrian)

References

Details

(Whiteboard: [qa-])

Load https://crash-stats.mozilla.com/search/?product=Firefox&version=25.0a1&platform=Mac+OS+X Click one of the signatures, go to https://crash-stats.mozilla.com/report/list?signature=memchr&platform=Mac+OS+X&product=Firefox&version=25.0a1 for example Expected result: the page loads and shows appropriate results Actual result: platform Select a valid choice. Mac OS X is not one of the available choices. version Select a valid choice. 25.0a1 is not one of the available choices. It seems some of the parameters need to be renamed, and their values changed, to work with the /report/list page.
/report/list expects the version param to be product:version e.g. version=Firefox:25.0a1 This is because it supports showing multiple product/versions at the same time.
It seems that we need an alternate version of report/list which accepts search-style parameters instead of query-style parameters.
At first I think I will just try to match the supersearch params to the report/list/ ones, that will be easier. In the future I plan on making things a bit different, and we will maybe even rework that report/list/ page.
(In reply to Adrian Gaudebert [:adrian] from comment #4) > At first I think I will just try to match the supersearch params to the > report/list/ ones, that will be easier. In the future I plan on making > things a bit different, and we will maybe even rework that report/list/ page. I agree, while /report/list could surely use some refactoring (or outright replacement), I think just to fix this bug you need to pass the odd parameters it wants. If you do a replacement for it, I'd urge you to use the same URL and param styles as the majority of Socorro :) This /report/list view is quite large mostly due to all the special handling and implicit behavior it has.
Continuing the conversation here, Benjamin. (In reply to Benjamin Smedberg [:bsmedberg] from comment #17) (from bug 889041) > I don't see how it's going to be possible to fix bug 897139 properly without > driving report/list from elasticsearch: how can you apply the same search > limits to report/list? We can't. Supersearch and report/list are very different. That bridge I'm building between supersearch and report/list will be very limited, because most of the possible terms in supersearch don't exist in report/list. I'm just trying to do "something", using the parameters that report/list accepts. If you say that is stupid and useless, I'll be happy to simply remove any link from supersearch to report/list. If you think that is still needed, but needs improvement, we can probably talk about improving report/list and making it based on supersearch.
Commit pushed to master at https://github.com/mozilla/socorro https://github.com/mozilla/socorro/commit/e564424db582e0a712cde03999ae700fff7b5bcc Fixes bug 897139 - Fixed links to report/list from supersearch. r=peterbe
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
> We can't. Supersearch and report/list are very different. Why are they different? report/list is basically just a facet of supersearch on the signature. Or at least that's what we use it for when we're doing queries! So I don't really care whether it's report/list or some other piece of supersearch which lets me facet on signature.
Target Milestone: --- → 61
report/list is indeed a bunch of facets made on a subset of crash reports. However, report/list and supersearch are very different in their implementations. report/list takes all its data from postgres, and has a limited number of parameters. It also is quite inconsistent in its data sources, as for example the Reports tab takes data from the `reports` table, most of the other tabs take data from the `reports_clean` table, and the signature summary tab takes data from some matviews. This leads to inconsistent numbers across different tabs, for example, and is a mess to maintain. However, I believe we could rebuild this entire thing on top of supersearch. Actually, supersearch already provides most of the facets you can have in report/list, in one way or another (though sometimes pretty poorly, but we could improve that). I'd be happy to discuss plans about how to make supersearch even better for you, and I guess you will have plenty of suggestions after it is finally released (which will happen with release 61, not sure exactly when though). So, to answer your question: supersearch allows you to facet on signature (and actually, on any accessible field) without leaving the page. No need to go to report/list. The link to report/list is mainly here for people who need access to more detailed facets.
> most of the other tabs take data from the `reports_clean` table, and the > signature summary tab takes data from some matviews. Yeah, the signature summary is apparently quite useful for QA activities, but it confuses everyone who's doing customs searches because they don't understand that it's not based on the current search criteria. > So, to answer your question: supersearch allows you to facet on signature > (and actually, on any accessible field) without leaving the page. I can't figure out how to do this. I put in a basic query such as `release channel is nightly and date > 2013-08-26`. What I get back is a list of signatures, not a list of reports, and I can't get a list of the actual crash reports without clicking the report/list link. If/when I add a supersearch query like "CPU family is AMD model 3 family 10 stepping 0" then I need to be able to get to only those reports.
Oh, yes, sorry, the latest version of supersearch was not pushed to production yet. I think we can expect it on Monday. If you want to test it on stage: https://crash-stats.allizom.org/search/
Bumping to verified as [qa-] - if you'd like QA to spend some time reviewing this patch please bump the bug to [qa+] and add minimal steps to verify.
Status: RESOLVED → VERIFIED
Whiteboard: [qa-]
You need to log in before you can comment on or make changes to this bug.