« The Regular Members group
Privacy options
Image resizing for non-uploads »
Poll

Would you like to have topic privacy options in Wedge?

Yes -- everyone, just logged in users, and just the author.
4 (14.8%)
Yes -- everyone, just logged in users, just the author, and author's buddies (the regular SMF feature), even if it hurts performance a bit.
2 (7.4%)
Yes -- everyone, just logged in users, just the author, and author's contact lists (like buddies, but you can create multiple lists and put people in one or more of them), even if it hurts performance a bit.
16 (59.3%)
Yes -- everyone, or just me (i.e. just the ability to write drafts...)
0 (0%)
Yes, but I don't really care, I would never enable the feature on my forum.
1 (3.7%)
No, I don't care, and my users wouldn't either.
4 (14.8%)
Total Members Voted: 23

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Privacy options
« Reply #75, on February 21st, 2012, 08:48 AM »
Hmm... Thanks for the details. This definitely calls for a rewrite. OTOH, if it works... Don't fix it before the rest.

I'll be sticking with the original code and not give a damn about is_mod. :(

BUT, what I'll do:
- definitely will still use t.approved inside the query_see_topic,
- will only show that t.approved on !allowedTo('moderate_forum')[1], instead of !$user_info['is_admin']. It's probably a tad slower, well really by less than a nanosecond or so, but it's only done once (when query_see_topic is filled), so that's okay...

What I won't do, is check for a way to make my SQL faster. I'm still shitty when it comes to MySQL optimization, and I still remember how people complained that SMF's handling of t.approved made it slower etc etc, even with the table indexes and all... So I'm just going to leave it without an index, and ask for your help on this Pete.
 1. Actually, we could even do !allowedTo('moderate_board'), but ONLY if the $board variable is set... Right?

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Privacy options
« Reply #76, on February 21st, 2012, 08:58 AM »
Quote
Actually, we could even do !allowedTo('moderate_board'), but ONLY if the $board variable is set... Right?
This is one of the times I really get frustrated with SMF. Yes, it will work but it's going to confuse users. Global moderators have both moderate_forum and moderate_board, but most of the time people don't give new global moderator groups that extra permission (because moderate_forum should deal with it, right?)
Quote
OTOH, if it works... Don't fix it before the rest.
That depends on your definition of brokenness. The permissions system in SMF and currently in Wedge is functional. It is on a technical level, not broken, because it does actually work. However, it's sufficiently confusing and has sufficient loopholes like this which imply that it isn't as unbroken as it might seem, and is why I wrote my own from scratch in SimpleDesk.
Quote
will only show that t.approved on !allowedTo('moderate_forum')
That seems workable, because it is a valid concept that forum-wide moderators can see such posts (as opposed to being able to approve them) but I think it risks confusing users.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Privacy options
« Reply #77, on February 21st, 2012, 11:00 AM »
Quote from Arantor on February 21st, 2012, 08:58 AM
Quote
Actually, we could even do !allowedTo('moderate_board'), but ONLY if the $board variable is set... Right?
This is one of the times I really get frustrated with SMF. Yes, it will work but it's going to confuse users. Global moderators have both moderate_forum and moderate_board, but most of the time people don't give new global moderator groups that extra permission (because moderate_forum should deal with it, right?)
!allowedTo('moderate_forum') && (empty($board) || !allowedTo('moderate_board')) should account for that, shouldn't it...?

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Privacy options
« Reply #78, on February 21st, 2012, 03:51 PM »
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)

Nao

  • Dadman with a boy
  • Posts: 16,082

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Privacy options
« Reply #80, on February 21st, 2012, 06:03 PM »
In which case !allowedTo(array('moderate_forum', 'moderate_board')) should do the job ;)

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Privacy options
« Reply #81, on February 21st, 2012, 06:29 PM »
And even better:

!allowedTo(array('moderate_forum', 'moderate_board', 'approve_posts'))

Right? ;)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Privacy options
« Reply #82, on February 21st, 2012, 07:58 PM »
Yup, only needs one of those things and you get false back overall ;)

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Privacy options
« Reply #83, on February 22nd, 2012, 12:21 AM »
Considering that SSI.php starts with "$user_info['is_mod'] = false;", do you think it'd be safe/okay to replace false with allowedTo('moderate_forum')? It's better than nothing... (Would have to move the stuff to after the loadPermissions() call though, I guess.)
Or... just not bother?
Posted: February 22nd, 2012, 12:07 AM

I'm doing this in my setup.

$user_info['can_skip_approval'] = empty($settings['postmod_active']) || allowedTo(array('moderate_forum', 'moderate_board', 'approve_posts'));

Should be enough to get things done, including in SSI.php...

For instance, the ssi attachment code:

Code: [Select]
WHERE att.attachment_type = 0' . ($attachments_boards === array(0) ? '' : '
AND m.id_board IN ({array_int:boards_can_see})') . (!empty($attachment_ext) ? '
AND att.fileext IN ({array_string:attachment_ext})' : '') .
(!$settings['postmod_active'] || allowedTo('approve_posts') ? '' : '
AND t.approved = {int:is_approved}
AND m.approved = {int:is_approved}') . '

My version:

Code: [Select]
WHERE {query_see_topic}
AND att.attachment_type = 0' . ($attachments_boards === array(0) ? '' : '
AND m.id_board IN ({array_int:boards_can_see})') . (!empty($attachment_ext) ? '
AND att.fileext IN ({array_string:attachment_ext})' : '') .
(empty($user_info['can_skip_approval']) ? '
AND m.approved = 1' : '') . '

Please tell me if you find anything that's logically wrong.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Privacy options
« Reply #84, on February 22nd, 2012, 12:26 AM »
Quote
Considering that SSI.php starts with "$user_info['is_mod'] = false;", do you think it'd be safe/okay to replace false with allowedTo('moderate_forum')? It's better than nothing... (Would have to move the stuff to after the loadPermissions() call though, I guess.)
Or... just not bother?
That's out of convenience more than anything, because SSI won't load board permissions. Yes, it should be safe to reset that after loadPermissions() but I don't think it makes enough of a difference, I suspect anyone who cares enough will just do their own permissions tests anyway.
Quote
Please tell me if you find anything that's logically wrong.
I don't have a problem with that at all - because it satisfies my eternal whining about permissions not being attended to in a reasonable way :P

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Privacy options
« Reply #85, on February 22nd, 2012, 08:51 AM »
- Actually, given how little 'is_mod' is used throughout Wedge/SMF, I'm thinking it might actually be smarter to entirely remove it, if it's gonna bring only confusion... Or update it everywhere it shows up, to make it more useful.

- Eheh.

- Okay, a funny one... You said it'd be best to call boardsAllowedTo for full rights etc... And that it wasn't free so we couldn't really use it in SSI... Well, we can, using the mod cache. Look at Subs-Auth.php:

Code: [Select]
$_SESSION['mc'] = array(
'time' => time(),
// This looks a bit funny but protects against the login redirect.
'id' => $user_info['id'] && $user_info['name'] ? $user_info['id'] : 0,
// If you change the format of 'gq' and/or 'bq' make sure to adjust 'can_mod' in Load.php.
'gq' => $group_query,
'bq' => $board_query,
'ap' => boardsAllowedTo('approve_posts'),
'mb' => $boards_mod,
'mq' => $mod_query,
);

$user_info['mod_cache'] = $_SESSION['mc'];

The 'ap' is what we wanted. I already used the mod cache before -- just that it's so confusing, most people (including me) wouldn't think of it first!

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Privacy options
« Reply #86, on February 22nd, 2012, 10:04 AM »
Cripes, even I didn't know about that.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Privacy options
« Reply #87, on February 22nd, 2012, 10:16 AM »
I didn't remember. Then I found out that my noisen patch used it in an earlier version of query see topic. Look into it ;)

I think it warrants some reworking of the system...

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Privacy options
« Reply #88, on February 22nd, 2012, 10:25 AM »
I will look into it, need to go out for a bit first.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Privacy options
« Reply #89, on February 22nd, 2012, 01:55 PM »
The #1 issue with all this is that there are too many things to go through if you don't know better. (Heck, even if you know better...)

- Have I got approve_posts permission on this board? (allowedTo('approve_posts'), $user_info['mod_cache']['ap'])
- Have I got moderate_board permission on this board? (allowedTo('moderate_board'), $user_info['mod_cache']['bq'])
- Am I a moderator on this board? ($user_info['is_mod'], $user_info['can_mod'], $user_info['mod_cache']['bm'])

And so on. At this point, it becomes really unclear what 'can_mod' is for, why 'is_mod' is reset in SSI when really it could be using the mod_cache, etc...
There's a strong, huge feeling that SMF has been overhauled many times when it comes to permissions, and once again different developers had their own idea of how to make it 'simpler', and failed to make them commonly used. That mod_cache thing is saddening, because it's exactly what's needed (a session cache of some expensive queries), but also it doesn't save everything it could ($boards meaning the list of boards you have moderate_board on, is not in it, even though it's calculated), it's not clear what the difference between being a board moderator and having moderate_board permission is, and finally I'd tend to say that using acronyms for permission names is a bit silly. mod_cache is only accessed exactly 30 times in the entire codebase (plus the 3 times it's set up), so it's not like it's so complicated to type $user_info['mod_cache']['board_query'] instead of $user_info['mod_cache']['bq']... Plus, it makes the thing easier to understand.

Have you got some thoughts to share on all of this, Pete..?
« The Regular Members group
Image resizing for non-uploads »