Multiple flags per reviewmoderation

[Michael Nelson]

In addition to Review.hide, we need a status to the ModerationRequest (ie. New, Confirmed, Rejected etc.), as well as the ability to flag a review multiple times, recording the details.

Also, it might be worth considering one of the generic django-moderation apps that are around (ie. https://github.com/dominno/django-moderation )

[Michael Nelson (michael.nelson)]

I've just spent some time investigating both django-moderation and django-gatekeeper.

Both have lots of useful functionality, but also miss one-or-two features we'd need.

django-moderation
===============
url: https://github.com/dominno/django-moderation
Overview: The "normal" use-case with this app is that new objects require moderation by default. Although this behaviour can be overridden, it seems that there is currently no field on the ModeratedObject model to store who flagged/requested the moderation. Otherwise this app has most features we'd need (and some that we'd not need - such as re-moderating when an object is edited and displaying the changes).

django-gatekeeper
===============
url: https://github.com/sunlightlabs/django-gatekeeper
Overview: This app *does* support flagging - great, seems to match our requirements and is very configurable, but doesn't support a reason for flagging in its model.

So we could either branch and contribute to one of these, or start with the simple functionality that we already have (perhaps moving it into a separate django app though) and learn from the work of these other projects. If in the end we can replace our app with one of those - great.

[Michael Nelson (michael.nelson)]

After looking more closely at django-gatekeeper I think we can use it - see the linked branch.

It has the following differences from our original model:
 1) moderation objects are *always* created when a review is created - which makes sense when we use the automoderation (blacklisted words or even askimet).
 2) When flagging a review, it doesn't have separate fields for the flag category (eg. "SPAM") and the textual reason entered by the flagger ("I consider the links here spam."). So you'll see I'm currently storing both in the moderation_reason field as "Flagged by userjoe for 'SPAM': I consider the links here spam.". I think this is OK as long as we're intending the category to be something helping the flagger - ie. we won't be able to sort by flag category etc.

If these differences are unwanted, then we can create our own moderation app (just start by moving the ModerationRequest object out and begin building in the features of django-moderation/django-gatekeeper that we want).

[Matthew Paul Thomas (mpt)]

Does that mean we can have both flagging, and optional pre-publication moderation? I think we might want to start out with pre-publication moderation turned on, and then turn it off in a month or two if (a) the volume gets too much for manual moderation or (b) we're confident we have automatic filters for as much bad stuff as we can. And then turn it back on temporarily if anyone ever tries to flood the review service.

As for the original question about Review.hide, with a sufficiently large number of users, people will flag reviews for all kinds of spurious reasons, maybe even by accident. It would then be the job of a moderator to look not at every flagged review, but at those reviews that have been flagged the most times.

[Michael Nelson (michael.nelson)]

On Thu, Nov 25, 2010 at 5:23 PM, Matthew Paul Thomas <email address hidden> wrote:
> Does that mean we can have both flagging, and optional pre-publication
> moderation? I think we might want to start out with pre-publication
> moderation turned on, and then turn it off in a month or two if (a) the
> volume gets too much for manual moderation or (b) we're confident we
> have automatic filters for as much bad stuff as we can. And then turn it
> back on temporarily if anyone ever tries to flood the review service.

Yep - indeed. Gatekeeper has simple setting to enable that. That is,
it would require an update to the configuration branch (it would be a
nice improvement to gatekeeper if it was an option in the admin
web-interface).

>
> As for the original question about Review.hide, with a sufficiently
> large number of users, people will flag reviews for all kinds of
> spurious reasons, maybe even by accident. It would then be the job of a
> moderator to look not at every flagged review, but at those reviews that
> have been flagged the most times.

Yep, so with the current implementation (in the above branch), I've
ensured that:

1) If the review has not been manually approved, then flagging will
move it to the pending state (ie. hiding it awaiting moderation).
2) If the review *has* already been manually approved, then flagging
will not change it's state, but it will be flagged for moderation
(perhaps a different queue - up to us).

The current implementation of gatekeeper won't allow us to provide the
flagged reviews that have been flagged most often (although looking at
a review moderation, you'll be able to see all the flag-comments).
Enabling records for each flag event is an an improvement which we
could contribute back upstream (or if necessary, fork and improve).
I'll start some discussion there with the author.

[Michael Nelson (michael.nelson)]

FTR, created the following issues to start conversations on django-gatekeeper:

 * https://github.com/sunlightlabs/django-gatekeeper/issues/issue/6 - Cannot see multiple flaggings of the one item
 * https://github.com/sunlightlabs/django-gatekeeper/issues/issue/5 - ModerationObject always created even for default APPROVED

[Michael Nelson (michael.nelson)]

On Fri, Nov 26, 2010 at 8:40 AM, Michael Nelson
<email address hidden> wrote:
> The current implementation of gatekeeper won't allow us to provide the
> flagged reviews that have been flagged most often (although looking at
> a review moderation, you'll be able to see all the flag-comments).

Actually, without a workaround, gatekeeper overwrites the
moderation_reason (rather than appending), so the flag comments will
when its default approve/reject methods are called.

Updating the branch now to work around this.

> Enabling records for each flag event is an an improvement which we
> could contribute back upstream (or if necessary, fork and improve).
> I'll start some discussion there with the author.
>

[Matthew Paul Thomas (mpt)]

Excellent, thank you.

[Michael Nelson (michael.nelson)]

After discussing the restrictions of both django-gatekeeper (we weren't happy with the fudges we needed to include in the above branch) and django-moderation, we're going to instead just refactor the current model already in rnr (ie. to separate flagging from the moderation request so that we can record multiple flagging events per moderation request), and gradually add the extra functionality as required

Moving the code out to a separate django app would obviously be nice eventually too.