949463 - audit log

Status: RESOLVED WONTFIX

(Input :: General, defect, P3)

Description

[Will Kahn-Greene [:willkg] ET needinfo? me]

Bug #949461 covers adding the ability to delete responses. Before implementing that, we need audit log infrastructure so that we can keep track of who did what and when. That makes it easier to maintain metrics on activities so we can suss out problems.

For example, are we finding we're spending a lot of time deleting certain classes of spam? If so, can we nix it at the source instead?

Comment 1

[Will Kahn-Greene [:willkg] ET needinfo? me]

Moving this to 2014q2.

Plus, I'm making this a P1 because this is blocking future spam-alleviating work.

Comment 2

[Will Kahn-Greene [:willkg] ET needinfo? me]

Things we might be able to use:

https://github.com/etianen/django-reversion
https://github.com/treyhunner/django-simple-history

Comment 3

[Will Kahn-Greene [:willkg] ET needinfo? me]

Both of those django apps are pretty interesting. But if we're going to go with either of them, we will want to upgrade to Django 1.6 first.

Instead, I think I want to roll my own auditing infrastructure. I have the following use cases:

1. mine the data to see patterns and adjust spam-detection and other algorithms accordingly

2. metrics so I can see how the situation is changing over time in regards to how much work is being done, who's doing it and why -- this would let us set priorities on future development to alleviate problems

3. for a given response, see what changes were made to it, by whom and when -- this will make translation revisions easier to deal with when/if we add that

Anti-requirements:

1. I don't need unlimited undo functionality

2. I don't need to maintain history for all time--we should maintain history for like 6 months because anything beyond that is so old it's value is low

Comment 4

[Will Kahn-Greene [:willkg] ET needinfo? me]

Making this a 3-pointer since I think it'll take a few days to implement. It probably involves the following:

1. create an audit table model

2. write a mixin that on create, save and delete adds a record to the audit table

3. write some code so that you can see the history for a given response in the admin

4. write extensive tests

Comment 5

[Will Kahn-Greene [:willkg] ET needinfo? me]

Bumping this to 2014q3.

Comment 6

[Will Kahn-Greene [:willkg] ET needinfo? me]

Bumping this to 2015q1 because we're out of time for this quarter.

Comment 7

[Will Kahn-Greene [:willkg] ET needinfo? me]

We have a Journal app right now. We'd need to tie it to the Response table and write some views.

I WONTFIXd bug #949461 which was the impetus for this bug. Thus we can reduce the priority of this and push it off until we figure out what to do with spam and/or contributor-driven activities.

Comment 8

[Will Kahn-Greene [:willkg] ET needinfo? me]

I'm going to move this to 2015q2 since I want to work on better tools for this sort of thing.

Comment 9

[Will Kahn-Greene [:willkg] ET needinfo? me]

Bumping this out of the sprints altogether since it's not a priority.

Comment 10

[Osmose [:osmose, :mkelly]]

The Input service has been decommissioned (see bug 1315316) and has been replaced by a redirect to an external vendor (SurveyGizmo). I'm bulk WONTFIXing Input bugs that do not appear to be relevant anymore.