Extend and customize Drupal functionality with contributed modules.
If a module doesn't quite do what you want it to do, if you find a bug or have a suggestion, then join forces and help the module maintainer. Or, share your own by starting a new module.
A CAPTCHA is a challenge-response test most often placed within web forms to determine whether the user is human. The purpose of CAPTCHA is to block form submissions by spambots, which are automated scripts that post spam content everywhere they can. The CAPTCHA module provides this feature to virtually any user facing web form on a Drupal site.
We do this our spare time, which is unfortunately almost nonexistent at the moment due to real life obligations. To give the CAPTCHA module the required level of maintenance, an extra co-maintainer would be welcome. If you're interested in helping with this very popular module, please contact me or open an issue in the CAPTCHA module issue tracker.
The ACL module, short for Access Control Lists, is an API for other modules to create lists of users and give them access to nodes. It has no UI of its own and will not do anything by itself; install this module only if some other module tells you to.
We're aware of the following modules using ACL (let us know if you know of others):
Content Access (optionally uses ACL to provide by-user access control)
Workbench Moderation adds arbitrary moderation states to Drupal core's "unpublished" and "published" node states, and affects the behavior of node revisions when nodes are published. Moderation states are tracked per-revision; rather than moderating nodes, Workbench Moderation moderates revisions.
This module allows you to create arbitrary Workflows, and assign them to Entities.
Workflows are made up of workflow states. Transitions between states can be allowed per role. For example, a workflow with the states Draft, Review, and Published could be assigned to the Story node type. Only users with role 'chief editor' can set Stories to the published state.
You can set up the Workflow to alter states from form, page, comment and a special workflow tab.
By default, Drupal allows only users with "administrer menu permission" to add, modify or delete menu items.
In case you want for instance to let certain users manage primary links or secondary links but not navigation menu, this module provides this functionality.
Nodeaccess is a Drupal access control module which provides view, edit and delete access to nodes. Users with the 'grant node permissions' permission will have a grant tab on node pages which allows them to grant access to that node by user or role. Administrators can set default access controls per content type, and also define which roles are available to grant permissions to on the node grants tab.
The upshot is, this module allows you to do things like 'node 123 can be viewed by authenticated users and edited by admin users and joeuser'. As an added bonus, update and delete permissions are separated, so you can make sure users with edit permissions cannot accidentally delete pages.
The previous maintainer (chadcf) had released a dev version of nodeaccess for D7. Over the following months a number of bugs/issues were reported and as of May 7th, 2013, all bug reports in the issue queue have been addressed (where possible) and with that, version 7.x-1.0 has been released as a stable/recommended release for Drupal 7.
This module changes your forum administration page to allow you to set forums private. You can control what user roles can view, edit, delete, and post to each forum. You can also give each forum a list of users who have administrative access on that forum (AKA moderators).
This module requires the ACL module in order to function. The D7 version also requires the Chain Menu Access API2.x module.
Revisioning is a module for the configuration of workflows to create, moderate and publish content revisions.
You use it in scenario's like this:
Authors write content that prior to being made publicly visible must be reviewed (and possibly edited) by moderators. Once the moderators have published the content, authors should be prevented from modifying it while “live”, but they should be able to submit new revisions to their moderators.
We shouldn't have to grant these roles “god-like” powers (e.g. D6's "administer nodes" permission) to implement this.
Read Only Mode provides an alternate to the built in Maintenance Mode in Drupal. Instead of displaying a static text file to users while the site is in maintenance mode, Read Only Mode will allow access (reading) of new content while preventing the addition of new content (posting / submitting forms / etc).
This allows the site to remain functional while maintenance is performed. This module also provides messaging to users and administrators to indicate that the site is in maintenance mode.
Administrators are able create relationship types (friend, coworker, etc). Relationship types can be setup to be one-way or mutual. If a relationship type is one-way (subscriber) only the requester is shown as relating to the requestee. Relationship types can also be set as needing or not needing approval.
Administrators can give users the option to auto approve relationships on a per-relationship type basis.
Bundled with the main module are add-on modules providing functionality that not every site will need:
User Relationship Mailer will (conditionally) send email notifications regarding relationship creation/removal/approval/disapproval/cancellation.
User Relationship Defaults creates default relationships to any user joining the site (think Tom on MySpace).
User Relationship Implications allows admins to specify implied relationships (Manager implies Coworker) that are automatically created.
User Relationship Invites requires the Invite module and allows users to specify a relationship to a user that they invite to join the site.
User Relationship Privatemsg integration with the privatemsg module showing your relationships in the quick select list.
Workbench Access creates editorial access controls based on hierarchies. It is an extensible system that supports structures created by other Drupal modules.
When creating and editing content, users will be asked to place the content in an editorial section. Other users within that section or its parents will be able to edit the content. A user may be granted editorial rights to a section specific to his account or by his assigned role on the site.
The module supports Taxonomy and Menu modules for the management of access hierarchies.
Note that the module only controls access to content editing. It does not provide any content filtering of access restrictions for users trying to view that content.
D6 is approaching end of life. We'll be doing maintenance fixes only.
Module Grants makes modules that deal with content access permissions operate better on unpublished (as well as published) content. It also makes sure that access grants behave in an orderly fashion when such modules are used together.
Access grants are tested for unpublished content just as they are for published content
Allows modules that feature fine-grained access control (e.g. Workflow, TAC-Lite) to work together
While Module Grants' raison d'etre is to act as a catalyst amongst other modules when dealing with unpublished content and/or fine-grained access control, it does come with a handy feature of its own via the Module Grants Monitor submodule, which is bundled with the package download. After enabling Module Grants Monitor, a new item, Accessible content, appears in your navigation menu. Clicking on it reveals a summary of all the content the logged-in user has access to (i.e. view, edit) after access controls have been applied by the content access modules installed on your site. So if you have Workflow installed then what's editable to you and what's only viewable to you will depend on the workflow state the content is in. With the TAC-Lite module enabled it will depend on the vocabulary term(s) used in the content.
Thanks to dankh, Module Grants now also has Views support, allowing you to add to your views edit and delete links that properly honour permissions.
Version 1.x provided "two useful features which Drupal itself is missing: a simple permission to allow downloading of private files by role, plus the ability to combine both public and private downloads".
Version 2.x removes the "global" permission and implements a per-directory by-user and by-role filter instead, to let the administrator better tweak the whole website and increment the overall security.
People who want to view the node or download one of its private attachments are first redirected to a password query page (/protected-node). Once the user entered the right password, he is redirected back to the original node. Authorizations are stored in sessions, so users don't have to enter the password over and over again once provided (requires cookies.)
The module includes support for sending emails, views, and rules.