Wedge

There isn't a master setting any more :P

Quote

...I don't get it. If testing for m.approved=0, m.approved=1 or nothing at all, same performance. How can it be, since in the last case we're sure not to ever use the approved index...?

Putting the WHERE clause in is more expensive than not having it. If it isn't necessary to test it, don't have that clause in.

Oh, it works. The only thing that doesn't work properly (out of what is shown) is the textual matches, when you're using any of the HTML special characters, they get encoded properly for sending, are stored properly but the regex doesn't apply them properly at this point.

Quote

Heck, can anyone actually view an unapproved topic if they don't have permission to, but they know its ID? Because I can't see any code to stop them in Display.php! Actually noisen.com/wedge.org do have such code, that's where it gets funny. Well, they don't add approved flags to the mix but at least they support 'justme' privacy.

Now you understand why I was so fussy about the whole loadBoard thing. loadBoard is supposed to deal with that.

I know in SMF if you have a topic whose ID you know but it's moderated, you can only see it if you're the owner or a moderator with suitable permissions, but it's enforced by loadBoard as far as I can tell, not by Display. Display assumes to a point that if you can see the board, you can see the topic.

Sadly, no. If it never checks for being enabled or not, but always checks anyway, there's a performance hit attached. It's just not one you can avoid by turning the feature off...

That's really more of an SMF issue; in their case, post moderation is a very specific feature, disabled by default, so you get penalised by default whether you use it or not.

In our case, I'm really expecting users to use it more than SMF users make use of post moderation,

They get their name on the linktree, on the board index and their badge is altered on the fly.

They're also, silently, added to group 3 when in that board, which means you can do permissions checking in that respect.

Again that's the historical aspect. It was never supposed to be entirely based on the permission but showing you the area if you could do at least one thing there - much as you get access to the admin tab if you can do any of the admin like features (e.g. news, manage permissions, manage membergroups etc.)

Quote

And the ONLY place it's used (although it's repeated a couple of times), is whether the user can see the Warning button on a userbox...
That smells like "REMOVE!" to me...

DOOOO EEEET. Basically, yeah, it was a historical thing that was never quite realised the way it was intended.

Which is virtually how 1.1.x did it, except it still created proper per-board permissions rather than having discrete profiles.

I wasn't very clear on that point. I knew of the mod cache subsystem, but I wasn't aware of all the details and precisely what it covered - namely the ap element.

But combine the places it is used, with the knowledge of what it actually contains and it becomes rather clear (to me at least) what it was intended for. It's like having 3/4 of the pieces of the puzzle and then suddenly you find that last piece and it all suddenly makes sense.

Oh, it's horribly confusing, which is why I didn't even implement it in SimpleDesk but left it simply as the ability to copy a role, rather than to mirror it.

The other thing with the mirrored permissions is that most mods for SMF never used them properly - not even SimpleDesk got it right, and I don't believe Aeva did either.

(Case in point, I reordered all the groups on my one site to have a bunch of groups, one per user, for unique badges/titles because I'm like that. Each of these new groups was based on a higher group that controlled permissions - but neither SD nor Aeva responds to the child groups properly and I had to end up assigning the permissions in both to all the groups, not just the parent group.)

I like the idea but I'm concerned it would potentially lead to greater complexity.

I'm also not sure you can actually optimise it *that* far, though, and there's a lot of places that use ?topic in the URL to handle permission loading.

Storing it in the topics table is going to hurt. Storing it outside the topics table is going to hurt too, just in a different way, and neither is lightly ignored.

Putting it in the table as a textual id with a list of groups means the query becomes WHERE t.privacy = something OR (t.privacy = 'groups' AND FIND_IN_SET(...)) which is expensive enough.

Meanwhile, putting it in a separate table means either a subquery, or a join, both of which being applied to potentially every topic in a board (or worse) to validate access is going to get very unfriendly very quickly.

I don't think you're crazy, but I also don't think there's a good way to achieve this meaningfully for topics.

Regarding applying it to thoughts, I'd actually be inclined to handle that in permissions (permission to post, permission to read, permission to read replies, permission to reply, etc.)