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.
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.
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.
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.
A very simple node access module that limits access to nodes if they are published in the future.
If the Node's "Authored On" property ($node->created) is equal to or less than the current request time, then a visitor may have access to the node. If it is after then a visitor will not see the node listed or be able to view it directly. NOTE: This does not effect edtorial access.
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.
Le Gate is a simple module that restricts user access to pages on a site, and then provides two mechanisms
by which users can then gain access. It was first developed as an "age gate" module to allow access to a site
only when an appropriate age is selected (>15yo for COPPA). But then we decided to make it more generic.
When a user tries to access a restricted page they are redirected to a configurable and themable page
Partial comment display module provides a facility to admin to configure the number of comments which will be shown to user on node view page. This configuration is available under comment settings tab in each content type.
This module will not work for those roles who has "post comment" permission.
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.