Logs for actions at post- rather than candidate- level

mysociety / yournextrepresentative

A website for crowd-sourcing structured election candidate data

https://candidates.democracyclub.org.uk/

GNU Affero General Public License v3.0

56 stars 21 forks source link

Logs for actions at post- rather than candidate- level #884

Open jf1 opened 8 years ago

jf1 commented 8 years ago

Changes to candidates are logged and displayed on each candidate's page, however neither locking a post nor uploading its SoPN are displayed on the post's page. It seems that locking is logged but uploading isn't.

Previously other posts had errors so I was curious to know how they'd arisen. Tonight this post was locked despite there being no SoPN, so it'd be useful to know who locked the post or removed the SoPN. This highlights another potential issue - should it be possible to lock a post if there's no SoPN?

It may also be useful to be able to add a note to the logs and/or flag a post, candidate or user action for inspection by a site admin; not to make a scene out of the occasional genuine mistake, but to provide way to track vandalism or frequent mistakes - or more positively, to highlight which users have made so few mistakes that they should be considered for elevated privileges.

wfdd commented 8 years ago

As a first step, the API could allow filtering logged actions by action_type, source and user. The post log entries aren't actually associated with a post; constituency locking and unlocking was just kinda shoehorned into the log by reappropriating the source field.

See also #372 and #373.

mhl commented 8 years ago

LoggedAction does at least have a post field now in the DC fork. I think the following steps are needed:

[ ] Add the post field to LoggedAction (probably by cherry-picking 1aa03a2ee993348ca6)
[ ] Update the code that records the lock / unlock
[ ] Add a data migration that looks at all the constituency lock / unlocked LoggedActions and set the post field on them
[ ] Add filters to the logged action endpoint of the API, as @wfdd suggests
[ ] Possibly do the same for other actions, e.g. set-candidate-elected and set-candidate-not-elected
[ ] Include a "recent changes" list at the bottom of each post page

jf1 commented 8 years ago

Might be useful to factor in or be mindful of the potential to store post-level values for 'incumbent person' and 'incumbent party' mentioned in https://github.com/mysociety/yournextrepresentative/issues/901