This is getting annoying... I need some opinions here.
Part 1: the problem.
This is how Noisen.com does topic privacy:
- build a query checking the privacy state
- load board, with query above, and also load topic approval
- check topic approval manually. Actually, I didn't really bother with that, because Noisen doesn't use topic approvals much.
This is how Wedge.org does topic privacy:
- build a query checking privacy & approval states
- load board, with query above (if private or not approved, no topic, thus nothing to show)
The problem is with the query building. Privacy is fine, but approval is not, because if you're a moderator, you're exempt from having to check on approval states, since you're the one who's supposed to approve messages...
However, and the trick is here, the query check is built BEFORE the board is loaded, which also means it's built BEFORE permissions are loaded. Thus, allowedTo() will always return FALSE, making it impossible for moderators to see unapproved posts.
Part 2: how I solved it in late March. (And why it fails to work correctly.)
I simply removed the topic privacy/approval check in loadBoard, and figured I'd move it to Display.php (which I forgot to do). I fixed that today (not committed yet). However... It also means that if you have ";topic=..." in your URL, but are NOT viewing a topic page, the topic approval query won't be loaded. Oops!
I went for an alternative solution, which was to move the $topicinfo builder to its own loadTopic() function, and then automatically load it on all pages if the topic itself is shown NOT to have a 'default' privacy or approved setting. Then, I can easily close access to that topic if the user isn't allowed to see it.
Still, that makes it all very complicated, and it loads a lot of data for nothing.
Another (close) way to do it would be to accept that I'm spending an extra query on all pages with ";topic=" in them, but a SUPER FAST query like "SELECT 1 FROM topics AS t WHERE id_topic = $topic AND {query_see_topic}". That would only manipulate a single row in a single table, id_topic has an index so it's all fine, and query_see_topic only manipulates that row as well.
Part 3: what should I do?
Not worry about the extra query? It takes about a millisecond on my local install. (Still, I find it 'too much'.)
Move the $topicinfo builder to loadTopic, and call loadTopic if $topic is set, then not call it again from Display()..? (Problem: although it's a similar query to my simplified one, filling $topicinfo when you don't actually need that info is also overkill. Then again, maybe people would LIKE for $topicinfo to be systematically available when a current topic ID is available.)
Something else..?
Help :sob:
This topic was marked solved by 
