Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Nao
6361
Plugins / Re: Edit History
« on February 22nd, 2012, 10:18 AM »
Oh I get it now! IPod -> no visible right side of the pic. So I missed that.
6362
Features / Re: Privacy options
« 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...
6363
Features / Re: Privacy options
« 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!
6364
Plugins / Re: Edit History
« on February 22nd, 2012, 07:17 AM »
Quote from Arantor on February 22nd, 2012, 12:44 AM
The history of a post is pretty post centric?
So you're not using the user menu then? So. Action menu maybe?
6365
Plugins / Re: Edit History
« on February 22nd, 2012, 12:36 AM »
Isn't it a usercentric menu rather than post centric?

Yeah it's only semantics....
6366
Features / Re: Privacy options
« 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.
6367
Features / Re: Privacy options
« on February 21st, 2012, 06:29 PM »
And even better:

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

Right? ;)
6368
Features / Re: New revs
« on February 21st, 2012, 06:27 PM »
rev 1372
(6 files, 3kb)

* Now vertically centering the thought action buttons. Yay. (index.member.css)

! Fixed whatever glitch I could find remaining in Warm and Wuthering. I'm not exactly sure why I was using an !important on .catbase, hopefully it really was no longer needed. (index.css, Warm/index.css)

! Minor tidbits, like the Wedge select box no longer requiring non-breakable spaces on long lists to avoid hiding their right side. (Themes.php, ManageMedia.template.php, Profile.template.php)
6369
Features / Re: Privacy options
« on February 21st, 2012, 05:36 PM »
Oh yeah, right!
6370
Features / Re: Privacy options
« 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...?
6371
Features / Re: Privacy options
« 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?
6372
Features / Re: Privacy options
« on February 21st, 2012, 12:20 AM »
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... ;)
Quote from Arantor on February 21st, 2012, 12:12 AM
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.
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.
Quote
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.
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...
6373
Features / Re: Privacy options
« on February 21st, 2012, 12:04 AM »
I just noticed that SMF/Wedge never actually (easily) disclose the fact that someone is a global mod...
There's $user_info['is_admin'] which is based on in_array(1, $user_info['groups']), but there's no in_array(2, $user_info['groups']) in the entire codebase -- there's an $user_info['is_mod'] setting, but it's only set within a given board, according to local board moderator settings.

To me, it would make a lot of sense to set $user_info['is_mod'] at the same time as 'is_admin', and then do a logical OR on it when we're inside a board to add the board moderators...

What do you think?
6374
The Pub / Re: Logo Madness
« on February 20th, 2012, 10:20 PM »
Something like this, then, following your remarks..?
(Did the logo a few days ago but forgot to post...)

I think I prefer a 'simpler' logo, myself.
6375
Features / Re: Privacy options
« on February 20th, 2012, 09:58 PM »
No i dont need ssi but it's easier to get the list of topics this way.

Also. Why wouldn't global mods be automatically able to approve posts?