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.
Have you ever encountered a scenario when you have content for which you are setting view permissions and you find you would love to require your users to have two of your existing roles to view it? By default Drupal will allow users with either of those two roles to view the content, and your only recourse is to find a module like Taxonomy Access Control to control your access from a separate location, or to create a 3rd role and require it to view the content (and then assign that 3rd role to untold numbers of users).
Access Join solves that problem! With either blocks or nodes (node usage requires the Content Access module) you can select a group of roles and with the flip of a radio selector change that content to require all the selected roles for access!
Access Join essentially allows the 'AND-ing' of roles together when setting which roles can view content. Drupal's default behavior is to use OR when looking up which roles have access to content. The module works for blocks and (with a very small core hack) nodes.
This is a proof-of-concept module. Don't use it on a production site. This is an API module, and it does very little by itself. You probably shouldn't install it unless another module tells you to do so.
The original purpose of the module was to create a user-level access system for all entities. The high-level goal was to make it easy for a module to get an answer to the question "does User A have access to view the comment with ID 37?" The low-level goal was to create a system that allows simple granting/revoking of access to perform certain actions on entities, and this system should work with minimal changes across the rest of the Drupal site. For example, if User A does not have access to view node 42, then that node should not appear in Views listings for that user.
However, the reason this module was written was to make it easier to build a system for user-controlled privacy settings. That architecture has gone down a different route, and the code in this repository currently doesn't reflect that effort and won't be continued. I may still end up putting the user privacy effort at this namespace, but it will look very different than what is here now.
Reduced node edit lets users edit a node even if they don't have access to the body's input format: in that situation, the body field will be hidden, but the user will have their normal edit access to the rest of the node. A good description of the problem is in issue #91663:
Users lose (or don't have) edit access to nodes that they should be able to edit, given their roles and associated access control settings.
The node.module node_access() function denies 'update' access to a user, if a node has an input filter assigned that the user cannot access.
This can be a problem because a user can create a node, the administrator may alter input filter permissions so that the input filter used to create the node is no longer accessible to the user (or edit the node and assign a restricted input filter to the node) - and the original user can no longer edit a node (the edit tab disappears from the node menu, and if the user tries to access the edit function via /node/x/edit URL, the users receives an access denied message.)
This module will hide the body textarea in those cases where the user doesn't have access to the input format; they can still edit the title and other fields that they do have access to.
We recently saw a scenario where the client wanted to create an ip whitelist for their intranet site. This site is the same installation as the client’s public site. It simply has a different domain and different content. The question was ‘How we can manage separate whitelists and blacklists (ie ‘list sets’) for each domain, rather than one list set per installation.’
Domain_ip behaves similarly to ip_ranges, but it differs in the following ways:
Ip_ranges is used to define an ip whitelist and blacklist for a specific site. This is okay except for installations that also use the domain_access module, because they have different domains for a same installation. In this case, they are restricted to single list sets across domains. Whereas ip_ranges works against all domains for an installation, domain_ip provides a separate list set for each domain, respectively, meaning each domain has its own independent whitelist and blacklist.
To manage multiple sites, on the administration page there is a separate ip settings tab for each list set. Each domain has its own administration tab.
This module adds Services support to the community module called content_lock that will prevent two users from editing the same node concurrently. This module exposes the main operations of content_lock through Services as a resource, so that content locking can be done over a web service API such as REST for mobile applications or third party integrations. The main operations it currently implements are retrieve, create, and delete.
This module exposes the following operations of content_lock as a web service:
retrieve - Find out if a node is locked and get info about a lock e.g. who owns the lock and when it was created.
create - Create a new content lock on a node. Locks a node preventing other users from editing it.
delete - Deletes an existing lock on a node. Only the lock owner may delete the lock.
The IP List module allows administrators to maintain and search list of IP addresses and IP address ranges, and associate each address or range with an arbitrary organization (string). The module doesn't do anything with this list, but the list can be integrated into other systems.
This module was written to be integrated with a Varnish ACL (access control list) and thereby allow non-technical administrators to manage a list of IP addresses and ranges that can bypass a content paywall.
Virtual Site allows a site admin to quickly instantiate a sub-site or standalone site within a single Drupal install. Virtual site instantiation includes, among other things, the ability to quickly populate a new site with placeholder content, menus, and selection of custom themes.
This module is in early development, so it may be a few weeks before the first development release is posted. However, this project page has been created to begin fleshing out documentation and feature set.
Allows for selected filefields to protect their files from download unless from users with appropriate role permissions. This allows a site to use Public file access method for the main site, but selectively secure a subset of files as required.
The module works by creating a secure subfolder under files. Therefore there are a few requirements:
* Ability to use .htaccess files to secure folders on your server (i.e. Apache webserver).
* Filefield_paths to put selected files in the secure folder.
Translation Workflow is a translation management and workflow for Drupal 7. Based on the new Content Translation which introduces entity/field translation for the new translatable fields capability in Drupal 7.
Audience provides an abstract definition of user groups and types in a given context. These definitions are called "Audience presets" and can be used by other modules to control different types of audience related actions or permissions. By using CTools these audience presets are exportables and can either get stored in a database or live in code provided by modules.
Modules can use these presets to check if a user is member of a given audience. Therefore audience_is_member_of($preset, $account, $context) is used.
Using audience_members($preset, $context) all users of a given audience in the given context can be retrieved.
Audience presets are instances defined by an audience type. Default audience types shipped with Audience are "user", "roles", "author" and "userreference". There also "intersection" and "union" that merge multiple preset definitions to one preset (e.g. User is "author of node xy" and has "role admin").
This module provides a hopefully simple way to restrict access to organic group content to subgroups of users. You first define the levels of access you need (for example: top secret, secret, confidential) and, using Drupal permissions system, assign permissions to view content of different levels to the different user roles.
You can also give content editors the possibility to restrict node access to different levels.
This module is particularly useful in combination with OG User Roles.
In some cases you want to publish a certain piece of content on a specific date. You can use the Scheduler project for this but this means the content will not be available until the specified date. This will result in people not being able to find content that will be published in the future.
Sites with very high numbers of nodes often times have trouble rebuilding their node access permissions since the default drupal behavior is to load and save each node individually. This is an adequate solution when you have a few hundred nodes, but when sites have 500k or possibly millions of nodes, this can take hours to days to complete. Needless to say, that can really cut into your beer time.
The goal of this module is to provide very quick, bulk inserts directly into the node_access table without iterating through nodes individually. the module supplies a hook "hook_quick_rebuild" and passes no data in. from there, modules that implement grants can use this to do a bulk insert for all the nodes that meet access criteria.
This module ties in to the rebuild permissions form, and takes over that functionality, so the UI works exactly the same way as before. If node access granting modules exist that this module does not support, a notice gets added to the rebuild permissions screen, and the process reverts to the slow way of building permissions.
Remember: There is no way to completely stop someone who knows their stuff from copying your content!
This module isn't useful in most cases, but can be helpful if you're trying to deter people from copying your content.
Premium redirect is a simple module for extending premium content module
(http://drupal.org/project/premium_content) the purpose of this module is
to provide a redirection to a configurable page (node) when a user without
sufficient access level is trying to access a premium content.
Currently the module is only capable to do a global redirection for all
premium content level.
The goal of this project is to provide a method for users to easily configure access settings to their own entities. The interface for configuring access will come from a shared access field attached to the entity.
Implement field hooks to define the new shared_access field type.
Define formatters and formatter settings.
Implement an extendible access controller class structure for defining access realms and their underlying functionality.
Define several default access realms (user, organic groups ... perhaps a few more).
Implement field hooks so that a form shows up on the entity content page.
Implement a standard sharing settings form that can hook into the access controller classes and be used to control access to the entity.
Provide autocomplete functions and hooks for displaying user name/og suggestions as the user types
Implement access hooks and query/query_HOOK alter functions to control access
Implement field access hooks so that the form only shows when the owner or configured admins view the page.