Hello,

I've got a fresh OA installation (7.x-2.43) without the drupal/oa workbench modules and I didn't make any changes in admin->people->permissions or admin->config->Organic Groups->OG node Group permissions or OG node Space permissions.

Now, I've got the following construct/building:
- a (private) group with "Group user inheritance" = yes and "Group user permission inheritance" = child's permissions
- a (private) space with the group as parent
- a calendar section within the space with no entries under "Section Visibility"

What goes right:
As long as there are no space members all of the group members only can see the space and the calendar section (which is ok).
When I add a group member to the space that group member (now also a space member) can create content in the space (e. g. an event in the calendar, which is also ok).

What goes wrong:
Now, when I remove that space member from the space it shouldn't have the possibility to create content anymore (because now it is only a group member again). But that doesn't work. The removed space member can still create content even now it is only a group member.

I think (from documentation and webinars) that the fundamental concept of read/write permission is based upon group / space membership, so that's why I think the described behavior is a bug or am I missing something?
Did I make something wrong when establishing my group, space and section?
Btw, I refreshed the oa cache and the browser cache after removing the user from the space but it still got the possibility to create content in the space.

Thank you a lot for your hints and comments!
Michael

CommentFileSizeAuthor
#4 sectiongroup.png205.12 KBMichael_73
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Michael_73 created an issue. See original summary.

Michael_73’s picture

Michael_73 CreditAttribution: Michael_73 commented

It seems that after adding a user to the space and then removing it again, it is possible for every group member to create content in the space although they never were members of the space before.
So seems that it isn't only a problem with the specific user but with the whole space which is "open" for creating content for all members of the parent group after you added and removed one user!?

mpotter’s picture

mpotter CreditAttribution: mpotter commented
Category: Bug report » Support request
Priority: Major » Normal

You don't even need to add anybody as a member of the space. As soon as you add the Group as a parent of the space, everybody in the Group will be considered a Member of the space and will be able to create content. This is exactly how Open Atrium is supposed to work.

Michael_73’s picture

Michael_73 CreditAttribution: Michael_73 commented
FileSize
sectiongroup.png205.12 KB

Thank you Mr Potter for the explanation.
Based upon some webinars and images (see attached image) I thought with a group as parent of a space you are giving (only) read access for the space to all group members.
Only with explicitly adding users as member to a space they can create content.
And my oa installation behaved exactly that way: With the group as parent of the space all group members could see e. g. the calendar section but no one could create an event (which was ok in my understanding).
Only by adding a member of the group to the space this user could create an event (but unfortunatly after removing him from the space he still could create an event).

And I thought this is the correct way to give all group members the possibility to see space content but give only some of them (who have to be space member) the right to create content.
Btw. then how can I manage this in an other way?

For example:
https://www.drupal.org/node/2340349
"In OA, Groups are used for access control to Spaces. Space membership controls creation of content. So Group members can view content from all Sections that Group has access to, but only Space members can create content within that Space."

And I also understand the attached image (sectiongroup.png) in the way I explain.
There it seems that only group members who are space member at the same time have write access.

Maybe I really got somethin wrong!?

Thany you again. Really appreciate your explanations in order to understand the basics of oa group / space membership and permissions.

Kind regards
Michael

mpotter’s picture

mpotter CreditAttribution: mpotter commented

That documentation page isn't correct. Members of a Group are inherited by child Spaces. They become "inherited members" of the Space and have all permissions of normal Members. The diagram you showed is for a *SECTION* that has a Group assigned to it. But I believe we are talking about a *SPACE* that has a Group assigned as a Parent, which is different.

What you'll need to do is disable the Create Content permissions for Members of the SPACE. Then create two Groups, one with the Create permissions enabled, and one with the Create permissions disabled. Add users you want to create content to the first group, and add users you don't want to create content to the second group. Make both groups parents of the space. Ensure that the Groups have the "Inherit Permissions" and NOT the "Use Child Permissions" option.

Now your users will use their Group-level access to determine if they can create content or not.

Michael_73’s picture

Michael_73 CreditAttribution: Michael_73 commented

Thank you very much Mr Potter.
Now I understand the basics of space membership and permissions.
In the meantime I found another possible solution for my problems (I guess):
I disabled the create content permission for the space, added a new space membership role which is allowed to create content and then assign this role to these users I want to have the create content permission.

Kind regards
Michael

Michael_73’s picture

Michael_73 CreditAttribution: Michael_73 commented
Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

joep.hendrix’s picture

joep.hendrix CreditAttribution: joep.hendrix at CompuBase Internet Solutions commented
Version: 7.x-2.43 » 7.x-2.64
Status: Closed (fixed) » Active

Regarding #3 and #5.

Your information is not correct, or there is a bug in the current 2.64 version.

Steps to reproduce:

  1. Fresh install of OA 2.64
  2. Create a public space
  3. Create a public section, for example a Discussion section
  4. Create a test user
  5. Create a test group
  6. Add the test user to the test group
  7. Add the test group to the test space
  8. Login as the testuser
  9. You will not be able te post content in the Discussion section

If this testuser were a direct member of the space, then he can post to the Discussion section.

I am confuesed....

mpotter’s picture

mpotter CreditAttribution: mpotter commented
Status: Active » Closed (fixed)

In #5 is says:

Then create two Groups, one with the Create permissions enabled, and one with the Create permissions disabled

Groups and Spaces have different default permissions. After creating your Group in step 5 go to the Permissions of the group and you will see that none of the "Create X content" permissions are enabled. You need to override these permissions and enable the Create permissions.

When a user is inherited via a Group, they have the permissions of the Member OG role of the *Group*.

joep.hendrix’s picture

joep.hendrix CreditAttribution: joep.hendrix at CompuBase Internet Solutions commented

After some more trial and error testing we have found how things should be configured for the different use cases.

Since there are a lot of questions in issue list on this matter and the current information sources are confusing, I will spend some time to create a handbook page where the different use cases will be described.
Hopefully others will also add to this bookpage so we will end up with a nice document that reflects the flexibility in OA.

Cheers, Joep

joep.hendrix’s picture

joep.hendrix CreditAttribution: joep.hendrix at CompuBase Internet Solutions commented

Will add to the incomplete current handbook page https://www.drupal.org/node/2340349.

mpotter’s picture

mpotter CreditAttribution: mpotter commented

Thanks! Updates to the handbook are always welcome. I just looked at that page and the case discussed here seems to already be covered (and it talks about editing the Group permissions for Create content), so maybe it just needs some tweaking to clarify.

joep.hendrix’s picture

joep.hendrix CreditAttribution: joep.hendrix at CompuBase Internet Solutions commented

Yeah, but since there are so many use cases imaginable it is hard to find out if that handbook page is applicable to somebody's situation.
For example, the current use case described Public space, section write permission via group membership has cost me literally a day to figure out. All the possible permission settings are very overwhelming and not easy to grasp. Ik hope by adding some very recognizable use cases your workload on the issues list will go down -;).