Status of Bug #3038?

Hi Guys

I was wondering what the end result of bug#3038 was?
forge.joomlapolis.com/issues/3038
I can't really figure out what decision there was made on the behaviour?
What was the 'right' way to do it, and is it in the RC?

My wish was:

The old implementation would only allow moderator to modify group1.
My hope was that some sort of setting or the like, would allow it to modify group2/3 also.

My solution so far, has been to have people in group2, also be part of 'member', but as of 1.8RC, that doesn't seem to work.

The implementation is in CB 1.8 RC, you're welcome to upgrade and test. I can't say for sure how your usergroup structure will work. We're moving away from usergroup usage (slowly being phased out) and going for Accesslevels and Permissions (direction of Joomla). Usergroups shouldn't be used to handle permissions/access.

As I mentioned at the bottom, it doesn't seem to work as before (in the beta code) in 1.8RC.
I would welcome the ability to use permissions instead.
But what permission should be set, or is that only doable in future versions?

We don't have a whole lot of permissions yet. You're welcome to check in CB > Configuration where you'll find the permissions button. As for the usergroups they should be working fine and have confirmed you can select child groups of Registered, etc.. perfectly fine. However, usergroups work in reverse. For example in the above Moderator under Group 1 has higher permissions then Group 1, but not of Group 2 as it's a child of Group 1 and not Group 2. It's very confusing. You should be using accesslevels (which 1.8 RC switched everything to accesslevels, only use usergroups for legacy support) which you can combine any groups you want.

Ok, I'm currently switching to use the ACL levels, as they are much better for this sort of work.
But how does that influence CB moderators? There's only mentioned groups there?

I can definetely say that the patch implemented previously is NOT working anymore.
Looking at the structure above, I have made sure that all users in groups below members, are ALSO part of members, and that worked previously, this does not work anymore.

Ok, I'm currently switching to use the ACL levels, as they are much better for this sort of work. But how does that influence CB moderators? There's only mentioned groups there?

Moderators is still usergroup based.

I can definetely say that the patch implemented previously is NOT working anymore.
Looking at the structure above, I have made sure that all users in groups below members, are ALSO part of members, and that worked previously, this does not work anymore.

Don't understand; seams working fine here. If you select "Moderator" usergroup to be the moderator group then "Moderator", "Administrator", and "Super Users" are all CB moderators.

- Group 1
- - Group 1a
- Group 2

In the above example "Group 1a" does not have privileges over Group 2, because it's not a child of Group 2. Usergroups work like a tree with multiple branches. 1 branch has no relation to another branch. Issues like the above is exactly why Accesslevels should be used (and we're working towards that with each release), but we can't complete such a usage implementation yet; that's for CB 2.0 where full accesslevel and permission usage will be used across the entire component rather then usergroups.