Last updated June 11, 2013. Created by good_man on June 21, 2011.
Edited by samwilson, chicagomom, slindhurst, Mac Lake. Log in to edit this page.

This page describes the basic usage of the Content Access module. This basic usage of controlling content types' access control is enough for most users, so it's very likely you'll find what you are looking for here.

Why use Content Access instead of Drupal's default access control system?

The Content Access module is a layer on top of Drupal's access control system, but it provides more fine-grained access control (node-level or content type level), greater usability and more options. So instead of ticking/unticking the checkboxes on Drupal's permissions page, you go to the node or content type whose visibility you want to control and change its access control settings.

Configuration

There is no global configuration page for this module. It's coupled to content, so configuration is accomplished by

  • enabling the appropriate permissions in the site-wide permissions area,
  • configuring access for content types and
  • optionally configuring access for nodes themselves.

Example Use Case - Role Based Access Control

  • A client asked you to build a site with a section into which he or she can put his invoices, and only the client and the accountants in the company can access this section. The "section" in Drupal's terms is a content type we'll call invoice.

    Next, create user roles called "clients" and "accountants", and assign any users who are clients or accountants into these roles.

  • After creating the user roles and content type and enabling Content Access, go to the content type edit page for this content type (e.g. in Drupal 7 'yousite.com/admin/structure/types/manage/invoice' and in Drupal 6 'yoursite.com/admin/content/node-type/invoice'). There you'll find a new tab called Access Control.
  • You find inside Access Control these basic Role Based Access Control Settings, for working with published content of this content type:
    • View any invoice content: Allow the checked role(s) to view the nodes (content) of this content type.
    • View own invoice content: Allow the author (from the selected roles) of the node to view it.
    • Edit any invoice content: Allow the selected role(s) to edit nodes of this content type.
    • Edit own invoice content: Allow the author (from the selected roles) of the node to edit it.
    • Delete any invoice content: Allow the selected role(s) to delete nodes of this content type.
    • Delete own invoice content: Allow the author (from the selected roles) to delete the author's own node of this content type.

    Note that users need at least the access content permission to be able to deal in any way with published content.

  • Back to our use case, you select View any content for the accountant & client roles.
  • Now published invoices will be only visible to people (users) from the previously selected roles. Be sure to test your configuration by logging out or logging in as another role and trying to view the node.
  • On this page you can also enable Per Content Node Access Control Settings.

Per Content Node Access Control Settings

If the Node-level access control box is checked for a specific content type, a new tab for the content access settings appears when viewing content. You have to configure permissions to access these settings at the site-wide permissions page (Drupal 7 = admin/people/permissions). There are two available permissions here:

  • Grant content access - View and modify the content access rules for any nodes on the site.
  • Grant own content access - View and modify content access permissions for a user's own nodes

Once node-level access control is enabled for a content type, roles that have been granted content access will see a new Access Control tab when viewing nodes for which they have content access control.

In addition to role-based access control (as above), the node-level access control page includes a section for creating and managing User Access Control Lists, which allow the user to grant access to specific users to view, update, and/or delete the node.

Select individual users to grant access by entering their name in the Add user lookup field.

Looking for support? Visit the Drupal.org forums, or join #drupal-support in IRC.

Comments

I did everything the docs told me to do, disabled access to a certain page for anonymous users, cleared every cache in the neighborhood, and it never worked.

Then on a whim I went to admin/user/rules where I got a message like "you need to rebuild your access content rules" or something like that. I clicked on the link and it did its batch processing, and then the module worked.

Perhaps that's an addition for the above steps?

Good hint, but the rebuild permissions message is so clear, and appears everywhere if you didn't rebuild (it's a Drupal message behaviour). And I think the suitable place for your hint is installation page not basic usage.

But this has happened to others (and myself). The best solution is to uninstall and reinstall the module. As soon as the module is reinstalled, choose to rebuild permissions immediately.

This is a great module!

It's absolutely true that there are cases where you have to force the rebuild of permissions even after the module says it did so (though it was suspiciously quick). This should be part of the troubleshooting documentation.

I'm not sure if this is because my site previously used nodeaccess, because it was upgraded from Drupal 6 or what, but I tried everything I could get my hands on, and nothing worked until I forced the rebuild.

Also, no one included the link to rebuild for those who didn't know where it was (or that it was (needlessly) moved in D7). /admin/reports/status/rebuild or you can find the link on the status report.

Hope this saves someone some time.

Man, I don't know what's going on, but rebuilding just doesn't seem to be working. I even disabled the module, removed it from the directory, re-installed it, rebuilt permissions, set the permissions, then rebuilt AGAIN. Nothing changed.

Steps:
1) Enable, rebuild Rules
2) Go to "Content Type X" Access settings and Enable "Per content node access control settings"
3) Go to Content node X Scroll to bottom till MENU and URL settings and try to look for "Content Access Option settings"

Alternatively:
3) Fails to find the access configuration link

Seems like this fails due to other similar module installed (workflow module might be breaking this?)

-pg

This is a great module but I'm unclear on something. If you wanted to hide a node from certain users, and that node was in a menu, surely the menu item should follow the node and display or not display according to the access settings. It just doesn't make sense that the node is hidden but the menu item displays. Do you have to install another module to handle that? or hard code, I just don't get why it wouldn't be one of the same.

What global permissions need to be set? This still isn't working for me. Do I have to have "View published content" un-checked for this module to hide content types from users?

Basically, what I'm asking is, is "View published content" on the /admin/people/permissions page supposed to override the settings on the individual content types?

If so, that would be a good thing to add here.

Well, all that does is remove the user's ability to see ANYTHING. So apparently, "View Published Content" still needs to be checked. Not sure what I'm doing wrong here...

loopy, did you enable access control for the content type, eg for pages go to /admin/structure/types/manage/page/access, & check (for example) Enable per content node access control settings, the box halfway down the page, under PER CONTENT NODE ACCESS CONTROL SETTINGS (click to expand to see the checkbox).

After you do that, there will be a new access control tab on the edit page for that type of content.

Oh, also, It may be that you will need to go to admin/reports/status and click on the link to rebuild permissions
(/admin/reports/status/rebuild)

Putting this here to remind myself for the next time...