Help with assigning usergroup

I have two issues that I'm working through right now and could use some help.  They are:

1) I have a Staff usergroup that I've given most administrative permissions to (along with Super Moderator privileges so that they also appear under About->Staff).  I just noticed that when adding a new user account that I cannot assign them to a user group.  Seems odd.  Am I possibly missing a permission that I'm not aware of or have overlooked?

I've double and triple-checked all relevant permissions but can't seem to find anything specific to this issue I'm experiencing.  Any ideas where I should specifically be looking?

2) I have created one post in the Staff forum.  However, when I go into the Admin Zone I noticed that the block for "Staff forum" says "There are currently no topics in this forum".  I don't think that is correct as there is one post.  Has anybody else seen this?  Is this a bug?


Thanks in advance for your help!
 

Automated fix message

cwdean said

I have two issues that I'm working through right now and could use some help.  They are:

1) I have a Staff usergroup that I've given most administrative permissions to (along with Super Moderator privileges so that they also appear under About->Staff).  I just noticed that when adding a new user account that I cannot assign them to a user group.  Seems odd.  Am I possibly missing a permission that I'm not aware of or have overlooked?

I've double and triple-checked all relevant permissions but can't seem to find anything specific to this issue I'm experiencing.  Any ideas where I should specifically be looking?

2) I have created one post in the Staff forum.  However, when I go into the Admin Zone I noticed that the block for "Staff forum" says "There are currently no topics in this forum".  I don't think that is correct as there is one post.  Has anybody else seen this?  Is this a bug?


Thanks in advance for your help!
 

This issue has now been filed on the tracker as issue #4207, with a fix.

1) I have a Staff usergroup that I've given most administrative permissions to (along with Super Moderator privileges so that they also appear under About->Staff).  I just noticed that when adding a new user account that I cannot assign them to a user group.  Seems odd.  Am I possibly missing a permission that I'm not aware of or have overlooked?

A non-administrator cannot add a member to an arbitrary usergroup, because that usergroup could potentially have greater permissions than they have. There's no reliable way for Composr to calculate it, so it has to block the feature.

Possible solutions:

1. Just make sure the default usergroup is the one you want new members to be in
2. Use an administrator account to add members
3. I specified a feature for it if the above workarounds wouldn't suffice https://compo.sr/tracker/view.php?id=4208

Just make sure the default usergroup is the one you want new members to be in

The problem with this is that the site will have two primary sets of users, CurrentMembers and PastMembers, so I can't really default to one or the other.  I could use some other default, but then I would have to manually set the proper usergroup after they change their password (i.e. validate their account) which sort of defeats the Welcome email purpose .  Might as well use the "Validated" process then…

Use an administrator account to add members

That's what I'm having to do now .

I specified a feature for it if the above workarounds wouldn't suffice 0004208: Define usergroup superiority to allow non-admin staff to specify the usergroups of members - Composr CMS feature tracker

Okay, that makes complete sense.  While I realize how important security needs to be, it isn't easy to remember when architecting site usage with open concepts (even though you still need to, so I appreciate the reminders!).

I like your proposed feature.  In it's simplest form all the feature really needs is a list of approved usergroups that a Administrator or Staff user group would be allowed to approve (i.e. to enforce user group assignments that are "approved").  A more advanced implementation would be to create a hierarchical order for usergroups, indicating most to least usergroup privileges.  Even then, with such granular security permissions as supported by Composr, that hierarchy may not be 100 percent accurate, but that's for the implementor to manage – as with greater flexbility comes greater responsbility .

But a simple list of "approved" usergroups would work as well.
 

Maybe I can open it up so that a non-admin may select any "open" or "default" or "presented at install" usergroups, as all those flags indicate a low-privilege group that anybody could join.
How does that sound?

EDIT: Looking into this some more, I can see my explanation was simplified to what is currently true.

