Groups and Team users permissions to create content are not being inherited

Hi antonyanimator, can you confirm that in the Group (the one you are trying to add to the space) you have the following options selected:

Group user inheritance: "Yes - subgroups of this group will inherit users"
Group user permission inheritance: "Inherit Permissions - inherited users will also have the same permissions as this group"

Can you retry now? We fixed some things related to inheritence.

I still see this behavior as at v2.26.

Could this be the same issue I was having? https://www.drupal.org/node/2281383 It turned out that I needed to have "Child's permissions - inherited users in this group's subgroups will have the permissions of a generic member of that subgroup." checked instead of "Inherit permissions".

that option means the inheritated user will have the use permissions of the group/space when in that space, so if that is granting permissions of parent group then something is wrong.

However, note, that the permission setting is on the child (for how it inherits), not the parent, so need to check the settings of the child, not the parent.

I believe I can confirm this has been fixed by 7.x-2.40-rc1. Here's my use case:

In real life, I have teamslet's call them committees, for the sake of not overloading another word.

1. Start-up Committee
2. Fundraising Committee

I also have a committee of Everyone, which is just the union of all committees.

In Open Atrium, I have created

1. Start-up Group, with members directly added
2. Fundraising Group, with members directly added
3. Everyone Group, no direct members, but inheriting members from Start-up and Fundraising Groups.

I have created a Space, "Internal", with no direct members, but have added the "Everyone Group" to the "Inherited" tab for the Internal Space.

All Groups and Spaces have the settings

1. "Yes - subgroups should inherit users."
2. "Use Child's permissions"
3. Default roles and permissions

Members of e.g. Start-up Group have permission to create content in all sections within sub-spaces of the "Internal" Space, which is the expected condition.

