Wedge

Public area => The Pub => Features => Topic started by: Nao on March 15th, 2012, 08:47 AM

Title: The Regular Members group
Post by: Nao on March 15th, 2012, 08:47 AM
I've always had a love/hate relationship with the Regular Members membergroup.
In fact, I was so wary of it for many years, that I had hardcoded the Register page to automatically put new members into a custom membergroup, so that I wouldn't have to deal with that group. Little did I know at the time that it was simply a convention for a virtual membergroup numbered '0'.

Now, because if you apply a primary membergroup to someone, they will lose their '0' group membership, they might lose permissions that were only given to regular members. This might be 'as designed', but it isn't terribly obvious in the permissions section that 'regular members' doesn't ENCOMPASS all other groups, and that instead it represents group 0.

So, I modified the Profile template to actually show a Help icon next to Primary Membergroup, with a popup explaining what it does and what happens if you assign something to it.
Now, I'll commit it this way because it took me half an hour of my time and I'm the doc doc, but I was thinking... How about we simply list Regular Members as a 'normal' membergroup, i.e. in Primary Membergroup we list "Regular Members (default)", and in Additional Membergroups we list the same, but hidden by default, and only shown if the Primary membergroup isn't 0...?
I'm sure we can add '0' to the list of additional membergroups, can't we...?
Title: Re: The Regular Members group
Post by: Arantor on March 15th, 2012, 02:35 PM
The whole Regular Members thing is a massive headache from both a technical and logistical point of view.

A simple band-aid, as suggested by Unknown years ago would be to start off by renaming it to Ungrouped Members. At least then it would be accurate rather than vague and possibly misleading like it is now.

There is no technical reason why we can't add 'Regular Members' to the additional groups, other than the fact it should be completely unnecessary. I'm not arguing that it's broken but I don't think that's the solution.
Title: Re: The Regular Members group
Post by: Nao on March 15th, 2012, 03:57 PM
Actually, Sans Groupe (Ungrouped) is a term I used in some places in the French version to represent Regular Members.

Here's why I'm talking about this. In my current code, thought privacy is set to '-1,0' (guests + regular members). So, what if your primary group is not 0? Well, you can't see the thought... :-/
It's pretty much the same problem as with board access, *except* that it has to be set on every single thought you send.
Funny...
Posted: March 15th, 2012, 03:55 PM

(For instance, you wouldn't be able to view these thoughts, since you're in the Wedgeward primary group...)
Title: Re: The Regular Members group
Post by: Arantor on March 15th, 2012, 04:16 PM
Oh, I see the problem. I'm just not sure how best to fix it.
Title: Re: The Regular Members group
Post by: live627 on March 15th, 2012, 04:33 PM
Use -3 for all groups?
Title: Re: The Regular Members group
Post by: Nao on March 15th, 2012, 04:34 PM
I thought about it again, and it just struck me that in AeMe, I did it very simply: I took all groups that were being used as a primary group, and added them to my '-1,0' string... It requires an extra query, though. Or storing that list in a setting, maybe.
Posted: March 15th, 2012, 04:34 PM
Quote from live627 on March 15th, 2012, 04:33 PM
Use -3 for all groups?
Hmm...
This is bordering into hack-land, right? ;)
Title: Re: The Regular Members group
Post by: Arantor on March 15th, 2012, 04:35 PM
It may be bordering into hack land but -1 for guests is already a hack.
Title: Re: The Regular Members group
Post by: Nao on March 15th, 2012, 04:38 PM
Hmm, yes, somehow it makes sense :P

So... Why not -2? Is it already used by something else?
So we'd just 'need' to add -3 to the list of groups for $user_info and stuff?
Title: Re: The Regular Members group
Post by: Arantor on March 15th, 2012, 04:39 PM
There is one side issue with using such 'everyone' workarounds: don't ever use 'deny' with them because that just denies everyone except possibly admins depending on how you implement it...
Title: Re: The Regular Members group
Post by: Nao on March 15th, 2012, 04:50 PM
Well... I suppose it's not something we'll have to deal with for now.

I tried to find any references to -2 as a membergroup and failed... Is there any reason for its non-use, then...?
Title: Re: The Regular Members group
Post by: live627 on March 15th, 2012, 04:56 PM
No.
Title: Re: The Regular Members group
Post by: Nao on March 15th, 2012, 06:11 PM
Apparently -2 is used for 'uninherited groups', whatever that means...?
Title: Re: The Regular Members group
Post by: Arantor on March 15th, 2012, 06:14 PM
Oh yay.

OK, here's the deal. In SMF 2.0, you could have inherited groups, i.e. groups that in themselves had no permissions, but carried a badge and PM limits. This would allow you to create a single physical group for permissions (think SMF teams) but have them all have different badges.

I don't know how well it's implemented, and I know that both of us missed it in our respective magnum opuses (as neither Aeva nor SD respected them properly)
Title: Re: The Regular Members group
Post by: Nao on March 15th, 2012, 06:47 PM
That doesn't say what 'un' is for ;)

Anyway... Is it enough to justify not using -2? I mean, it's apparently only used in the id_parent owner of membergroups.

I'll stick with -3 for now.
Posted: March 15th, 2012, 06:23 PM

Oh, bummer... I just thought about the extra possibility I forgot -- private thoughts that should only be between the user and the person they replied to. I suspect that just filling in a blank value would be okay, though... (The default for the privacy field is -3.)
Posted: March 15th, 2012, 06:42 PM

Hmm, it's getting interesting...
If I implement 'me and recipient', this means I have to add a test for the parent's member ID before showing the thought. Which is okay. But what if you don't want said person to read your post...? Well, will I have to test for the parent only if the field is empty...? And what if you just want the thought to be read by you, the recipient and your friends (a custom ID), *but* the recipient isn't your friend...?! Then I suspect I'll have to add another virtual membergroup, e.g. '-5' would mean 'me and said member...'

Heck, thinking about it, it'd even be simpler to have something like: 'mem-1, mem-5, 12', meaning 'only member 1, member 5 and group 12'... Since we only have to search for mem- + my own user ID for the privacy test, that'd be doable... Meh ;)