1. You don't need to be an admin, you need "Assume the identity/access of any other member" privilege
2. And that only applies to primary usergroup. For secondary usergroups, if you have "Assume the identity/access of any other member" you have full control, but if you don't you can still put people into any "open" usergroup. I think you're not seeing secondary usergroup selection simply because you have no "open" usergroups and Composr is refusing to show an empty list.

I think these existing rules make a lot of sense.
I just can't remember all the subtleties off the top of my head. I'm looking now to see if it needs to be documented more clearly.

Maybe I can open it up so that a non-admin may select any "open" or "default" or "presented at install" usergroups, as all those flags indicate a low-privilege group that anybody could join.
How does that sound?

Well, I really appreciate you giving this some thought, but I think it's best to just leave as is for now.  Using any 'open' or 'default' usergroup would still require it to be changed to an 'approved' usergroup later.  If we did that, you might as well just allow the default usergroup to be used, since you'd have to change it later anyway…and it works that way already .  Right?

By the way, I don't think you (or anybody) responded to my second question, which was:






 

Hi, the hotfix for the staff forum admin zone issue is here @ 0004207: Forum blocks not working with comma-delimited forum names - Composr CMS feature tracker

Thanks Adam!  I'll take a look at that hotfix right away.

 Well, I really appreciate you giving this some thought, but I think it's best to just leave as is for now.  Using any 'open' or 'default' usergroup would still require it to be changed to an 'approved' usergroup later.  If we did that, you might as well just allow the default usergroup to be used, since you'd have to change it later anyway…and it works that way already .  Right?

Lets only talk about 'open', because I've confirmed Composr already respects the idea that a non-admin with permission to add members may put them in any open usergroup.
I'll assume that the reason that 'open' won't cut it and the usergroups have to become 'approved' ['non-open' in Composr terminology] (i.e. only staff control who is in) is that the 2 usergroups you're putting people in really have to be determined by staff and the users must have no say in it after-the-fact.

Well, you could workaround it by just blocking non-staff from accessing the 'groups' page. If they can't access this page, I believe there is no way for them to put themselves into an open group. You can choose your usergroups when editing your account, but even that seems to respect that users without access to the 'groups' page should not be able to do that.

I haven't tested, this is from my reading the code.

Chris Graham said

Lets only talk about 'open', because I've confirmed Composr already respects the idea that a non-admin with permission to add members may put them in any open usergroup.
I'll assume that the reason that 'open' won't cut it and the usergroups have to become 'approved' ['non-open' in Composr terminology] (i.e. only staff control who is in) is that the 2 usergroups you're putting people in really have to be determined by staff and the users must have no say in it after-the-fact.

Well, you could workaround it by just blocking non-staff from accessing the 'groups' page. If they can't access this page, I believe there is no way for them to put themselves into an open group. You can choose your usergroups when editing your account, but even that seems to respect that users without access to the 'groups' page should not be able to do that.

I haven't tested, this is from my reading the code.

From “Post #6,611”, 26th April 2020, 5:11 am

Yes, you are correct.  Staff must assign the usergroup based on the 'role' that the member should be in.  It's easiest to do that at account creation.

I investigated your suggestion to simply block non-staff from accessing the groups page.  I'm assuming you mean Social->Usergroups from the menu?  I could do that, but as it is any member going to the groups page can only 'request' to join a usergroup and that requires Staff approval…so no big deal.  Just ignore the request or simply deny it…but there is no security risk involved.  And the intent is to have HOA members assigned to the correct usergroup based on current or prior membership…so that needs to occur when the Staff creates their account for them.  At least that's the path I'm pursuing right now…which is why I'm looking for a method to assign a temporary password…because the members are not creating their accounts…the Staff is doing it for them.

I'm assuming you mean Social->Usergroups from the menu?

Yes.

as it is any member going to the groups page can only 'request' to join a usergroup and that requires Staff approval…so no big deal

I think you are confused as to what an 'open' usergroup is. An open usergroup is one you can join immediately without approval. Hence why they can be considered low-privilege and non-admins can put people into them when adding members.

Chris Graham said

