Wedge

(17 files, 3KB)

Revision: 1464
Author: arantor
Date: 14 March 2012 15:52:13
Message:
! Removed "Show open report count in forum header" from moderation center preferences, seeing how we don't use it and it's driven by the menu instead. Important: if you previously had moderation settings set, it's going to be broken, so make sure to either clean out mod_prefs in the members table, or at least strip the leading value from something like 1|npgrw|1 to npgrw|1. (ModerationCenter.php, Profile-Modify.php, Report.php, ScheduledTasks.php, Subs.php, ModerationCenter.template.php, ModerationCenter language file)

! Removed some duplicate settings pertaining to drafts and added a note to another area to indicate that there were related settings available. (ManagePosts.php, ManageSettings.php, ManageSettings language file)

! Language string clean up (ManagePosts.php, ManageSettings.php, ManageSmileys.php, Admin+ManageSettings+ManageSmileys language files)
----
Modified : /trunk/Sources/ManagePosts.php
Modified : /trunk/Sources/ManageSettings.php
Modified : /trunk/Sources/ManageSmileys.php
Modified : /trunk/Sources/ModerationCenter.php
Modified : /trunk/Sources/Profile-Modify.php
Modified : /trunk/Sources/Report.php
Modified : /trunk/Sources/ScheduledTasks.php
Modified : /trunk/Sources/Subs.php
Modified : /trunk/Themes/default/ModerationCenter.template.php
Modified : /trunk/Themes/default/languages/Admin.english.php
Modified : /trunk/Themes/default/languages/Admin.french.php
Modified : /trunk/Themes/default/languages/ManageSettings.english.php
Modified : /trunk/Themes/default/languages/ManageSettings.french.php
Modified : /trunk/Themes/default/languages/ManageSmileys.english.php
Modified : /trunk/Themes/default/languages/ManageSmileys.french.php
Modified : /trunk/Themes/default/languages/ModerationCenter.english.php
Modified : /trunk/Themes/default/languages/ModerationCenter.french.php

Cool, that works for me. As long as the manage membergroups area doesn't allow access to contact lists, and contact lists don't allow for editing regular membergroups, I'm happy with that.It's a tough one to call, because there's more to it than topic privacy.

Namely, the way permissions are generally loaded would have to be rethought, as also whether we store the user's primary group in their user record too. What we'd end up doing is pushing the permissions check out of the loading the member's main record, and pushing it off to loadPermissions where we'd end up querying for user's groups LEFT JOIN permissions table for the permissions for those groups (since that's the only way to identify users in group 1, who don't have any entries in the permissions tables otherwise)

And of course you have to be careful not to join the contact lists for the purposes of permissions.

That part is mostly not a *huge* deal in performance, but where it will make a difference is topic privacy as you suspect. The problem though is that I don't know *how* it's going to make a difference. Honestly I don't think there's any better way than to benchmark it and see what happens.

What I do know is that it will have a beneficial impact on handling users who want to implement shared forums (multiple forums with a single members table) to not have the groups tied explicitly to users in the members table.While the UI aspect is the primary aspect, there is a slight performance gain to be had, because you don't have to go through and update folks' post count groups if you change them, which is an ugly query. It also means you don't have the same management issues in other respects... people that don't want post count groups have a habit of deleting them.

That might not sound like a problem but I've seen WAY too many cases where people delete all the post count groups. That wouldn't be so bad if it weren't for the problem that results where it fucks groups up leading to any user anywhere having full admin access because of the way the post count assignation query works.

I'd almost argue that the UI simplification it would bring for setting permissions would actually be enough.

OK, last point first, that's mostly historical. MySQL until later on didn't have subselects at all, and we even removed the block on subselects in the code. Not only that, but there's also a performance consideration - going back, the belief was fewer queries = better, and if you can't do subselects, the best method is to denormalise the data somewhat and do what was done.

As far as membergroups vs contact lists go, yes, they're fundamentally the same thing - lists of users - but membergroups have a lot more to them. There's multiple types of membergroups, they have badges, they have PM limits and permissions and *stuff* attached to them. They also get the distinction of having three separate elements of the members table (primary group, post count group, other groups)

I have no real objections to making contact lists and membergroups basically the same thing, provided that proper protections are taken to ensure that the two are not permitted to overlap (e.g. you can't edit or view a contact list anywhere you're not supposed to be able to and vice versa)

In fact, that reminds me of something I considered... I considered the possibility of ditching post count groups as they are currently implemented and reimplementing it separately so that they're not physical groups, but instead a separate entity (that has badges etc.) and rearranging permissions so that they're set up based on being granted at different post counts rather than by groups. Needs more thought to explain what I have in mind but it would simplify this setup and move it closer to what you're looking at doing.

Which is why it can't really be done that way :(

I have thought about doing a Pirate language pack, actually. There's just an awful lot of translation to do...

And, incidentally, a Pig Latin one.

So, let's say that something happens and the date of tomorrow is missed, what will be your next snide comment about things?

That's the thing that irritates me: it seems like the only things you say on here are comments about how you can't have Wedge yet, I don't see any other comments about any of the things we've done, nor suggestions for things we could do, only about how you 'lose hope' and so on.

Consider how much time *we've* invested, is it really too much to ask that you contribute something more than whining considering what you're going to get at the end of it?

Well, if it were expected to be used generally, it might be a candidate for inclusion into script.js, then it's just a matter of calling it?

That's the thing, it's about control, and who has what control.

The admin can set up who's in what groups, not the user. So it seems a bit odd to expect the user to use that setup, whereas if they're using buddy lists, they have control over who sees their topic.