Permissions in COD. How does OG work with permissions?
Understanding 'global' vs 'group-wide' permissions
There are two sets of permissions when using Organic Groups:
1) permissions in admin/people/permissions: this is controlled by user_access('permission')
2) permissions in admin/conference/XXX/edit/permissions: this is controlled by og_user_access('permission')
The permissions in #1 are usually referred to as global permissions and if og strict permission checking isn't turned on, these permissions will trump. You can use this if ALL of your conferences use the same permissions at the same time: IE all conferences always allow sponsor submissions. If at any point in time you want one conference to NOT allow access to post/edit/etc into it, you must use og strict permission checking.
The permissions in #2 are usually referred to as OG permissions. If og strict is not turned on, these permissions overlap the existing permissions in #1. So if you have session submission turned off for anon users, but non-members can post sessions, then anonymous users will be able to post them because technically they are non-members.
Note: The patch below fixes the anon problem. With this patch, anyone with authenticated user access can submit to your group if it has non-member checked. This is useful for conferences where the CFP is open but regsitration is not. For conferences that want users to registered before they can submit a paper/presentation, make sure non-member is unchecked.
Default OG/COD Setup
In general, each group should be overriding the default permissions with their own. This allows a group to turn on/off access to a certain part of the site (IE session submissions) without affecting another conference. OG Access Strict should be turned ON so that global permissions don't override a negative permission in the OG settings.
You also should refrain from setting any global permissions related to content. This will help consolidate permissions per conference.
The OG Access module is not needed unless you plan to create a private conference. This is not yet supported in COD, but in theory should work.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | og_anon_permissions_deny-2.patch | 1.82 KB | japerry |
Comments
Comment #1
japerryUpdated paths to reflect beta6. The flexibility of permissions is still a considerable hurdle for anon users.
Comment #2
japerryUpdate to patch
Comment #3
japerryAlso need to add 'required' to content types in which we want to restrict posting to a certain group. IE Sessions, BOF Sessions, etc. If they're not set to required then any authenticated user can make a session and it just sits unattached to an event.
There might be a case to not have required og_group_ref fields for some use cases, but I think thats the exception, not the norm. For those users we'd want to have a features override set.
Comment #4
mrconnerton commentedComment #5
mrconnerton commented[wrong issue]
Comment #6
mrconnerton commentedComment #7
dyannenovaSetting to needs work because we still need to rip out all of the permissions from features.
Comment #9
japerryComment #10
BabaYaga64 commentedI've been exploring a bit on how the permissions work in OG versus the sitewide default permissions in COD. I came up with some basic user roles documentation here: https://docs.google.com/document/d/1kXxaf0hcQ7yvS8N4urEQrfv79X9y5lA_ghTd...
I'm planning on adding a workflow for authenticated users to add sessions.