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.