All users were logged out of Bugzilla on October 13th, 2018
When looking at a list of crash reports, I always want to know how many distinct users are represented the crash -- 10 crashes from a single user is very different to one crash from 10 distinct users. It's easy to manually determine whether multiple crashes come from a single users. The "install time" field is the one I use the most, though there are several others can can be used in combination. Easy, but slow and tedious -- you have to open lots of reports in separate tabs and then look through them all. This should be automatable. You'd do some kind of hash on the fields that should be consistent for a particular build belonging to a particular user -- e.g. product, version, install time, build ID, architecture info, adapter vendor ID, adapter device ID -- and then map all the hashes down to small integers. The places where I'd like to see this info are: - In "Signature facet" tab of "Super Search" results: - Add a "distinct user count" column next to the existing "count" column. - In "Signature report for <signature>" - In the "Summary" tab: this info would get its own box, next to OS, Product, etc. - In the "Reports" tab: each hashed ID would get its own column. There may be other views where exposing this info is useful as well, but those are the ones that I use the most.
[FWIW, we don't know anything about *users*, we only know *installations*, so changing the subject to reflect that ;-)] (In reply to Nicholas Nethercote [:njn] from comment #0) > - In "Signature report for <signature>" In the "Products" section of the new /signature report we have that count, in the old /report/list report it's under "Crashes per Install". As it's probably a pretty expensive query, I'm not sure it would be good to do it for everything by default, but having it easily available is good. Note that something that happens for a reasonable count of installations but on average multiple times per installation has higher priority to be fixed than something that happens only once for every installation - but something that happens for an extremely tiny amount of installations could be completely bogus. And note that "install time" is something you can usually display in the reports tables where we have them (if you can't that should a a separate bug from displaying a count of them somewhere - as you know, one bug per distinct issue is always good).
Summary: Indicate which crashes come from distinct users → Indicate which crashes come from distinct installations
Created attachment 8740118 [details] Screen Shot 2016-04-11 at 4.01.11 PM.png Am I blind or is that segment missing from the new summaries on Signature Report?
> Am I blind or is that segment missing from the new summaries on Signature > Report? It's the "Installations" column in the "Product *" box.
> In the "Products" section of the new /signature report we have that count, > in the old /report/list report it's under "Crashes per Install". Aha. Thank you for the suggestion. Though it's a shame it shows up in the one box where you can't control the time period! > And note that "install time" is something you can usually display in the > reports tables where we have them Nice suggestion. Though it shows up as an integer like 1460126180, which is much harder to read than the nicely formatted date & time that you get in an individual crash report. So, the situation is a little better than I first thought, but there still is room for improvement.
(In reply to Nicholas Nethercote [:njn] from comment #4) > Nice suggestion. Though it shows up as an integer like 1460126180, which is > much harder to read than the nicely formatted date & time that you get in an > individual crash report. Ah, it does in the ES-powered cases. Can you file a separate bug to display it in a better format there? We should absolutely be able to do that in the UI.
> Can you file a separate bug to display it in a better format there? > We should absolutely be able to do that in the UI. I filed bug 1264153.
You need to log in before you can comment on or make changes to this bug.