In my opinion (tested on OA 2.41 fresh install) the OA Group's members inheritance mechanism of rights for the Space isn't working as expected (the fact that an authenticated member which was made member of an OA Group which, also, is a OA Group inherited into an OA Space should act like a member of the same OA Space directly added, there shouldn't be any difference...this to justify the mechanism of inheriting OA Groups into OA Spaces without singularly declaring each OA User membership to them):

Steps to reproduce:

(1) create (as Site Admin) a Space
(1.1) set the created Space as Private
(2) create (as Site Admin) a Section into that Space
(3) create a User (editor role)
(4) create an OA Group
(5) add the user created at (3) as member of the OA Group created in (4)
(6) edit Members OA Space settings of Space created in (1)
(7) add the OA Group created in (4) (which now contains the user (3)) into Inherited members of the Space (this action should let the Space to inherit members from the added OA Group).
(7.1) at this point the Space shows its private state and shows which OA Group is admitted to see the content published into that Space.
(8) at this point (all Space, Group, Section have default OA settings) log out the Site Admin and log in as the user
(9) the user can see (Site Map) and access the Space and its Sections BUT it is not enabled to add contents (I tested this into a Discussion Section) -> No "+" push button in the Toolbar.
(10) now, as Site Admin, add that user directly as Space Member (without promoting it as Space Administrator), leave or remove the OA Group from the Space (it doesn't matter).
(11) log in as user and now that user is able to add content to the previous tested Section -> now the "+" push button is available.

Am I doing something wrong by following this procedure?

In another OA 2.41 installation I have I did the procedure outlined above discovering that if I log in as the user at point (8) then the user (not direct member of the OA Space) doesn't see the Space at all although it is (or it should be) an inherited member of that OA Space through its OA Group. So this is a slightly different (and worst) behaviour than the one reported above results of (AFAIK) the same steps while in two different OA 2.41 sites (the first is a fresh new OA 2.41, the other was an upgrade from OA 2.33).

I confirm that, on the private OA Spaces, peoples are two in my test: the Admin (as per default) and the user, inherited from the OA Group (of which it's an administrator member too); other informations are: Group Manager = admin, Total member = 1

This sounds very strange...in both cases once the OA User is added directly as OA Space member...then the OA Space access (or just the ability to add content to OA Sections that belongs to that OA Space as in the first case) is granted, finally.

Davide.

Looks like the title of this issue would be better described with "OA Spaces don't inherit OA Group's members like they do with members directly added to them". Isn't it?

I'm still try to understand if I understood the inherit mechanism well or not...it seems so simple or, maybe, I'm doing (or expecting) something that is totally wrong.

Does this issue have a correct solution/workaround like the one proposed by @nrackleff with the comment #9? I'm not sure...reading various other reported threads.

Thanks, Davide.

I just tried the steps given in #12 and could not reproduce this in v2.42. So either it's fixed or there is something else different on your site. The user created in #3 was able to see the space in (8) as well as create content just as expected.

2.42 should be out later today for you to try.

OK Mike, I'll test this too (actually I solved by adding every single user as direct member of each necessary OA Space, would be great to use OA Groups to obtain the same result).

A question regarding OA Group members types: once a user is member of an OA Group does it need to be "promoted" as OA Group Administrator member or is it just sufficient to leave it as a simple OA Group member? What is the difference between two types considering also that each OA Space has Administrator members and Not-Administrator members differentiation?

That is what the "Inherit permissions" vs "Child permissions" option controls.

Assume User A is Admin member of Group B, which is a parent of Space C. There are two inheritance options for Group B:

1) Inherit Permissions
All of the permissions of User A are inherited into Space C. Since User A was an Admin member of Group B, they become an inherited Admin member of Space C. They are not specifically listed as Admins in the Members->Admin page, but they do have full space admin permissions. If Group B had some sort of custom permission scheme, the user would have those same permissions in Space C.

2) Child Permissions
User A is inherited just as a normal member regardless of their permissions in Group B. So in Space C the User is just a regular member and NOT an admin.

Keep in mind that Admin/Member/NonMember are OG Roles and you can add custom roles to your own site. In case (1) any custom role the user has in the Group will be inherited into the Space. In case (2) the user is just a normal Member and loses their special role in the space.

Understood; So considering case 1, given that Inherited permission seems to be the default setting when creating an OA Space, this consequently should mean that (an editor role) non administrator member of an OA Group will be seen exactly as (an editor role) non administrator member inherited by the Space in which the Group it belongs was inherited.

Right?

Always considering the case 1, the same could be said if the user is an administrator of an OA Group (User permissions set at Group level win against the child which is, in this case, the OA Space)...this basically means that no matter the permission or role a user has inside its Group...these properties will be "transferred" to the Space via the Group membership with a result that should be equal to the one we obtain when the very same user is added directly to a Space.

Argh...difficult english!

I will re-test on OA 2.42.

Hello Mike, It looks like that in OA 2.42 the issues I reported weren't gone in my upgraded test site.

Few things surfaced in testing the above (I didn't noticed before) on a fresh new space, new sections and new group on 2.42 (same user with editor role):

(1) the user which was made member of the OA Space through the inheritance mechanism by the Site Admin doesn't see that private OA Space it's able to visit on the Spaces node on Home -> All Spaces... (exactly it doesn't see it neither on the Space Membership list, as it should be, nor on the Spaces All list)
(2) Recent Spaces list doesn't report it too (despite user visited that OA Space using the Site Map).
(3) the user is still unable to create content on space's sections (here nothing changed).
(4) a curious thing showed up: the OA Space shows up on the Home -> Site map page and, from there, can be visited by the user so there is a sort of inherited membership in place.
(5) when the user visits that space through the Site map, on the space landing page left side there is an unexpected "Request space membership" link (I mean unexpected for that user in that space);
(6) on the OA Space the "Groups" reports the OA Group of which the user is member of...so the membership inheritance - apparently - looks somewhat working BUT if I then look deeply and access the Members list for that space with the Members push-button I then discover that related OA Group doesn't appear on the Members Inherited (where I - as user - expect to find it).
(7) the Site Admin is able to see the inherited OA Group so, maybe, from the point of view of the user (which is not an Admin of OA Group and so not of the OA Space) there are two issues:
- on a side, a "visualization" issue: shouldn't the user be able to see that it is member of a Space (inherited through its OA Group) it is member of?
- on other side, a "membership" issue (other than a more general inheritance issue): why a membership request is presented if it is yet a OA Space member?

Caches were cleared, indexes were rebuilt, permissions too...but nothing apparently changed.

Let me know if a new issue should be created of if I'm doing something in the wrong way.

Maybe I have a "dirty" test site...I'll test ASAP on a clean fresh 2.42 to see if things change.

Thanks, Davide.

Yes, please test this on a fresh install. I still am not able to reproduce these issues.

But, keep in mind that some widgets, such as the Spaces list in the user dashboard only show the *direct* memberships and not inherited. So having inherited spaces not show in some lists is generally "by design". Atrium is trying to distinguish between the potentially large number of spaces a user might have *access* to via inheritance, vs the smaller number of spaces the user is directly participating in.

The main topic for this issue thread is whether the inherited user can Create Content in the subspace or sections (3) in #18.

The Request Membership button is for requesting *direct* membership of a space. The Inheritance just gives the user *access* to the space, but doesn't flag them as direct members. Again, this distinction is by-design. Inherited members and direct members should have the same access permissions, but they are NOT the same exact thing.

As an example, think of a common collaboration site, such as Reddit. You might have *access* to view lots and lots of different spaces. As a high-level user you might have access to ALL spaces. But you are only actively participating in a small number of spaces. The list on your user dashboard is for the spaces you are directly participating in. The Members tab of a space shows the members directly participating and not just all the users who have access to the space.

So, let's keep this focused on #3 for the Create Content permission. If you have suggestions on improvements for the other distinctions between membership you should probably create separate Feature Request tickets.

Reading you Five / Loud and clear!

@mpotter: considering your comment #16 (OA default is (1) Inherit Permissions) and what you then wrote on comment #19:

The main topic for this issue thread is whether the inherited user can Create Content in the subspace or sections (3) in #18.

I did some test on a fresh, stock and clean OA 2.41; properly installed and running.

I think I found the key: it looks like Group's members inherited by the Space don't inherit role permissions through their defined user role as happens when same users (sharing same roles) are added to Space directly.

Probably I've overestimated the usefulness of Open Atrium Groups.

Long story short: it looks like direct Space members receives user roles permissions, indirect ones (inherited through a OA Group) not because Organic Group Node - Group permissions - for these users only - just step in and rule out what those "special" users can/can't do in a Space. This is probably by design, I don't know.

Long story: I noticed that directly added members to a Space (sharing the same role of inherited ones) receives permissions through the role - as example Editor - they have (/admin/people/permissions) and this works as expected on Space/Sections they belong to (if an Editor role has "Create Discussion Post" enabled then editor users can add a Discussion Post on the Discussion Section of the Space or directly one the Space landing page). That's fine.

Indirect (inherited) members into the same Space (with the same exact user role of direct ones) don't receive permissions from the role they have but they receive permissions only through the Organic Group's set of permissions defined by the Organic Group - Node Group (/admin/config/group/permissions/node/oa_group), at least this is what I found while testing (every time I changed something I did clear caches and rebuild permissions to be sure what I see on the site is congruent with settings).

Thus the key of the story regarding how inherited users behave seems to be the default set of permissions defined on Organic Group (for non-member, member, administrator member), I mean specifically *that* set of permissions and not the set of permission defined by default for each OA role (for anonymous user, authenticated user, administrator, editor).

So when you have a Space which inherits OA Group members then their permissions are governed by the Organic Group, no matter of what permissions were set for users role (in this case I chose the Editor role for three users, two users were added to an OA Group that has default Organic Group - Node Group permissions, one user was added as direct member of the Space that has a Discussion Section, the OA Group was inherited by the Space, OA Group's member can access the Space while they can't create a Discussion Post); all permissions settings were default by the standard Open Atrium installation.

Basically this means that there are (at least) only three ways to let a non direct member of a Space to act like a direct one (when speaking of OA Spaces/Sections and actions they can do on/with content types), please correct me if I'm wrong (not an expert here):

1. let the user to submit a space membership request (so asking to be added as a direct member of the OA Space) due to the fact its Group membership lets him do access the Space he only need to gain permissions for that Space: this means that an Admin should then discover and approve the pending subscription request for that Space and only then that user can act like a direct one -> so then he will be able to create a Discussion Post (as example).
2. assign that user to be an Administrator member of the OA Group it belongs to: this will enhance its power at the maximum permissions level he can desire (administrator members of an OA Group have all permissions enabled as the OG permissions set discussed above reports) but it's not a good way to operate IMHO.
3. change that user permissions as needed on the OG Group - Node Group (e.g. enable only the "Create Discussion Post" parameter) but, again, this is not the right way because you will end to have users with equal roles that will receive permissions to manage contents in two different ways since they play into the same OA Space coming from two different routes (direct one vs inherited one).

So the question I had in my head "Why it's impossible to create a Discussion Post for a non-Administrator member of an OA Group even if it was inherited by the Space and it has the same role of other direct users?" seems to have a simple answer: because that user looks different from the point of view of the Space and, by default, the "Create Discussion Post" permission is simply disabled in Organic Group Node - Group.

Am I wrong? Is this way of thinking misleading?

If "No" then there is a trouble: OA Groups are useful only to easily group mail notifications schemes, not to group users to easily (which isn't easy) give them access/permissions to manage (create/edit/delete) their/other contents in Spaces/Sections.

If "Yes, because this is "by design" then someone would then illustrate a good reason to group users by creating OA Groups in Open Atrium (which is a nice thing).

Edit: the more I look at this the more I think this is just a personal discovery of an inexperienced user like me, other more experienced Open Atrium / Drupal users maybe know that yet very well.

A curious side note (that looks unreasonable to me) is that the "Edit Own Discussion Post" and "Delete Own Discussion Post" are enabled by default in OG Group Permissions for members, "Create Discussion Post" is disabled: why to give - by default - the ability to delete/edit a discussion post if the ability to create it is denied since beginning?

Thanks, Davide.

A short answer to this: Organic Groups overrides default Drupal user roles. You should not be using global Drupal roles, such as the "editor" (which comes from Panopoly and is not used in Open Atrium).

In the out-of-the-box install of Open Atrium, all Create X Content permissions in global Drupal are disabled (except for Administrator). Create Content permissions get enabled via OG Permissions via Spaces or Groups.

To implement "Editors", ignore the Drupal editor role. Instead, create an Atrium Group called Editors. Set it's Permissions to Override the default. Edit the OG Permissions for that Group and enable the permission to Create X Content (in the Member role of the group). Ensure the inheritance is set to "Inherit Permissions" (NOT Child Permission). Then assign the Group to the Space you want. Now anybody who is a member of the Editor Group will be able to create content in the space.

I just tested this on our clean installs and it all works fine. So I think somehow your various permissions have gotten messed up. The main purpose for Groups in Atrium IS for *access control* (notifications are a secondary feature).

OK (all this really deserves a Wiki page as a Best Basic Practice to follow): so when a people (user) is created it should just be fine that the "authenticated user" role (in terms of "Drupal" roles) is the only one enabled by default (forgot the "Drupal" editor role, leave it unchecked), this for existing and/or any new people (user) of the site (/admin/people/create).

This means that People Permissions and Roles should never be changed (if we can do it through OA Group overriding their default permissions set for member users).

I tested with the procedure you described and it works.

So basically this means that for every OA Group I need to override its set of permissions (that are read-only by default) and then set them accordingly (in my vision I mean all equals for all groups for the member user profile)...in this way inheritance works and users of OA Groups inherited into various OA Spaces act like direct OA Space members.

No I think I didn't messed up anything on the test site because the only one test I did (I never override nothing at OA Group permission level) was to enable then disable the "Create Discussion Post" parameter (was unchecked) for member user on Administration -> Configuration -> Organic Groups -> OG permission overview -> Node - Group edit (see from /admin/config/group/permissions/node/oa_group) and exactly through this test I wrote what I discovered.

On the same test site (OG Permissions re-defaulted) I tested your procedure and it looks good.

Lesson: forgot to check the "Drupal" editor role when creating a new people and focus on overriding OA Group permissions and set member user permissions accordingly (by the way "Inherit Permission" on the OA Group is the default).

Thanks Mike. Great.

In the future I'd like to see a way to have a OG Permissions "profile" that you can assign to a Group or Space. So rather than just selecting "Use defaults" or "Override" you have other options in the drop-down for different profiles you can define. Then you don't have to have so many different customizations that are hard to manage. But that's more of an Organic Groups feature request and is further down the road.

Glad you were able to get it working even though it's rather complicated.

Mike, Thanks for your help, patience and time!

Your OG Permissions "profile" idea would definitely be a nice-to-have features.

Davide.

The comment #9 by nrackleff is very important here.

If you want to have space members added via a group to have the same permissions as direct members, you will need to to check "Child's permissions - inherited users in this group's subgroups will have the permissions of a generic member of that subgroup." in the group definition.

Yes, but to clarify:

Inherit Permissions: users have the permission defined for their role in the GROUP (and keep their role)
Child Permissions: users have the permission defined for *members* in the SPACE (and role is changed to member)

So, the Role is an important distinction here. If the user is the Admin of the Group and you use "Child Permissions", then the user is no longer an Admin, they are just a regular Member of the Space (and thus have the regular member permissions).

That is why "Inherit Permissions" is the default. It allows you to inherit both the permissions and roles from the parent group. You can still set up the permissions in the Group to match the permissions in the space if you want.

The documentation page indeed should be updated with clear examples so I support joep.hendrix's initiative.

Basically you have your scenario's for open Space's and your scenario's for private Spaces. Another factor is the use of Groups and the use of direct Space membership.

Another issue is that the UI is counter-intuitive because it is not clear what "this group" and "that subgroup" is refering to. I only found out today that in order to hide a private sub-Space one should set Group user permission inheritance for the child Space to "Child's permissions" and setting this is independent from the Group user inheritance setting in the parent Space. Now because the Group user inheritance toggles the Group user permission inheritance visibility one suspects a relationship there.

Group user inheritance *
No - subgroups of this group won't inherit its users.
Yes - subgroups of this group will inherit its users.

Group user permission inheritance
Inherit Permissions - inherited users in this group's subgroups will have the permissions as they do in this group and not the permissions of generic members of that subgroup.
Child's permissions - inherited users in this group's subgroups will have the permissions of a generic member of that subgroup.

I'm not sure but it's confusing at least.

Argus: might need a similar issue or help page for your specific case. But I think something is still confused there. None of these inheritance settings affect the current group...they only affect subgroups. So when you say you set a sub-space to have "Child permission", that doesn't affect that specific subspace, it only affects its children, so that doesn't cause the subspace to be hidden. Unless there is a bug somewhere.

Also, improvements to the UI wording are welcome. These come from the og_subgroups module and I agree they are confusing to new users. But I believe if you read them carefully they do indicate exactly what they are doing.

"this group" refers to the current OG Group (Atrium Group or Space) that you are editing
"subgroups" refers to any children of the current Group/Space that you are editing.

The first option "Group user inheritance" controls the On/Off as to whether children inherit any users at all. If this is Off, the next question doesn't matter. That's why it toggles the UI.

The "Group user permission inheritance" determines what role/permissions an inherited user has in the child group. When set to "Inherit permissions", the inherited user retains the role and permissions that they have in the current group (the parent of the children). When set to "Child permissions" the inherited user has the Member role/permissions in the child space.

It is indeed a little challenging to understand those settings.
A little help in the vocabulary of one of the settings could be made by changing "Group user permission inheritance" to "Group role inheritance" or something more user friendly?

I tested this again on a clean OA.

Testing visibility and access for private subSpace B

• Create a Space A and a subSpace B
• Set subSpace B to 'private'
• Testuser is regular member of Space A
• Set the Group user inheritance for Space A to "No"
• Result: Testuser can see subSpace B but not it's content
• For subSpace B now set Group user permission inheritance to "Child's permissions"
• Result: Testuser can not see subSpace B, nor has access to it's content.

Argus, can you move specific example/test to a new issue so we can work on a patch for it outside of this general discussion. Definitely sounds like a bug in og_subgroups, but I'm willing to track it in Atrium since that module issue queue doesn't get a lot of attention.

One other thing we'll need to test is if this behavior is the same after rebuilding permissions after each change. Organic Groups normally doesn't rebuild permissions automatically. We have some code in Atrium to trigger that, but maybe it's not being triggers in some cases.

(For example, even changing from Public -> Private doesn't normally rebuild permissions in OG...that is something Atrium added)

I have noticed that sometimes a clear cache helps as well (drush cc all).

Will do that. Yeah might be the rebuild permissions. I noticed after further testing that changing the Group user permission inheritance setting triggers the expected result.

jakeschlachter CreditAttribution: jakeschlachter commented 2 years ago
Version: 7.x-2.26 » 7.x-2.40-rc1

I believe I can confirm this has been fixed by 7.x-2.40-rc1. Here's my use case:

In real life, I have teamslet's call them committees, for the sake of not overloading another word.

Start-up Committee
Fundraising Committee

I also have a committee of Everyone, which is just the union of all committees.

In Open Atrium, I have created

Start-up Group, with members directly added
Fundraising Group, with members directly added
Everyone Group, no direct members, but inheriting members from Start-up and Fundraising Groups.

I have created a Space, "Internal", with no direct members, but have added the "Everyone Group" to the "Inherited" tab for the Internal Space.

All Groups and Spaces have the settings

"Yes - subgroups should inherit users."
"Use Child's permissions"
Default roles and permissions

Members of e.g. Start-up Group have permission to create content in all sections within sub-spaces of the "Internal" Space, which is the expected condition.

Thank you so much!
I struggle for couple of hours to understand inheriting in Open Atrium, but your post help me a lot.
I'm doing my first project and Open Atrium looks very promising for me.