Wedge

Yup, only needs one of those things and you get false back overall ;)

That should do, yes. Mind you, you don't really need to validate that you're in a board, moderate_board will only be set if you're in a board anyway and have the permission (as it can't be set otherwise without mangling the DB directly)

Yes. Group 3 is a special group. Specifically, group 3 is the group whereby you're added into if you're a board moderator.This is where the brainfuck in SMF begins.

What is a moderator? How do you define a moderator? A moderator is someone who has the permission to moderate_forum or moderate_board. Nothing more. You can, quite readily, create a moderator who has actually less powers than a regular user if you so wish, because you can assign permissions to it.

That's one of the underlying problems in SMF, really. You have the admin group, it has special behaviour because it's the admin group. (It has quite a bit of special behaviour, in fact, not just board access shortcuts, permissions overrides but it's also the only group defined internally as protected, though you can create others, and even then I think group 1 is still considered special in ways other groups are not.)

But the global moderator group is not in any way special, except for the fact it exists in a default installation. Now, in SMF 2.0 (certainly prior to RC4), the group was actually very slightly special, in that it had permissions that were granted and in the tables, but that were nominally disabled (the post moderation permissions were still granted, even if post moderation was disabled) so it gave them access to the mod center even when theoretically they shouldn't have had it. But it was only special because of a buggy permissions loader, not because the group is special itself.That's just it, it is not the same.

Create a new group, give it all the same permissions as global moderator, specifically moderate_forum. What's the difference between that new group and the original global moderator? Nothing. There is (or at least, should be) no difference whatsoever between that new group and group 2, except for id and irrelevant details like name.

This is what I mean: you can create new groups that behave identically to the global moderator role, and they will behave identically in every single way. But you cannot create a new admin group or a new board moderator group that will behave identically.

You can create groups that emulate their functionality, in that you can create a new group that has every permission in it, is protected etc - but it will not be the same as the real admin group. You can create a group that only has moderate_board permissions in a certain permissions profile, and only apply that profile to a single board, which is the mechanical equivalent to a board moderator as far as permissions go, but it's not the same as a real board moderator.

Groups 1 and 3 are special groups (just as -1 and 0 are special groups as far as permission handling goes) but there is nothing unique about 2 other than it exists. And you cannot and should not rely on it existing, whereas groups 1 and 3 must exist.

This site does not have a group 2 at all. But everything works nonetheless - because SMF was designed not to rely on group 2's existence, and that's been true for at least the 2.0 series.

(Actually, that's not *strictly* true. There are a few places where such things are used but for the most bizarre reasons, namely:

* the query on ManageBoards.php line 469 or so, which says > board_moderator_id (3) or == global_moderator_id (2), when they could have just done > admin (1) && != board_moderator_id (3) for the same real functionality

* ManageMembergroups.php lines 558 and 994, same reason, as is the if() on line 707, though the code on line 785 is something you'd want to do for other groups, not just group 2 if you perform that operation, and 967-968 allows you to delete or modify the group if it is = 2 or any post count group that isn't the 0-post count group

* ManageMedia.php lines 766 and 1745, same as above

That leaves the credits as the only place I can find that explicitly relies on group 2 being, well, group 2.)

Yup, I'm not arguing that it's a mess. But this is why I'm overthinking things - because we need to figure out how much of it to salvage and how much actually needs rewriting.

There's the rub. Post moderation is not that common on Noisen. Meaning that you may or may not have noticed whether there were any glitches attached to it with topic privacy, e.g. moderated items being visible or not visible.That's the point, they may or may not be able to. Generally, yes, they will, but it's possible to construct a setup where a moderator can moderate but not view unapproved posts - since you can set up per-board profiles, you can do it on a per-group-per-board basis if you wish.Does Wedge itself require SSI for the welcome page? (If it does we need to fix that.)

In any case, here's the problem. How do you know, when viewing the front page, who is a moderator and who isn't? approve_posts won't be loaded at all. The only way to determine for certain is to run boardsAllowedTo() and then query filtering on those.

But that's the thing... is it the safe solution? It's fine in SSI, sure, but what about recent, unread, unreadreplies... places where you would likely need to be made aware of unapproved posts...?

That's great until you change it, because then it's whatever queries you have to update the board information, then a query for every single user that it directly affects. To take sm.org as an example that means you'd have to issue ~50 queries.

approve_posts is a board level permission, not a global one and in SSI, it isn't loaded. Nor is it loaded for search, recent, unread or indeed anywhere that doesn't explicitly contain topic= or board= in the URL string, so it will always return false, with the exception of true for administrators due to the hard-wiring of always-return-true-for-group-1-users.

Does SSI need to support post moderation? That's a good question. My gut instinct says that for the purpose for which post moderation is normally applied and where SSI is used, it's actually not necessary to worry about and that it would actually likely confuse users rather than reassure them.

The original SSI code does this - excludes unmoderated posts even if the user is otherwise empowered to see them, so in those cases I wouldn't worry about testing for approve_posts or is-owner, I'd simply validate that the post is approved or not (and subject to privacy anyway)

I didn't list a specific query, more the fact that those are the rules for topic visibility.

We didn't decide anything specific re where qst should go, though from a convenience perspective, being just a WHERE condition would be pretty handy, especially since being a subselect it wouldn't interfere with the criteria of the parent query so you wouldn't have to ensure t was aliased or anything.