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.
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.
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.
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.
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.
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.