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.
Available callback functions are defined by modules using hook_views_access_callbacks() function (in the same way as in hook_perm()), then could be set in in view's "Access restrictions" configuration.
When Drupal sends an email to a user, this module changes links so that said user is automatically logged in if they click any of the links in the email. For example, if you send them a subscription notification, if they click on the link to the original post, they will arrive at your website already logged in.
It works by appending a one-time login token to the end of each link. The login token expires when it is used, or when 30 days passes. In the case that it has expired, the user needs to log in in the normal way.
At first sight, you may think it's just another fork of already available module on drupal.org like taxonomy_access or tac_lite. First one is a taxonomy control access based on roles, second one is a taxonomy control access based on users. But both of those modules miss the - according to me essential - inheritance notion :
if you have access to one term, you don't automatically have access to the children nodes. My module does take care about inheritance and this way permit a powerfull user access control.
Module maintainer @podarok
Drupal Firewall was implemented due huge data importing into commerce, ubercart, feeds and other modules
The main idea - disabling redundant hooks, functions and other procedures when doing background tasks (mostly via cron or custom page callback)
For that we use hook_module_implements_alter
Module config page (sometimes You have to know this address 8) ) admin/config/dfw/config
This module is no longer active. The Masquerade module does what this module does, only better, so go and download that instead.
The difference with Masquerade and my module is that mine displays the "switch" link along side the "edit" link for users, where as Masquerade has the option to masquerade as a user in the operations dropdown. Masquerade also logs the user-switching as well as giving you a switch-back link, so it is truly superior.
Module provide an additional functional for content managers:
1) Manager role
2) Manager menu with ability use this menu in "admin menu style"
3) Hide unnecessary fields on node add/edit forms.
4) Show add "content type" button on selected node type / view pages. (Contextual links style)
1. Copy the entire pager_for_content_type directory
the Drupal sites/all/modules directory.
2. Login as an administrator. Enable the module
in the "Administer" -> "Modules"
1. Go to "Configuration" -> "Manager Access"
2. "Manager access fields" - set checkboxes for fields and for roles. Selected fields will not show on add/edit form for user which have selected role.
3. "Manager links settings" - set checkboxes for content types and for views. On selected views and content types will be added additional contextual links for manager.
4. Go to "People" -> "Permissions" and select roles for "Use manager links" and "Access top manager menu"
5. Go to "People" and add manager role to your user
This project has been sponsored by: Volcanoideas Drupal consulting and development.
Generally, this project enables content authors to see from any current content (entity) its dependent entities content.
Project overcome a major content control difficulty for content authors.
Provide content authors ability to track external content which refers to current content, without the need to check mass of external content to find out whether each external content refers to current content or not.
Content dependency main advantages:
Easily manage content dependencies - you can view/update for each content entity it's dependent entities from one places.
Backward Compatibility - You can install this module & start use it without need to perform any change in your content structure.
This module allows you to restrict access to term page based on user roles. It depends on the Drupal core taxonomy.module—just activate both modules and edit a term item as usual. There will be a new fieldset that allows you to restrict access by role or close term page for all roles.
If you're interested in helping with this or have problems with this module, please contact me or open an issue in the Term per role module issue tracker.
Installation is like with all normal drupal modules: extract the 'term_per_role' folder from the tar ball to the modules directory from your website (typically sites/all/modules).
Just open to edit edit or create term and add seetings to new fieldset that allows you to restrict access by role or close term page for all roles.
In admin area(path is admin/config/content/term-per-role) you can change behavior if access is denied to page(show page 404 or 403).
This project has been sponsored by: Volcanoideas Drupal consulting and development.
Privacy Per User provides a simple framework to enable privacy settings per user, similar to the privacy settings on a site like Facebook. Those settings may be used to check access for display of entire pages, elements of a page (such as in a theme), or as an argument validator in a View. This allows individual users to control access to things such as their profile, specific elements of their profile, or lists of content they may have made, e.g. flagged nodes. It offers a flexible API to allow additional privacy states to be added (e.g. friends only) and an exportable set of privacy types.
When you update the privacy settings of an Organic Group, you may need to rebuild the node access settings of the nodes assigned as posts to that group. Unfortunately the node access rebuild system focuses on rebuilding all nodes, instead of just those affected.
This module has forked the node rebuild system to allow developers to target one or more Organic Group's for node rebuild. It has the following features:
Automatically detect when group privacy changes as the result of the node edit form and directs users automatically to the batch edit screen.
Integration with Spaces allowing group administrators to rebuild node access for their group at need.
Developer API in the form of a og_node_access_needs_rebuild() function to add new groups for rebuild.
Plays nicely with general node access rebuild flag, allowing general node access to trump og-specific rebuild.
This module is set for maintenance and bug fixes only and is unlikely to get much in the way of new features. Good, minimal feature patches are welcome. As we currently have no use for a D7 version of this module, we are open to requests to create and co-maintain a D7 branch.
Sponsored by GoingOn Networks. We provide a unique academic life platform that enriches the student experience through the focused application of Drupal and other technologies.
Gives content access permissions on a book child page if users have access to the root of the book, typically provided by another node access module. Checks view, update, and delete grant operations, and can pass those on to the referencing content, or trigger a different grant configuration according to settings(not yet).
The webform module provides ways to limit access to the webform based on user roles, a maximum number of submissions and more. If you want to limit access to a webform but still want it to be accessible for anonymous users, the webform authorization code module is right for you.
In the webform configuration you can set a pass phrase which is then used to protect access to the webform.
When a visitor opens the webform, the form and body content will be replaced by a pass phrase form. If the proper pass phrase is entered access will be granted to the full webform.
This module adds support for mixed use of SSL and non-SSL (http and https protocols) for the 6.x branch of Domain Access.
Currently, Domain Access allows you to specify per domain whether to use http or https, and if a domain source is configured, URLs throughout that site (including form actions and so forth) use that protocol. However, if your site mixes use of both protocols (say, with SSL to protect the user login page, admin pages, or authenticated sessions in general), Domain Access does not support that configuration.
This module allows granular control of block visibility on a per-domain basis.
Use this module to set different visibility rules for each domain on your site, as setup by the domain access module. You can use this module in conjunction with the Domain Blocks module to restrict blocks from certain domains.
After installing your module, visit a block edit page and see the extra options added to "page visibility".