Wedge

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:

Hmm, perhaps a problem with how the attachment folder variable is built now that I've hardcoded all paths?

Hmm... Confirmed.

It's looking like the $topic 'creation' process never goes through {query_see_topic}, which is odd... I thought it did, really.
I mean, if a board is set to a specific group, attempting to access a topic in it will fail... So, I guess I need to add query_see_topic in the same query.
Can someone else look into it, to save me a few minutes? (or dozen minutes, depending on how it turns out...) I need to find where this one is. Possibly boardsAllowedTo or something. Have to jump to bed now... :-/

[Commit revision e6271d6]
Author: Nao (Signed-off)
Date: Sat, 12 Apr 2014 00:16:34 +0200
Stats: 4 files changed; +14 (insertions), -2 (deletions)

• Page replacements feature. (Admin)
• Spacinazi. (LICENSE, Media.german.php)

[Commit revision f424b87]
Author: Nao (Signed-off)
Date: Thu, 10 Apr 2014 23:50:19 +0200
Stats: 5 files changed; +7 (insertions), -7 (deletions)

• Spacinazi. (birthday, calendar, facebook)

---

[Commit revision 9251cc8]
Author: Nao (Signed-off)
Date: Thu, 10 Apr 2014 23:51:01 +0200
Stats: 1 file changed; +5 (insertions), -0 (deletion)

• Adding an htaccess cache file for the Facebook icon. Might seem a bit overkill, but Google PageSpeed likes this better. (facebook/templates/images/.htaccess)

Nope, I haven't been working on this... I usually rely on the original authors to fix problems (Dragooon, TE...), but feel free to work on them, just as I fixed the importer bug myself. ;)

I still rarely get the bug where I get a 10000px+ height on every post when loading the tab in the background. So it's not fully fixed.
I dunno if I should wait for Google to enable position sticky outside of the web platform flag. Not sure why they've been waiting so long for that... Something like 2 years! Even Firefox has yet to unprefix it... Why? Works so well for me...