OG Permissions don't get set by Features during install, so Space members can't create any content

Hi,

Try to clear all caches, works for me.

When you said admin, you would say admin user role or admin in section members role ?

I think, per node type, 3 conditions have to be met before a user can create, edit or delete content: the proper permissions firstly at the general user level (admin/people/permissions), secondly at the Space level (admin/config/group/roles/node/oa_space) and thirdly at the Group level (admin/config/group/roles/node/oa_group).
Correct me if I’m wrong.

I'm pretty sure that Space permissions completely override the global Drupal permissions. I'm not sure what affect the Group ones have...

Yeah that is correct. The standard Drupal editor role that comes with OA has nothing to do with editing content, it is about editing Spaces and group membership : http://docs.openatrium.com/documentation/roles-permissions

"Editor"

Allows a user administrative rights to a specific space. This includes all of the functionality of an authenticated user in addition to the ability to moderator other users content, monitor and modify membership, and customization of the layout of the space.

Yes it does, you need to set group visibility of a Space to private and it will act like that:

Group visibility *
 Public - accessible to all site users
 Private - accessible only to space members

But that is a different issue then the one in the OP, right?

Have you created any Sections in your Space? I think by default only admins can create Sections. But once you've created some Sections which allow other types to be created (for example, a 'Discussion section' will allow 'Discussion posts' to be added) then normal users will be able to create those types via the "+" button in that Space.

Hi,

are your sure your editor permissions in admin/people/permissions, section "node" are correctly checked?

Indeed, user need admin permissions to create spaces and subspaces. (even if it is written in the permissions to give to trusted people).....

I am having the same issue. Here's how I was able to allow a non-admin user to create space content:

1. Edit the space
2. Change the "Group roles and permissions" dropdown to "Override default roles and permissions"
3. Save the space
4. For the space select Configure->Config ( Hit the little gear button at the top of the right sidebar then select Config from the menu )
5. Choose Permissions
6. Give "Members" Create xxx content permission

For some reason "Edit my content" for my installed Document / Event / Task pages is set by default but not "Create"

I've tried creating a group, giving the group members Create permissions, adding the group to the space, but the space permissions appear to override this.

Are there docs or a screencast that explain this anywhere?

Great. Thanks

Great, another peace of the puzzle. You can set the default Space permissions at admin/config/group/roles/node/oa_space, but you can also override those and use a per Space permission profile like described in #16.

I will do a check what the default settings on a fresh installation are, it seems logical node creation should be allowed by default.

The default permissions should already allow this. There is a submodule called oa_adminrole within oa_core that is supposed to go through and give "Create xxx content" for each content type to the Members og_role.

So please let me know if this is not working.

Hmm, ignore #20. The oa_adminrole adds the "own" permissions for members.

The specific "Create xxx content" permissions should be added for members by the individual OA2 plugins. For example oa_discussions has an og_permissions feature to add this.

Maybe they had some Features that needed to be reverted?

@mpotter: I've been fighting with this for a couple of days myself, on a fresh install. Tried to ask about it in IRC but couldn't get a response. I'm in meetings all day tomorrow, but have delegated this to a coworker. Will have him follow up here or on IRC tomorrow or next week. We can also check to see if any features need to be reverted, but I doubt that's what's happening in our case.

I'm able to recreate this on a fresh install! It does look like the OG Permissions aren't getting set by any of the Open Atrium features. I haven't tracked down the cause yet, but I've updated the issue description with very specific information about what's happening and screenshots.

I did another fresh install - this time removing 'oa_adminrole' from the list of dependencies in openatrium.info and commenting out the call to oa_adminrole_update_roles() in openatrium.install. This fixed the problem: the features aren't overridden (except, of course, many other permissions setup by oa_adminrole are missing)! So, somehow oa_adminrole is the cause.

I've haven't tracked it down to specific lines in oa_adminrole, but if I had to guess, this code in oa_adminrole_update_og_permissions looks suspect:

      db_delete('og_role_permission')
        ->condition('rid', array_merge($admin_rids, $member_rids), 'IN')
        ->condition('permission', array_keys($perms), 'IN')
        ->execute();

That appears to remove all permissions for members. If this code is running AFTER the Features have set their OG Permissions, it will remove them.

Probably what we should do instead of db_delete() and then db_insert() is a db_replace() OR a db_select() to see what's already set and only db_insert() the missing items, so it'll leave whatever is already there intact. I'll look to see if OG provides any helper functions to doing this...

Anyway, if I find a code fix, I submit a patch!

Attached is a patch to oa_core which fixes the issue for me on fresh install - all the permissions come up as they should! Please let me know what you think.

Nice catch of module execution order problem! Committed to affb0fb for oa_core.

I've got multiple OA2 installs built with permissions manually tweaked as in #16

What triggers the #25 patch code? Once patched, will editing and re-saving a space or group trigger a permission rebuild? Will things done as in #16 be overridden? I could make arguments why they should and shouldn't. Trying to understand the intent and get my head around this before backtracking up through the oa_adminrole_update_og_permissions() rabbit hole.

The patch here only fixes fresh installs. Anyone who has already installed will still need to fix their site manually.

Per #6 above, is it true that Open Atrium 2 checks for a permission in ALL those places before it gives access? Or that if ANY apply to the current user, they get access?

Easiest way to find out is to create a test space and some test users and just try it out. Use trial and error.

I was having a real problem trying to work out what I was doing wrong (why I couldn't get the '+' button to show up for a site member). I followed Dave's instructions (#16), and now everything is working as it should.