Closed Bug 908821 Opened 11 years ago Closed 10 years ago

Create admin UI for graphics adapter signature summary

Categories

(Socorro :: Webapp, task)

x86
macOS
task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: brandon, Assigned: peterbe)

References

Details

Attachments

(3 files)

We need to be able to correlate hex values to vendor names and chipset values. This should be an admin UI.

It should use javascript to take a hex name and correlate it to a known vendor name (but not attempt this for hex chipset values).
Brandon,

Can you perhaps provide some additional information in terms of the fields etc. that is needed for this UI? Also, info related to some sample hex values and vendor names that correlate with them. I believe I might have missed most if not all of this when I missed the stability work week.

So all additional information is much appreciated.
Flags: needinfo?(bsavage)
Let's talk about this first thing next week.
Flags: needinfo?(bsavage)
This needs a blocker bug about adding the middleware first.
Thinking about the UI for this it seems to me to simply consist of one input field for the search term and a table to display the results. Not sure if one can search only by hex or, if one can search by vendor name as well. If both, we can just add a select drop down so that the user can select on which field to search. So in essence:

Select field [x hex  ] find: [            ]

*Results for your query*

HexID | Vendor
--------------
1     | vendor
2     | vendor
3     | vendor

....
So, after talking to KaiRo on IRC, I realise that I might have had the wrong idea and that what we need here, is not a search function but an ability to add new records and display some detail about current records.

So, with regards to the fields for each entry, KaiRo mentioned adapter_hex, adapter_name, vendor_hex, vendor_name but, then I remember Brandon mentioning about "correlate hex values to vendor names and chipset values" in comment 1

From what I gather we want to dynamically find and populate the vendor_name when the vendor_hex is filled in, if it is already known, that is. What if it is not known already? I would think we would then want to expose a field where the user can enter this name, correct?

With regards to the table data we want to display, KaiRo mentioned the following:

"I would be happy with a display table of IDs and names (i.e. all rows in that table that lies underneath) and ..."

What I understand from that is that we want to display the data we currently have for the entered vendor_hex and that this will be user driven i.e. user types in vendor_hex and clicks 'view' or something along those lines, at which point we populate the table with the relevant data.

KaiRo also mentioned the following:

"in an ideal table structure, there would be one table with vendor_hex and vendor_name and one table with vendor_hex,adapter_hex,adapter_name (in which the combination of the two hex values would be unique)
but, I think we are going with the more simple structure where vendor_name is just redundant"

Is the "ideal" situation above possible or are we going to focus on the latter solution?
(In reply to Schalk Neethling [:espressive] from comment #5)
> From what I gather we want to dynamically find and populate the vendor_name
> when the vendor_hex is filled in, if it is already known, that is. What if
> it is not known already? I would think we would then want to expose a field
> where the user can enter this name, correct?

Yes.

(And note that I don't know what the actual field names are, I just used those names to illustrate what I mean.)

> What I understand from that is that we want to display the data we currently
> have for the entered vendor_hex and that this will be user driven i.e. user
> types in vendor_hex and clicks 'view' or something along those lines, at
> which point we populate the table with the relevant data.

That's more complex than I envisioned (I just would display the whole list) but it would work as well.
Oh, and I guess we may want the ability to edit an entry as well (to fix typos, or sometimes the same ship might get a name variant or clarification added, I guess).

> Is the "ideal" situation above possible or are we going to focus on the
> latter solution?

That's probably a question for Brandon.
Hey Brandon, any thoughts on this from your end? Thanks!
Flags: needinfo?(bsavage)
Hey Brandon, have you had some time to think about this one?
Assignee: schalk.neethling.bugs → peterbe
Component: Webapp → Middleware
Flags: needinfo?(bsavage)
Let's tidy this up a bit. This bug is about the admin UI. So it belongs to Socorro:Webapp.

However, like I said in #3, this bug depends on there being a middleware endpoint that the admin UI can draw data from. Has any such bug been filed? 

Let's keep the data part (middleware) distinct from the Admin UI (webapp). 

I've read the verbose comments here (thank you Schalk!) but I still don't grasp what it is we're trying to build. Like, the bigger picture. Sorry Kairo if I'm now the third person you have to explain the original requirement to.
Assignee: peterbe → nobody
Component: Middleware → Webapp
(In reply to Peter Bengtsson [:peterbe] from comment #9)
> However, like I said in #3, this bug depends on there being a middleware
> endpoint that the admin UI can draw data from. Has any such bug been filed?

AFAIK it hasn't.

> I've read the verbose comments here (thank you Schalk!) but I still don't
> grasp what it is we're trying to build. Like, the bigger picture. Sorry
> Kairo if I'm now the third person you have to explain the original
> requirement to.

OK, let's start this with the goal we have for the outcome of that:
If you look at the Graphics Adapter Report section of the Signature Summary in e.g. https://crash-stats.mozilla.com/report/list?signature=gfxContext%3A%3APushClipsToDT%28mozilla%3A%3Agfx%3A%3ADrawTarget%2A%29 you see a list of hex codes for vendor and adapter right now (if it's not broken, see bug 959601).
We'd like to map those hex codes to actual vendor and adapter names (and I think Brandon actually already implemented stuff there to map it if we have the data), and we'll need admin UI to fill out those mappings where they are missing.

Now, the vendor ID is unique, but AFAIK the adapter ID is only unique per vendor, so in theory we could potentially have the same adapter ID come up with a different vendor ID and mean a completely different graphics card/chip. So two independent tables to map this don't work and that's why we ended up talking of a single table to do the mapping, even if it will contain the vendor name redundantly - we should be able to prefill it in the admin UI when the hex ID entered matches a known one, and we can map vendors in the Signature Summary display when the full vendor+adapter match can't be made.
Depends on: 959601
959601 just got resolved. But I'm inclined to wait a little about working on this bug because the matview fix in 959601 is behind and needs to do some catching up. Otherwise I won't have any data with which to work with on this bug.
Assignee: nobody → peterbe
Here's the plan. (After speaking to Selena)

I'll make an admin UI thing that has 3 different functions. 

1) Upload of CSV file (by taking the latest from http://www.pcidatabase.com/reports.php?type=tab-delimeted)
2) Manual find and edit a single record
3) Manually add a new row

Regarding point 1, I think the upload of the should be able to not just update but if a particular adapter_hex and vendor_hex combo doesn't exist it adds it. 

Also, regarding the CSV file. I notice that there are a lot of cases where the adapter_name is "n/a". Those we'll simply skip and leave as is.
Status: NEW → ASSIGNED
Commit pushed to master at https://github.com/mozilla/socorro

https://github.com/mozilla/socorro/commit/1f7449ed62f6f0d0cd63d28f573a2ff1551729de
fixes bug 908821 - Admin UI for graphics adapters, r=rhelmer,selenamarie,AdrianGaudebert
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 75
Seems to be working just fine on stage after uploading the latest pcidatabase.com csv file.

Now we just need to remember to do this on prod once this feature has fully landed.
Before
After
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: