553678 - Create audit trail for publishing actions

Status: RESOLVED FIXED

(Websites :: plugins.mozilla.org, defect)

Description

[Austin King [:ozten]]

We should create a simple audit trail.

This will help for cases where users share auth info, as well as single user being able to debug issues.

Comment 1

[Ryan Doherty (:rdoherty)]

Attachment: Audit log mockup for viewing all events

Comment 2

[Ryan Doherty (:rdoherty)]

Attachment: Audit log mockup for homepage

Comment 3

[Ryan Doherty (:rdoherty)]

Attachment: Audit log for plugin detail page

Comment 4

[Ryan Doherty (:rdoherty)]

Specs and mockups attached. Les: can you take a look and let me know if you have questions/concerns?

Comment 5

[Les Orchard [:lorchard]]

Haven't had a chance to check this out until now... need to think about this a bit: 

Edits to plugins and releases aren't as granular as what the mockups show right now, at least not as far as the server is concerned.

The editing page submits a plugin and all its releases in one big updated JSON document at the time of save. A user could have added/deleted any number of releases, and changed any number of properties across all releases. 

So, without doing some kind of diff between old and new plugin documents, I can only record that a plugin was edited - not that a specific release was manipulated.

Also, an entire plugin and its complete collection of releases gets moved from sandbox to production - not just an individual release. Basically the same story as above.

Comment 6

[Les Orchard [:lorchard]]

Made some progress on this.  I just checked in a DB schema change in r70480, filed bug 579099 to get it updated on staging.

In order to not break stating, I'm holding back on checking into trunk until the DB change is made. But, the rest of the code so far is committed to github:

http://github.com/lmorchard/plugindir/commit/5d447bd84513c77ba30838674be212088838a33c

Comment 7

[Les Orchard [:lorchard]]

Since bug 579099 just got closed, I've committed the audit log code in r70718 to get it onto staging in the near future

Comment 8

[Les Orchard [:lorchard]]

Going to close this and say it's feature complete on staging for a first attempt. It could probably use some work after feedback, so feel free to reopen or file additional bugs

Comment 9

[Ryan Doherty (:rdoherty)]

(In reply to comment #8)
> Going to close this and say it's feature complete on staging for a first
> attempt. It could probably use some work after feedback, so feel free to reopen
> or file additional bugs

UI looks good, we definitely need a method of know what's changed though. I'll file separate bugs so it's easier to track. Thanks!

Comment 10

[Les Orchard [:lorchard]]

FWIW: With the code for this bug, each activity log event currently maintains the complete old and new states of the plugin and releases as JSON in text columns.  So, given a sufficient way to construct and display diffs between the two, we can show what's changed.

The alternative is to rethink the way editing is done entirely - which is not a horrible idea, just one that implies a lot of work well beyond activity tracking.