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 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 is a very simple module that provides a CTools access plugin for using the access rules of another path. It does nothing without the CTools module.
When creating a custom page with Page Manager (for example, a Panels page), this module adds the 'Access to another path' access plugin in the Access tab. You may use it to mirror the access rules used by another path. For example, you might set up a custom search page, and use the access rules for the default Drupal search page, 'search'.
Gives automatic access to users if they are referenced somehow to this node.
It's scanning automatically for references with unlimited deep path, so you don't need to worry anymore how to configure your permissions correct, because it's checking for references automatically.
User 1 want to edit or delete Node 1, but the owner of this node is User 2.
But Node 1 have node reference (via nodereference) to profile of User 2 and User 2 have another reference (via userreference) to User 1. So that means that User 1 is referenced to that node, so give him access to edit it (you can customized other operations).
See following chart for example: http://drupal.org/node/520062
Using with view_own module, you can disable view permission for users and enable them only through references.
- Just enable the module;)
- http://drupal.org/project/cck module with nodereference and userreference module enabled
- knowledge how references are working and at least one content type with nodereference or userreference field
The TAC Unpublished module is an extension module for Taxonomy Access Control (TAC). It allows TAC's grants to control unpublished nodes.
This module allows administrators to grant certain roles the Use Taxonomy Access Control for unpublished nodes permission. Users with this permission can access unpublished nodes according to TAC's taxonomy-based grants. Users without the permission are denied access for unpublished nodes.
AUL module contains API and UI for node access system. AUL module can be useful in your project when content access logic is not simple.
AUL(Access User Lists) is very similar to the ACL(Access Control Lists). The difference that AUL creates access per user and adds nodes to it(ACL works vice versa. It creates grand per node and adds users).
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.
This module adds new field formatters for entityreference which check access before displaying rendered entities. Views has access filters such as 'published', but entityreference rendered entity formatter only checks entity_access() for the current user.
If you want to share and work with your documents online Google Docs, Zoho, iNetWord, Office 365 or Sharepoint are most likely to be - depending on how deep you can dig into your pocket - the solutions of choice. Especially, a large legacy of documents in proprietary formats, such as MS Word or Excel, may discourage from moving to an online editor. Additionnally, legal issues might arise if confidential files are hosted by a third party service provider.
WireDocs is a lightweight remote file editing tool. It takes the best of both worlds: Drupal as a CMS being responsible for hosting files and applications on a operating system (OS) doing the editing part. The approach automatizes a manual process: a file is downloaded, edited by a local editor and uploaded to its original remote location again. WireDocs makes this procedure completely transparent from a user perspective. The user only watches the application opening the demanded file and uploads are processed in the background after the file has been saved. WireDocs integrates with Drupal's content structure, namely the Field API, and currently supports file and image fields.
As a Java applet bridges the gap between Drupal and the OS the client must fulfill some prerequisites:
The Custom Listing Pages module provides the ability to create custom pages with data from existing content types.
- Display data from an existing content type with various options including:
- View Mode to display.
- Filter by one or more taxonomy vocabularies linked to the content type selected.
- Filter further by the tags for each selected taxonomy vocabularies.
- Sort by (title, last updated date, created date)
- Sort order (ascending, descending)
- Entries to display per page (pagination)
This module differs from Views as one of its main goals is to allow a content editor to publish listings of content without requiring administrative rights to the Views module. In a larger environment, you may need site builders or delegated site section owners, to create a listing of selected content. Using this module, this can be done and it's as simple as "Create new content" of type Custom Listing .. select the content type "profiles" , filter the output by selecting any assigned taxonomy terms and then select one of the pre-defined view modes. The Site Administrators will have created standard entity view modes for the selected content type, which can be themed with the necessary fields.
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.
Sometimes you want to be able to give simple URL access to content that would not normally be available to a particular user (or perhaps someone not even registered with the site).
Deep link module allows the direct access to a specific item of content under certain circumstances and limitations. Such as one-off or time-limited deeplinks.
The deeplink module provides a framework for generating special URLs which can be inserted into emails that allow access to a content item or page, and tracks the uses of that link.
The controls that go with deeplink provide the means by which users are selected, one allows selection by user - so only users will receive the deeplink and only those users will be able to use it; and by email: this allows you to enter a set of email addresses that will be sent the deeplink URL. Obviously this one is more limited in that unregistered users can look at the content.
Other controls, for example to select by role, could be built.
This module allow administrators of an ubercart store to allow access to view / edit / delete / change status of orders only to certain roles and based on current order status.
View orders by status and role.
(This feature replace 'view all orders' from Ubercart with view orders by status. For example you can now select for "role1" to view only New orders but not Completed ones. Also the user can search only orders that he has view access. Be careful that when you have 'view all orders' selected for that role this function is disabled and the user can see all the orders no matter of order's state.)
Edit order by role and status.
Delete order by role and status.
Change orders status by role and current order status.
This is useful when you are running a store, powered by Ubercart and you have certain users that handle the orders. For example if a group "shipping" only has to put orders in "Processing" or "Shipped" but NOT in "Complete" or "Payment Received" this module allow you to achieve this goal.
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:
Grant customers access to items like Nodes and CCK fields, Taxonomy, Roles etc. on your site when they purchase specified Ubercart products. Access can be configured to start immediately, after a fixed period from purchase, or on a preset date, and it can be given either for indefinite time, until a preset date or for a limited period based on the feature's settings.
Currently it has nodes and CCK fields handler that uses ACL and Content Access modules.
With future addition of more handler modules, it can grant access to other items (i.e. Taxonomy, Roles).