I think you are confused as to what an 'open' usergroup is. An open usergroup is one you can join immediately without approval. Hence why they can be considered low-privilege and non-admins can put people into them when adding members.

From “Post #6,620”, 28th April 2020, 9:11 pm

Thanks Chris.  

I think I understand the 'open' usergroup concept…at least in terms of allowing people to 'join' the site, they will get automatically assigned to an approved 'open' usergroup.  And I realize members could join other 'open' usergroups but there will only be two…and the second group (being a higher security group) won't be open.  

I could default everybody to one 'open' group (the lower security group), and then simply move the folks who should be in the second usergroup to that group. But then I would need to deal with people attempting to join the site that shouldn't be.  Not a big deal, but a nuisance that I'm trying to avoid — thus the closed site approach.  It's a little bit more work, but once the member accounts are created, maintenance should be minimal (we're only talking about 20 to 30 accounts).

I think I understand the 'open' usergroup concept…at least in terms of allowing people to 'join' the site, they will get automatically assigned to an approved 'open' usergroup.  And I realize members could join other 'open' usergroups but there will only be two…and the second group (being a higher security group) won't be open.  

Actually you're mixing up 'open' and 'Automatic secondary usergroup' here. I'll try and restate things to be clearer (I didn't go back through this topic to see how I explained it before).

'Open [membership]' is something a user actively chooses to join after joining the site, as a secondary usergroup, and doesn't require any approval. And as a sneaky side-result of this, Composr considers the group benign enough to allow non-admins to put members directly into it on the 'Add member account' form.
'Automatic secondary usergroup' is something that you are automatically entered into when joining, as a secondary usergroup.
And there's also 'Initial primary usergroup', which is about either specifying the initial primary group for any newly joining member (if only one usergroup is primary) or choosing a primary group from a list for any newly joining member (if multiple usergroups are primary).

Anyway, I think we are over-complicating things and getting into the weeds. I do believe all you need to do for your site is:

1. Disable access to the join module using the Permissions Tree Editor
2. Disable access to the groups module using the Permissions Tree Editor
3. Have the usergroups you select from on the Add member account be 'Open membership'
4. Add members using the non-admin staff accounts you set up, via the 'Add member account' form

Chris Graham said

I think I understand the 'open' usergroup concept…at least in terms of allowing people to 'join' the site, they will get automatically assigned to an approved 'open' usergroup.  And I realize members could join other 'open' usergroups but there will only be two…and the second group (being a higher security group) won't be open.  

Actually you're mixing up 'open' and 'Automatic secondary usergroup' here. I'll try and restate things to be clearer (I didn't go back through this topic to see how I explained it before).

'Open [membership]' is something a user actively chooses to join after joining the site, as a secondary usergroup, and doesn't require any approval. And as a sneaky side-result of this, Composr considers the group benign enough to allow non-admins to put members directly into it on the 'Add member account' form.
'Automatic secondary usergroup' is something that you are automatically entered into when joining, as a secondary usergroup.
And there's also 'Initial primary usergroup', which is about either specifying the initial primary group for any newly joining member (if only one usergroup is primary) or choosing a primary group from a list for any newly joining member (if multiple usergroups are primary).

From “Post #6,638”, 2nd May 2020, 2:39 am

Thanks Chris.  I really do appreciate you explaining the membership concepts.  I definitely need to do some reading on the Wiki to get more familiar with how they work…and will do so once I'm done testing site configuration.

Chris Graham said

Anyway, I think we are over-complicating things and getting into the weeds. I do believe all you need to do for your site is:

1. Disable access to the join module using the Permissions Tree Editor
2. Disable access to the groups module using the Permissions Tree Editor
3. Have the usergroups you select from on the Add member account be 'Open membership'
4. Add members using the non-admin staff accounts you set up, via the 'Add member account' form

From “Post #6,638”, 2nd May 2020, 2:39 am

Absolutely.  That is the approach I have taken and should work just fine.

Thanks again!