Wedge

Public area => The Pub => Features => Topic started by: Arantor on November 25th, 2011, 04:29 PM

Title: Post moderation
Post by: Arantor on November 25th, 2011, 04:29 PM
Been thinking a lot about this over the last few days and discarded more UI designs than I can think of for it (eek), but I want to share how I envisage post moderation working from a configuration point of view, and on a related note, why it needs to be changed.

I'm not looking at the mechanics of how approval itself is managed, simply at how one configures what the rules for placing posts on moderation are.

So, what's wrong with SMF's post moderation configuration? Firstly, Core Features. Regular readers will know that I loathe and detest that page. It's nice enough but it's illogical for a regular user to deal with. The number of people who, in the last couple of years, have asked how to turn it on should be proof enough of that.

Then, assuming you turn it on, post moderation shares one dubious award with the calendar, in being the only areas of SMF whose access permissions are configured in three different interfaces (that all do the same job). Yes, that's right, there are three different ways you can set permissions for post moderation - the simple and the classic permissions interfaces, and its own custom page.[1]

And notwithstanding the fact that you have to actually then configure it. It would take a genius of Vizzini's stature[2] to configure post moderation right first time unless you know how it's implemented, since it's *really* not clear from the permissions page.

Here's the problem: nowhere in the permissions does it ever tell you that if the user, for any reason, has 'post... without requiring approval', that overrides 'post... but hide until approved'. Unless you farted around, you'd never come to that conclusion on your own. It's almost broken enough that I'd call it a bug but it was as designed, seemingly. (It's designed by programmers, rather than *for* users.)

Let me explain the problem of doing this on a fresh SMF install, and you're welcome to join in at home. Today's challenge: configure it so that regular users don't have moderation but new users with up to and including 5 posts are moderated.

There are, in fact, two ways to do this, both of which are convoluted.

1. Turn on post moderation in Core Features.
2. Making sure that the 0-post count group is left alone, create a new post count group that requires 5 posts, so that once a user has successfully posted 5 posts (and until they're approved, it won't affect their post count), they can have different permissions attached.
3. Admin > Members > Permissions > Settings > Enable permissions for post count based groups (tick) > save

Here's where the paths diverge. Here's path A:
A4: On the same page as above (Admin > Members > Permissions > Settings) also enable Enable the option to deny permissions
A5: Go to Admin > Members > Permissions > Board Permissions and for each profile (that allows posting) set the permissions up as follows: Regular members should have "Post new topics, without requiring approval" and "Post replies to topics, without requiring approval" enabled, while the 0-post count group should have those permissions *denied* and "Post new topics, but hide until approved" and "Post replies to topics, but hide until approved" in their place. Once the user leaves the 0-post count group for the 5-post count group, the other permissions are no longer denied.[3]

Or, path B. It doesn't require deny permissions but it does things another way.
B4: Go to Admin > Members > Permissions > Board Permissions. For Regular Members, set all the posting permissions to disallow. Then in the 0-post count group, give them "Post new topics, but hide until approved" and "Post replies to topics, but hide until approved" and for every other post count group, give them "Post new topics, without requiring approval" and "Post replies to topics, without requiring approval".[4]

Either way, banal and frustrating (and in fact, you still have to do the same thing using the other interface but it's actually slightly *more* confusing, not less there).


So, here's what I think instead. I haven't quite found a UI I'm happy with which is why there haven't been any screenshots or commits on it yet.

Post moderation is one of those things that you're going to be setting rules for. Think about it; every time you actually want to set post moderation, it's going to be because you want it for specific situations. Some of those will be rather broad but specifically defined (all users with under 5 posts), some will be very specific (all new topics in a certain board)

Doing that last one in SMF is a brainfuck, in fact.[5] So instead, why not some kind of interface that lets you set those rules?

In fact, you can boil down almost every single kind of post moderation situation to rules. Some of them are simple rules, some of them are rules with conditions, and some are rules with exceptions, some with both conditions and exceptions.

But really, that's what's needed. Something to construct rules like:

* moderate all posts "where the user has less than 5 approved posts"
* moderate all new topics in "board x"

Then you can get more fancy:
* moderate all new topics in "board x" where "user has less than 100 posts"
* moderate all new topics in "boards x, y and z" where "user has been registered less than a week"

Or even:
* moderate all posts in "all boards" where "user has less than 10 posts" except "board x" (maybe it's a chit chat board where spamming is allowed, I dunno)

That's the core ruleset, creating rules about the user, but there's no reason why it couldn't be extended to other things like creating conditions or exceptions based on groups, or other user characteristics.

Then, just for fun, I want to introduce non-member-based rules. For example, I want to have it able to moderate posts that automatically contain certain words. I also want it able to moderate posts if they contain a certain number of links. (And have exclusions for all those things based on members etc. If a member has 200 posts, I don't think they should be limited from posting three or four links in a page for example)


I don't think any of this is over the top, I just think this is complicated to get right in a UI context and I'm more conscious of doing that than I ever used to be.

It's interesting to note that there are circumstances which could 'theoretically' be simpler to construct in SMF's environment but the reality is that they're pretty few and far between.


Thoughts?
Posted: November 25th, 2011, 04:18 PM

Also as a footnote, let me add that I would be ditching the core features setup, and simply base it on whether there are any rules defined - no rules = post moderation is off.
 1. It actually gets its own page, template and images, while the calendar has to make do with using internal routines. But still, three places, and it's unique in how far the third page goes, elevating it in a class all of its own.
 2. Vizzini: Let me put it this way. Have you ever heard of Plato, Aristotle, Socrates? Morons. (If you don't recognise the line, do yourself a favour and look the film up. You won't regret it.)
 3. But now we have an extra membergroup that does absolutely nothing other than allow another group's permissions to expire.
 4. This means you still have the extra group, but at least the extra group is now doing something. This is also very fractionally faster, but harder to maintain as you have to set the new permission up on any new post count group you create.
 5. New board profile and everything. Notice I skipped over that small detail in the above, but it's true.
Title: Re: Post moderation
Post by: PantsManUK on November 25th, 2011, 05:45 PM
Not sure if this is what you are expecting to hear Pete, but I love the idea of "written" rules for post moderation. As you intimated, the current way (in SMF) is just a nuclear CF, and it can't go away quickly enough for my liking.

A "structured language" approach (not SQL per say, but that kind of approach, where you have a set of primitives to work from) would be far simpler for admins to grok IMO. Heck, I'd not even be terribly upset if you go down the Outlook Rules path and have a non-immutable "pre configured" set of primitives to plug together (a little upset, sure, but no more than that  ;))
Title: Re: Post moderation
Post by: Arantor on November 25th, 2011, 06:45 PM
The problem of going down any kind of structured language for that kind of thing is support, in that it would add a support burden, when a good UI can do everything that a simple structured language do, and that way I also don't have to cope with trying to deal with the same problem that bbcode vs WYSIWYG or SQL vs QBE is, namely trying to represent code in a non-code way.
Title: Re: Post moderation
Post by: Arantor on November 27th, 2011, 06:24 PM
Bump. Anyone see any problems with this approach, or things I hadn't thought of? Or, even, ideas about how it might look?
Title: Re: Post moderation
Post by: Nao on November 27th, 2011, 09:13 PM
Omg... I'm afraid it's a tldr for me :(
Title: Re: Post moderation
Post by: Arantor on November 27th, 2011, 09:30 PM
OK, tl:dr version.

SMF's setup is royally broken, it's beyond a nightmare to configure and it's so unintuitive, even meriting the description 'nuclear clusterfuck' though not from me.

My suggestion is that instead of basing on permissions, to base it on rules instead. So that the admin can configure that posts will be moderated if:
* user has made less than x posts
* user is posting in x board(s)
* user has been registered less than a given period of time
* post will be moderated if it contains x words
* post will be moderated if it contains x links

Any or all of the above should be usable, and should be able to be configured with conditions or exceptions, e.g. post will be moderated if the user has < 10 posts OR contains a link, EXCEPT in board x. For example.

The idea is to provide some method for admins to set the rules they want to use and do so without faffing about with different post count groups or permissions or stuff.

(Also, you'll have to excuse me. Me and some people went to an all-you-can-eat Chinese restaurant, and not only did I eat a lot, I had some beer for the first time in a lot of months. I'm a bit squiffy right now.)
Title: Re: Post moderation
Post by: billy2 on November 27th, 2011, 09:40 PM
Quote from Arantor on November 27th, 2011, 09:30 PM
OK, tl:dr version.

SMF's setup is royally broken, it's beyond a nightmare to configure and it's so unintuitive, even meriting the description 'nuclear clusterfuck' though not from me.

My suggestion is that instead of basing on permissions, to base it on rules instead. So that the admin can configure that posts will be moderated if:
* user has made less than x posts
* user is posting in x board(s)
* user has been registered less than a given period of time
* post will be moderated if it contains x words
* post will be moderated if it contains x links

Any or all of the above should be usable, and should be able to be configured with conditions or exceptions, e.g. post will be moderated if the user has < 10 posts OR contains a link, EXCEPT in board x. For example.
Anything but SMorgs system please!
The above appeals to me "user made less than x posts"
That is about all I need - mines a small group, and I meet em all, eventually.
Nice work Arantor
:)
Title: Re: Post moderation
Post by: Arantor on November 27th, 2011, 09:49 PM
Quote
Anything but SMorgs system please!
As a developer there is a certain logic to it, it's done internally to create the least extra management possible, as it reuses all of the internal permissions structure, but to non developers it's a brain-ache.
Quote
The above appeals to me "user made less than x posts"
This is, to me at least, the standard case. However, the system should be able to cope with all the various demands that would be placed upon it; for example I'd envisage it being able to cope with topic moderation in a single board without having to do a new permissions profile for that board (like sm.org's showcase board)
Title: Re: Post moderation
Post by: billy2 on November 28th, 2011, 04:55 PM
Quote
............to non developers it's a brain-ache.
Brain ache is an understatement.  :niark:
Quote
This is, to me at least, the standard case. However, the system should be able to cope with all the various demands.........
Of course - a very basic requirements for a very basic forum. Whereas large forums will undoubtedly need more control than I will ever use.
Any member pisses me off and I drive round to their house and break their legs
Beats the SMF system  :angel:
Title: Re: Post moderation
Post by: Arantor on November 28th, 2011, 07:18 PM
I still want it to be easy to use though, regardless of how big or little it gets... This is the part that's stumping me because while Outlook/Thunderbird filters are what I first thought of when thinking of this feature, I still find it a bit clunky to use and I want to design something better.
Title: Re: Post moderation
Post by: Arantor on November 29th, 2011, 10:46 PM
Hmm, I found another issue that I'm not sure how I want to resolve.

Sometimes, we will know in advance that the message will be moderated, e.g. post count or board rules, but if it's the case where it will be moderated based on content, how should that be dealt with?

On the one hand, I'm thinking we could take it back as if it's an error (but displayed otherwise) and list that it will be moderated and give the reasons why, or it can just go back round to the posts (as in Wedge, return to the post after posting is default) and be shown as moderated. The only thing is that I'd sort of like to show the *reason* why it was moderated, but that means storing that information somewhere...

Thoughts?
Title: Re: Post moderation
Post by: Arantor on December 5th, 2011, 04:59 PM
OK, getting down to brass tacks (I can wait on the above post for a while, not so bothered by that), I figured all the way along that I'd have to store it somehow and parse it meaningfully.

What I'm ultimately thinking is that I'm going to store the list of rules in an XML block, inside the DB. Now before anyone shouts how inefficient that is, consider it from my perspective.

It's clean to parse, it's not restricting the content to linear columns (and given the inclusive/exclusive nature of things, that's a good thing) and it means I can cleanly delineate and/or clauses in exceptions and rules without brackets which while human readable, do make it a lot more complex to process internally.

Performance of handling XML isn't bad actually, probably better than I'd be able to do with a custom language parser all told.

This is just off the cuff but covers what I'm thinking of. (It's not intended to be user-visible but I guess it could be for 'pro' users. I don't really intend to build a pro interface exactly. I'd rather build one great interface and be done with it, the idea is that this is internal use only. It probably wouldn't even be indented/line-broken normally.)

Code: [Select]
<rules>
  <rule for="posts">
    <criteria>
      <boards id="1" />
    </criteria>
  </rule>
</rules>

This would make all the new posts in board 1 be moderated, except for admins.

Code: [Select]
<rules>
  <rule for="topics">
    <criteria>
      <boards id="10" />
    </criteria>
    <criteria>
      <posts lt="10" />
    </criteria>
  </rule>
</rules>

New topics will be moderated if the board is id 10, OR if the user has less than 10 posts. That's why there's the criteria tag, to contain all the elements of a clause, because you could do things like this:

Code: [Select]
<rules>
  <rule for="topics">
    <criteria>
      <warning gt="40" />
      <boards except-id="10" />
    </criteria>
    <criteria>
      <boards id="1" />
    </criteria>
  </rule>
</rules>

This way, you'd post moderate any new topic created by a user if it's in board 1, OR if they have more than 40% warning, except in board 10. Perhaps that's a banned board, or a test board or similar. Either way, it allows you to create AND clauses within a rule. (This one is: (warning > 40 && board != 10) || board = 1, expressed in code.)

Hmm, now I look at it, I'm sort of wondering about writing it in PHP-like code, but I just feel that it would be easier to manipulate done in XML than it would in some kind of code. This is, after all, extensible (and suits how I'm envisaging plugins would interact though this too)

Thoughts?
Title: Re: Post moderation
Post by: Nao on December 5th, 2011, 07:19 PM
Performance isn't an issue. It's only called at post time right?
Title: Re: Post moderation
Post by: Arantor on December 5th, 2011, 07:34 PM
Yup, only at post saving time.
Title: Re: Post moderation
Post by: PantsManUK on December 6th, 2011, 12:37 PM
I'm quite a fan of XML via PHP, so you have my blessing.
Title: Re: Post moderation
Post by: Arantor on January 13th, 2012, 01:02 PM
OK, so I thought about this a bit more today, going to look at implementing some of it hopefully today as well.

The bit I thought about was the criteria tag. It occurred to me that you might not just want to moderate posts but blacklist some types of content too depending on other criteria.

Specifically turning it into something like:
<criteria for="moderate"> - if the criteria are met, moderate the post/topic

<criteria for="prevent"> - if the criteria are met, prevent the post from being made entirely

<criteria for="lock"> - automatically lock the topic if certain criteria are applied (e.g. post contains ^/lock AND user has permission to lock topic)

Just a thought, anyways.
Title: Re: Post moderation
Post by: Nao on January 13th, 2012, 02:15 PM
I can already smell the 'feature that will take weeks to develop'...

At this point, I'd be tempted to say, "postpone for Wedge 1.1"..?
Title: Re: Post moderation
Post by: Nao on January 15th, 2012, 11:19 PM
One thing that might be a good idea... How about showing, in the main menu (Admin section), the number of reported posts waiting to be read? And the number of posts and files requiring approval...
I don't think they're cached and accessible at any moment, though, so that would be the main thing to fix... Filling in this data.
Then, if we have 5 errors in the log, 3 posts waiting for moderation and 1 post waiting for approval, we could update the top-level admin number to 9 instead of 5. I think it would make a lot of sense... "9 events requiring your attention"...
Title: Re: Post moderation
Post by: Arantor on January 15th, 2012, 11:59 PM
Quote
One thing that might be a good idea... How about showing, in the main menu (Admin section), the number of reported posts waiting to be read? And the number of posts and files requiring approval...
Well, the number of posts is already shown in the header, but moving it to the menu would be good (provided that we totalled up all the notices and listed that x are error log, y are moderation items... etc)

As for number of things requiring approval, these are actually not cumulatively tracked, only on a per-board basis (in the board/topic themselves IIRC) and that would otherwise entail a query to get that. Thing is, you can't just have a site-wide count because it won't always be site-wide. Not all sites have all their boards open to all staff, and a moderated post in a very private board wouldn't necessarily be available to more regular moderators.
Title: Re: Post moderation
Post by: Nao on January 16th, 2012, 08:32 AM
I know it's not going to be site-wide, but I was thinking, for admins and global mods, they're always going to have the same numbers, aren't they..?
Title: Re: Post moderation
Post by: Arantor on January 16th, 2012, 08:35 AM
Admins, yes, global mods... maybe. Global mods don't have to be global, it's only implied, not enforced. They are by default, but beyond that, no guarantee.
Title: Re: Post moderation
Post by: Nao on January 16th, 2012, 11:47 AM
I just think that there should be an incentive for people to check the moderation area, in case they never do... Even if it's only the admin, it's already that.
Title: Re: Post moderation
Post by: billy2 on January 16th, 2012, 09:00 PM
Quote from Nao on January 16th, 2012, 11:47 AM
I just think that there should be an incentive for people to check the moderation area, in case they never do... Even if it's only the admin, it's already that.
+1
Title: Re: Post moderation
Post by: Arantor on February 9th, 2012, 10:27 AM
OK, so I took a crack at this last night and I debugged what was left this morning.

So right now I have the foundations in place - it's the UI that's missing. I created a temporary textbox in the admin panel and used that to indicate rules in the XML.

It's possible to construct rules on the following criteria: (and to have separate criteria for new posts vs new topics)
* in a given board or boards, or outside of given board or boards (e.g. able to say 'inside boards 1, 2 or 3' or 'all boards except board 4')
* user is or is not given id (e.g. do something if it is user id 1, do something if it is not user id 1)
* postcount is above/below a certain level (e.g. do something if count < 10, or count >= 20)
* warning level is above/below a certain level (e.g. do something if warning <= 10 or > 60)
* subject or body contain a given arbitrary regex (e.g. you can do something if a post contains profanity)
* user is in, or not in, certain groups (e.g. user is part of group 1 or not part of group 1)
* user has a given permission, or doesn't (e.g. do something if user has ability to lock any topic)

That last one is quite important as quite a few different tasks as available to be carried out.

* prevent the post being made at all (throws it back to the post editing screen with a warning about containing words that are not permitted; the warning itself is not actually specific to the content refused)
* place the post in moderation
* lock/unlock the topic
* pin/unpin the topic

To put it into context, you can specify - for example, that if the post contains ^/lock and the user has permission to lock any topic, that it will be locked automatically.

Rules are thus cumulative - a given rule can happily test for multiple criteria before acting. You can - as I tested this morning, for example - create a rule whereby if a non-admin posts the word 'fuck', the post is disallowed entirely - but the admin is free to post this happily.

IOW, all of the underlying behaviour set out in this topic is implemented and - thus far - seems to be working, though there's no UI (which has other stuff that needs to be managed where replacing the older setup)

Known caveats/issues:
* There's no logic for handling own vs any permissions at this point, and I'm not really sure it needs it - replying to own vs any is already a physical permission that's handled normally, it's mostly for the lock topic stuff and I'd argue if you're locking a topic based on something the user can do or not do, you probably shouldn't be giving it to everyone anyway.
* Can't yet handle based on number of replies (e.g. when 200 replies are in a topic, lock it)
* It's not possible to return a non-generic error on going back to the user.
* It's also not possible to do something like warn a user (but I'd argue that unless the post is going directly to moderation and nowhere else, the user probably shouldn't receive a warning)
* The outcome of rules action on a post is not logged at this point in time unless it's an existing moderation action (if you use the lock-topic option for example, the act of locking a topic will become logged but only because the existing code is still used)

It's a WIP from about 4 hours work :)


The one thing that bugs me is what to do about attachments. Right now the system just hijacks the original moderation, it doesn't deal with any of the permissions and it very definitely doesn't care about attachments (they would fall into the original code which is, make them unapproved unless they have permission to post attachments without worrying about approval) - but I'm honestly wondering whether it's actually an issue or not.

Do we actually care about attachments requiring approval? I'd argue that it should be tied to the post's approval status rather than the attachment itself being approved.
Title: Re: Post moderation
Post by: Nao on February 10th, 2012, 02:33 PM
Quote from Arantor on February 9th, 2012, 10:27 AM
Do we actually care about attachments requiring approval? I'd argue that it should be tied to the post's approval status rather than the attachment itself being approved.
As implied in another topic -- my official word on this is that I don't give a damn about attachment approval, and I agree with you. At 'worst', you can always add a rule saying 'if post has an attachment...'. Maybe even extra rules like 'attachment over X bytes', 'attached image over X pixels' or 'attachment that is of the image/doc/zip type'.
Title: Re: Post moderation
Post by: Arantor on February 10th, 2012, 02:34 PM
Quote
At 'worst', you can always add a rule saying 'if post has an attachment...'. Maybe even extra rules like 'attachment over X bytes', 'attached image over X pixels' or 'attachment that is of the image/doc/zip type'.
I actually hadn't thought of that, but it could be an interesting extra rule type.
Title: Re: Post moderation
Post by: Nao on February 10th, 2012, 03:15 PM
:)

Problem solved, then!
Title: Re: Post moderation
Post by: Arantor on February 10th, 2012, 03:23 PM
Well, I'm currently in the middle of stripping out attachment approval stuff, and while I'm not sure we need the 'post has attachments' rules at this stage, I'll certainly bear them in mind for later :)
Title: Re: Post moderation
Post by: Arantor on February 10th, 2012, 04:05 PM
Egad... now I realise the full horror of some of the internals.

The permissions I need to think about, because the permissions as set up can actually tell a user *before they try to post* that the post will be moderated. Need to figure out if there's a way I can quickly derive a subset that will be able to warn users ahead of schedule.

Meanwhile... {db_prefix}approval_queue is going to need some surgery, especially since it still actually has a calendar field in it >_<
Title: Re: Post moderation
Post by: Nao on June 15th, 2012, 09:03 AM
Re: the message just above... (Which I missed originally. It was unread --- there are some topics I keep for later and then they drop out of the 20 latest topics and I completely forget about them...)

I was working on fixing the post_thought permission to work 'as intended' with user warnings (as opposed to the odd hack I committed by mistake), and then found about user moderation (high warning level.) It applies post_unapproved_topics and such to them, which I think is exactly relevant to what you mentioned above.

So, yeah, I was already thinking that associating post moderation to moderation filters, while a notably good concept in your mind, wasn't going to cut it because I wanted to be able to post-moderate a message (i.e. make it unapproved even though it was already approved, for instance as a replacement to deletion, or simply as a way for multiple negative reports to hide it until a moderator decides it's okay and should be protected against reports or something) (yeah I know, it's a feature suggestion and I'm not going to do it... -_-), anyway, I was already thinking that, and now it's even more obvious to me -- post moderation should be *always* enabled on any topic that has at least one unapproved post (i.e. topics should have a 'post_moderation' field set to 1), and technically speaking, everywhere we access multiple topics in a single query (either by looking for a post_moderation setting, or just enabling unapproved post tests by default.)

Discuss. (<-- I feel at school all over again...)
Title: Re: Post moderation
Post by: Arantor on June 15th, 2012, 03:07 PM
OK, here's the deal from my perspective: I see absolutely no reason to unapprove a message.

Deletion the way we've talked about it has much the same effect but without the complications attached to it - you get to remove the post from general visibility, but leave it around for moderators - and it's obvious that a message has gone (something not currently obvious in either context)
Quote
It applies post_unapproved_topics and such to them, which I think is exactly relevant to what you mentioned above.
That particular permission is a remnant of the old setup, because I don't want post moderation to be tied to the obscure permissions setup in SMF which is why I designed the moderation rules setup - that's the whole point, because the old permissions setup is so messed up. Note that it is entirely a separate thing to the above.

In the old setup, post_unapproved_posts is the permission one assigns to users *instead of* the reply permission, so you have to not issue the reply permission and use this one.

The only reason it's still present (instead of using totally moderation filters) is because I couldn't yet figure out an efficient way to suggest to users that they might be moderated (as having that permission instead of the proper reply one would do)

But it is entirely separate to moderation being applied, or not.