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.
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.
This small module adds the missing permission "view any unpublished content" and "[Content-Type]: view any unpublished content" to Drupal 7 and provides an replacement for /admin/content aka "Find content".
Taxonomy based Access Control List module provides taxonomy-based access to the nodes. tacl module provides only a common API but this package also contains a "frontend" - tacl_user that allows for managing per-user, taxonomy based permissions.
The target audience are site builders (tacl_user) and developers (tacl).
Control access to view, update and delete a node based on taxonomy term
Handles per-role settings (only in tacl API module)
Handles per-user settings
Handles multiple terms and vocabularies for the same node
Enabling access control for specific fields on nodes based on user location. Administrators create settings for each profile containing a list of countries and which fields are under control. It's possible per profile set default behavior to whitelist or blacklist.
Mark content as restricted so a permission is needed to view it.
Each content type has a permission to view restricted nodes of that type. There is also a global View all restricted content permission.
Each content type may be set to always or never restricted, restricted by default, or not restricted by default. The first two options just apply globally. The second two create a checkbox on each node form, but control its default value differently.
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 context reaction that will restrict access by role. If the current user triggers a context condition that uses this reaction they will either receive an access denied message or be redirected (based on reaction configuration). This module is still under heavy development but is actively being used.
A few use cases.
1. A site op only wishes to have authenticated users access the members/* path. Using this module one would create a path based context then disallow users in the anonymous role to access that path.
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.
CiviCRM allows administrators to create profiles for "public" (i.e. anonymous) users, but does not allow you to limit certain profiles to authenticated users? This module allows you to assign permissions by role to public profiles.
This module allows you to manage permissions for contents per user. It allows you to specify custom view, edit and delete permissions for each content. It work`s in opposite way how other access modules work, by provide a new user tab in user profile page with a list of private nodes, then you will be able to give this user permissions for each content (view,edit,delete)
How To Use
In node add page , select access type (public or private).
Go to the user page you want to give him permissions for the private nodes, and you will see a new tab called Node Access, with list of private nodes and 3 checkboxes for every node.
This module is a collection of helper modules extending Workflow’s access capabilities and granularity.
It currently includes 3 extension modules:
- Workflow user reference access
- Workflow role reference access
- Workflow transitions access
These modules are particularly useful when working on advanced workflows, roles and rights/permissions structures for projects such as collaborative platforms or intranets. Concretely speaking, for those having worked with Open Atrium and workflow, this module was successfully tested and brings a useful addition to fulfill advanced requirements.
The Workflow user reference access and Workflow role reference access modules work in a very similar way, to provide dynamic resolution of node access rights/permissions for a particular state in a defined workflow. By changing values of user or role reference fields in a given node, different users or roles can be granted/revoked access to this node, according to a specific workflow.
Workflow user reference access
This module extends Workflow by allowing CCK user reference fields to grant referenced users specific permissions/rights on the node, according to Workflow’s defined logic.