User:Archaeopteryx/UI for AMO-AMC action log

Like described in bug 255305 , addons.mozilla.org (AMO) has no really usable user-interface (UI) for its "approval log". For this reason, i began writing some Javascript-only code who let me the possibility to create a Greasemonkey script. Now I hope it will help the Remora developers implementing the following features, probably converting the code to PHP. I have a test file (with some approval data), so contact me if you want to get the source (#addons is a good place for this).

• itemhistory should become a special case of action log, removing uninteresting cols and showing only actions containing this add-on id. This data can be used to calculate the average time between the add-on submission which is useful for the reviewers especially reviewing new add-ons which are updated sometimes more than once a day and consume many reviews.

• During the redesign, action log filtered by (developer) user id could show his activity. It would be a nice-to-have (P5).

• A main issue is that the review process has two actions: The way in and the way out. At the moment, their is only the request relation between them, so the whole action log has to filtered for getting all data for a request. Adding two new fields for connecting there two events would reduce server load, the best would be a unique id-field and a 2D-array with actions and unique ids related to this request. This allows an easy calculating of the time add-ons had been waiting in queue for review.

• Their should be only one review for each file in the log (can be solved by filters) or AMO allows approving add-ons only for reviewer-selected applications (and OS?), the rest stays in queue.

• These columns should be available:
  • Add-on id
  • Request id
  • user id
  • unique action id
  • action class
  • action time
  • submission time
  • review / withdrawal time (called "review time")
  • time in queue
  • number of submissions for this add-on
  • number of positive reviews for this add-on
  • number of negative reviews for this add-on
  • approval rate for this add-on
  • number of reviews by this reviewer for this add-on
  • number of positive reviews by this reviewer for this add-on
  • number of negative reviews by this reviewer for this add-on
  • approval rate for this reviewer

• Comments sent to developers will be in the log, I hope, so these action classes are necessary:
  •  ? submission
  • + approval granted
  • - approval denied
  • W withdrawal by submitter
  • D add-on deleted by AMO admin
  • B blocked by AMO admin
  • U unblocked by AMO admin
  • C Comment sent to developer
  • E Edit of data for approving the add-on by submitter

• Filters / switches:
  • Filter add-on / request / user / unique ids like this: Positive and negative ids and ranges, for instance -2000-3000,2400-2600,-2500 would match all ids except 2000-2399, 2500 and 2601-3000
  • connect the add-on / request / user / unique ids with AND or OR condition
  • Time range, needs new data if range gets extended
  • Shown only selected actions
  • Group in and outs (submission isn't shown if add-on is reviewed)
  • calculate submission data for all available / only in this time / only actions which match the filters
  • calculate review data for all available / only in this time / only actions which match the filters

• Sorting should be done like in bugzilla with buttons in the table head and save user dependend (as cookie?)

• (Pseudo-)graphical analysis
  • To know how many add-ons are usually submitted and in the queue, a table with data, submission and reviews would be very nice which could be used for a bar chart and detecting problems with past major updates for applications when the developers all sent new versions of their add-ons, so we could learn how many review capacity would be needed additionally.
  • Allow statistics for a selected reviewer (P5)