Access Control on Drupal Sites

On a basic Drupal site 

On a basic Drupal site with only the core modules installed Access is controlled as follows:

User 1 and other users granted ‘administer nodes’ permission can View, Create, Edit and Delete all content types.  For all other users:

Ability to View content is switched on or off on a per role basis in node module | access content.  If your role has a tick in the box you can see everything;  if it hasn’t you can see nothing.  There is no distinction between different content types - it is all or nothing.

Ability to Create, Edit and Delete content is controlled on a per role per content-type basis

Drupal 5
Each content-type (page, story etc) has three possible per role switches, for example:
* create page content
* edit any page content
* edit own page content

Drupal 6
In addition to the above there are two more per role switches:
* delete any page content
* delete own page content.

On a site using Taxonomy Access Control

On a site using Taxonomy Access Control an additional level of permissions is added to the equation.  Taxonomy Access Control allows you to give View, Update (which means Edit) and Delete permissions on a per role, per node basis.  The Taxonomy Terms are set individually for every node as it is created and affect each role according to the permissions that have been set.

The way in which the Taxonomy controls interact with the basic controls is different for View and Edit.  If Taxonomy Access is active:

To View a node:
a)  Your role must have a tick in the node module | access content box (basic level permission)
and
b)  The node must have a taxonomy term that gives your role View rights.
This is like two turnstiles in series - you must have two tickets, one for each turnstile.

To Edit a node
your role must have either:
a) An entry in the Permissions Table giving permission to edit:  e.g. node module | edit own page
or
b) A taxonomy term attached to the node giving your role Update and/or Delete permission for that node.
This is like two turnstiles in parallel - a single ticket to pass through either one or the other will get you in.


On a site using Content Access Control

Content Access Control gives View, Edit and Delete permissions on a per role, per content-type basis.  In addition, it is possible to optionally allow per node permissions for selected content-types.  The content_access module very usefully includes author in the list of roles.

If Content Access Control is active:

To View a node:
a)  Your role must have a tick in the node module | access content box (basic level permission)
and
b)  The node must be a content-type that gives your role View rights.
This is like two turnstiles in series - you must have two tickets, one for each turnstile.

To Edit a node
your role must have either:
a) An entry in the Permissions Table giving permission to edit:  e.g. node module | edit own page
or
b) A taxonomy term attached to the node giving your role Update and/or Delete permission for that node.

This is like two turnstiles in parallel - a single ticket to pass through either one or the other will get you in.


Organic Groups

Used without any form of Access Control

If Organic Groups is used without any form of Access Control, including OG Access Control, all Groups and all Group Posts can be seen by all users with access content permission.  The Group acts as a central location from which all the posts (which can be of any number of different content-types) made to that Group can be viewed.

The ability to Create, Edit and Delete Groups and Group Posts is controlled on a per role basis by ticking the appropriate boxes in the Permissions Table.  However, even if he/she has a role that gives create group post permission, a user can only post content into a Group if he/she is a member of that Group.

Installing the Organic Groups module creates three new tables in the database which make the above possible:

* og		Links Group Name to the Node ID of the Group Page (Group).
* og_ancestry	Links Group Posts to Groups
* og_uid		Links Users to Groups

Used with Content Access Control only

This is an unlikely scenario, but it is included for completeness.
If Content Access Control is active on the site but OG Access Control is not, it is necessary at the very least to grant permission to selected roles to view Groups and Group Posts using the Access Control tab on each of the appropriate Content Types.  If this is not done the Groups and the Group Posts will only be visible to administrators or others with ‘administer nodes’ permission.  

Permission to Create, Edit and Delete Groups and Group Posts can be controlled on a per content-type per role basis by ticking the appropriate boxes in the Permissions Table.

Permission to View, Edit and Delete Groups and Group Posts can be controlled on a per content-type per role basis by ticking the appropriate boxes under the Access Control tab on each of the appropriate Content Types.

Remember:
* Permission to Create can only be granted in the Permissions Table.
* Permission to View can only be granted under the Access Control tab.
* Permission to Edit and Delete can be granted either in the Permissions Table or under the Access Control tab.  Decide which you are going to use and stick to it.  Don’t mix them!

Yes – it is totally illogical, but I didn’t design the system!

Used with Content Access Control and OG Access Control

The writers of Organic Groups do not recommend this, but it can be done.
The essential point to grasp if you have two Access Control Modules activated is:

*** Never use two Access Control Modules to control one Content-Type ***

In the specific instance under review here:

* Use OG Access Control to control access to Groups and Group Posts.  Leave all the boxes under their Content-Type Access Control tabs un-ticked so that no permissions are granted by the Content Access Module.
* Use Content Access Control to control access to all other content-types.

OG Access Control

Permission to Create, Edit and Delete Groups and Group Posts can be controlled on a per content-type per role basis by ticking the appropriate boxes in the Permissions Table.

Permission to View is granted using the settings on the Organic Groups Access Configuration page (/admin/og/og_access).  Permission to view Group Posts can be set globally for all Groups on the site or it can be left for either the author or editor to decide on a per post basis.  Visibility of Group Home Pages can be set in a similar way.

Node Access Table

Whenever one or more Access Contol Modules are active on a site, the node_access table is used as a central record of all the View, Update (Edit) and Delete permissions granted to every node on the site along with a record of which module or part of a module (realm) has granted the permission.  The term used to record the group of users to whom the permission is granted is called the Grant ID (gid).  For many Access Control Modules this is a role, but in the case of Organic Groups it is all the members of a Group.

OG Access Control writes permissions to the node_access table using the following realms:
* og_admin
* og_subscriber
* og_public

David Teall
December 2009