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.
Field Access API provide an wrapper to let other modules easily implement any access criteria for fields, both for view and edit mode.
It let developers define any custom rule for granting or not access to a specific field.
It is an API module, so doesn't provide any end-user feature on its own, and is intended for developers. Install it only if another module requires it or you want to make your own implementation.
This module enables access control based on (and so requires) the Node Relativity module. It propagates the grants from a node to its descendants. You should use another module like content_access to provide the grant to the ancestors.
Just enable the module and select the content types that will inherit the grants at /admin/settings/relativity/access.
Allows for logging user actions on sensitive/critical administrative pages. Logging is limited to specific users and/or user roles (configurable). Logging only occurs on specific administrative pages (configurable). Features include:
Allows overriding page nodes on a domain-specific basis.
Provides an "Override" tab on node pages that removes the current domain from the node's domain access, clones the node, and publishes the clone to only the current domain.
Copies translations of the node being overridden (if any), too, so they're considered translations of the newly created node.
Sidesteps need to use multiple url_alias tables (with Domain Prefix). Makes Drupal interpret the URL alias for a node that's been overridden as a path to this domain's version of the node. Example: node 1 (the node at node/1) is published to all domains with the URL alias contact-us. You visit the node from the subdomain "cats" and select the "Override" tab. Now a new node has been created (node 2), that's published only to the "cats" subdomain, and node 1 is no longer published to the "cats" subdomain. When you visit http://site/contact-us you'll see the content of node 1. However, when you visit http://cats.site/contact-us, you'll see the content of node 2 -- node 1's override.
Node translation access module allows to control access to nodes for selected languages
When using the entity translation module for node translation, all the available languages will inherit source language. In this case, node will be visible on all available languages no matter whether it has translation or not. Using entity translation module you can deny access to nodes of selected language. You can deny access to languages per node. Users will see standard access denied page.
The Mode module is a utility module that allows administrators to manage different permission sets and switch between them conveniently. It works by manipulating the permissions table during each switch.
Example scenarios where this module will prove useful:
GeoIP Role allows to dynamically grant roles to the current user according to his IP address location.
It depends on the GeoIP API module.
Currently, GeoIP Role allows to attach countries to roles, thus defining geographical zones.
When a user visits your site, he dynamically gain the role(s) attached to the country reported by his IP address.
GeoIP Role may be used with any other module like Nodeaccess that controls access based on user roles.
The Open Semantic Framework (OSF) for Drupal is a middleware layer that allows structured data (RDF) and associated vocabularies (ontologies) to "drive" tailored tools and data displays within Drupal. The basic OSF for Drupal modules provide two types of capabilities. First, there are a series of connector modules such as OSF Entities, OSF SearchAPI, OSF Field Storage and OSF Views to integrate an OSF instance into Drupal's core APIs. Second, there is a series of module tools used to administer all of these capabilities.
By using OSF for Drupal, you may create, read, update and delete any kind of content in a OSF instance. You may also search, browse, import and export structured datasets from an OSF instance.
OSF for Drupal connects to the underlying structured (RDF) data via the separately available OSF Web services. OSF Web Services is a mostly RESTful Web services layer that also allows multiple Drupal installations to share and collaborate structured data with one another via user access rights and privileges to registered datasets. Collaboration networks may be established directly to distributed OSF Web Services servers, also allowing non-Drupal installations to participate in the network.
File access by node type allows website administrators to select which roles can access files belonging to nodes of a certain node type. This goes beyond simple field permission, since there can be situations where users might embed an uploaded file into a Body textarea, or a WYSIWYG editor.
This module allows the restriction to work even in those cases by intercepting the file download before it happens. It also respects other access control mechanisms, since it defaults to either restricting access, or delegating it further. If the file download is not denied, and no other module is there to make a second decision, then it will download it. This allows for future integration with other modules and should be consistent in how Drupal handles access control.
The predelete module hooks into the deletion process of nodes. By default it is not possible to react on a deleteion attempt before the deletion of a node. This is cured by providing the hook_predelete_node(). Other modules may implement the hook and add custom checks on the node that is about to be deleted.
The module ships with an API documentation and an example module that provides a single checkbox field. Nodes that contain the field could only be deleted if the checkbox is checked.
This module does nothing on its own, other than to attempt to make harmony out of multiple node-related "access callback" changes made in the hook_menu_alter() implementations of various modules. It does this by ensuring that its own "access callback" handler is called for each of several node-related menu paths ('node/%node', 'node/%node/edit', etc.). This handler then calls all other "access callback" handlers for the given path, returning TRUE if any handler grants access.
Prevent access to OG private posts except to privileged users and OG group members.
This module serves to ensure that OG private posts remain private to the Organic Group(s) to which they're posted, regardless of which other modules may be trying to grant access.
Organic Groups usually does a fine job of ensuring that group posts marked "private" will only be accessible by group members. But other access-control modules may still grant non-group-members with access to those nodes.
This module adds an additional check to the node access system, so that group posts marked "private" will be inaccessible (for view, edit, and delete operations) to anyone who is not a group member, even if other modules grant such access.
This simple module allows nodes with required elements to be left empty when the node is in selected workflow states.
This is Useful for 'draft', 'unpublished' or 'staging' kind of workflow states where the node isn't yet finished. It's especially useful when using nodes as complex formal applications over several pages where users typically spend lot of time to fill out and work with them.
The FAPI '#required' attribute will recursively be unset after the form is build, but enabled again just before rendering, giving the user the same visual experience as before.
After much consideration, I've decided to scrap this module and take the project in a different (and, I hope, far better) direction as Access Control Kit. No further development will be done on Conditional Roles, other than to provide a migration path to ACK.
Unlisted adds a checkbox for 'Unlisted' to the node publishing options. Unlisted nodes are not access controlled, simply excluded from all Views listings. This makes for a casual publishing workflow in which an author can send a link to someone to review a post before listing it publicly. This is especially useful in cases where the reviewer may not want the barrier of logging in, or the author may not want the hassle of complicated access control choices.
Put a time frame on posting and editing content in organic groups.
This module restricts access to group content within a time frame (or time window) specified in date fields attached to the group entity. Depending on how the date field is configured, the date field behaves either as a simple due date or a 'from – to' window.
This module allows the site admins to restrict access to certain paths or the entire site, based on the visitor's IP address.
It allows users with a certain role to bypass the system, it allows a list of paths to bypass the system and it allows you to make a list of paths which can only be seen by whitelisted IPs, and another list which can not be accessed by blacklisted IPs.