Wedge

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.

So. Just give up...?

No... just requires more effort in solving the problem. I don't have any answers for this right now :(

I mean, give up on board moderators, especially in SSI, and simply focus on replacing t.approved=1 with {query_see_topic} everywhere it shows up..? That would seem like the 'safe' solution, at this point...

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...?

I don't know. If I don't get started it'll never get done.

And, really, Noisen.com has been running fine for 4 years with these privacy settings. I could simply get them straight from Noisen, but I just wanted to be 'cleaner' and move t.approved to query_see_topic... It's really the only difference. I don't think it'll hurt in any way.

You already know that, Pete, but sometimes you tend to overthink it ;)

Yes, but how often do you use post moderation? How often are there board (or global) moderators who can approve posts? How often are these things viewed outside of boards?

Yes, I also tend to overthink things but for something like this, there is a part of me that feels I have to because it can have all sorts of nasty consequences.

It's not about me...Can't they, all?I don't know, but I know that Wedge.org uses SSI to load the latest post list... And for that reason, I'd like for my moderators to be able to see unapproved posts from the list...But technically, if we don't do anything, it's worse than doing anything at all...

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.

The only reason they can is because the standard profile gives them that permission in each board, not because of anything else.

The whole point is that global moderator is not a magic group. 1 is a magic group, 3 is a magic group but there is absolutely nothing special about 2, you could even delete it and things should still work normally. That's why we don't do a test for group 2. On this site, for examine, it would magically ignore me as being a global moderator, which means you end up relying on an assumption that just does not fly.

The only way that works is essentially if you neuter the ability to create global mods just as you cannot create another admin group. You can make it mostly the same but not actually the same for real.

One of the issues with topic privacy tests being put inside a 'postmod_active' test is exactly that -- topic privacy won't work at all if you didn't enable post moderation. Which didn't occur to me simply because I always enable it...
Ouch, another headache... ;)Oh, I see... But aren't people in group 3 also linked to a specific set of permissions...?!
To me, if $user_info['is_mod'] is set on board moderators, if that very variable exists, it should mean to be used, regardless of actual permissions given to the group...
Otherwise, I don't really see the point. And it's exactly the same for global moderators. If one is in that particular group, no matter the permissions, they *should* be able to moderate everything on the forum.I don't know what this means. What I do know, is that something's wrong in that respect. Perhaps it's due to SMF2's permission profile system. But giving too much possibilities for each membergroup is a failure to me. It's simply so complicated to manage...

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.