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 you to configure a menu management, publishing for the client or the publisher.
With this menu you can select the pages or page types that they can view or edit in a dashboard are custom shaped menu accesible by the customer no matter the place where it is located.
Review Token provides a tokenised URL for bypassing access restrictions on unpublished content.
It can be used to provide per-node access for unpublished content to users without logins, though a specially crafted URL.
Currently incompatible with modules which provide workflowed versioning, as the module will load the current published content, rather than a specific draft.
This module was originally created by Boztek.
Sponsored by the Australian Government Department of Sustainability, Environment, Water, Population and Communities.
This extension utilizes several technologies from the RENDER technology stack (see RENDER project). In enables the user to browse through diversity aware information extracted from the articles stored in DRUPAL. A demo can be found at the Demo page.
Provides tools for Workbench Access when configured with the Menu access scheme and Automated section assignment.
This sandbox contains a Drupal 7 port of the Views Access Callback module.
This is a demo sandbox module
Restrict Control is a module which disable all CTRL actions and Right click actions
Following CTRL actions restricted :
CTRL+A ,CTRL+C ,CTRL+V ,CTRL+U, copy link, svae page etc
This module allows to create 301 redirections for unused entity paths, by bundle and language.
For example, if you have some content type, and you don't want people to visit it's corresponding "node/%node" page (because that content type is not a page-like content type, it's just an object-like content type that must remain hidden).
Another useful case, is when you desire to redirect Taxonomy term page to an existing View page, with a given exposed filter selected ($_GET parameter).
The configurable redirections are compatible with tokens, and exportable via Features.
A 'entity_bundle_redirect_alter' hook is available, so you can modify the redirection "on the fly" for each entity.
This module adds a checkbox in the edition form of each content type. Once checked, the content of each node of this content type will be uneditable (even by its creator).
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).
AUL module can be usefull when logic in content access in your site is wery hard and you don't want to create lots of grants per each user because it slows page load and causes long queries.
With AUL you can create for example just 3 realms for each user (one for view, one for edit, one for delete) and than add nodes to your AUL.
Using AUL we move our big list of access "locks" in node_access table. But hook_node_access_records will work quickly and we won't have long queries with access conditions because we don't have many access "keys".
Workbench State Permissions provides additional permissions for each Workbench state. Here's example for the 'Draft' state:
- Each Workbench state:
- Draft: View all content
- Draft: Edit all content
- Draft: Delete all content
- Each Workbench state for user's own content:
- Draft: View own content
- Draft: Edit own content
- Draft: Delete own content
- And new permissions for own Workbench Moderation transitions:
- Moderate own content from Draft to Needs Review
- Moderate own content from Needs Review to Draft
- Moderate own content from Needs Review to Published
As seen above, this adds very very many new permissions into the game and some additional complexity for the module at the same. That's why this would need much more testing.
This module was written for a need but didn't need this at the end. So this might work on some parts but is still a work-in-progress and needs more testing (and implementation). Decided to put this up if someone wants to contribute working on this.
Services Views Publish v0.1
This module extends the Services_Views module by creating an additional resource to a Services View endpoints. The additional resource appends "_edit" to the services endpoint path.
You can then access this endpoint like any other and will return the list of fields associated with given services view, and their respective attributes.
- Machine Readable ID
- Default Value
- Field Type
- Field Attributes Array (Conditional of Field Type)
- Character Limit
- Select Type
- Select Options Array
- Select Option Key
- Select Option Value
- File/Image Attributes Array
The module currently creates a new resource and does so to services only views.
The next challenge will be to display all these attributes within a given output structure. My main output structure is currently JSON.
After, I will concentrate on adding additional features, but for now this is sufficient for the beginning of this module.
NOTE: This module is in no way affiliated, endorsed, nor provided by ClickBank.com.
What is this module?
This module validates purchases on payment processor ClickBank, and provides a "secure" file download link. This module IS appropriate in the following situations:
- You already use ClickBank as your payment processor
- You don't want to pay for services to protect your digital goods at the point of sale
- The information you're selling does not need to be 100% secure
- your digital goods should not be available to search engines, or users typing in the url directly.
This module does NOT do the following:
This module allows you to restrict access to a comment by changing the theme of the comment if there is private.
Installation and configuration
Normally install the module in sites/all/modules, and enable it,
then go to admin/structure/types/manage/YOUR_CONTENT_TYPE/comment/fields and add a boolean field with the machine name field_private_comment.
Set it with
On value : Private comment
Off value : Public comment
Configure permission in admin/people/permissions#module-private_comment
This module can works with og-7.x-2.x. Permission of this module will be override by og : a private comment will be accessible only to group members.
Provides markup to indicate user roles and roles that can access restricted content.
How many times have you created a private content just to see your group, but would like some other group would be able to view this content without editing it and others can not see private content in your group?
This module provides the ability to give permission to display on a particular node, which was set to private for the group, a group to which the user is not a member. The groups have chosen only the ability to view, without compromising system security.
Delay access to content based on users role and content type.
This module allows Administrators to set permissions for publishing content under selected menu items for selected users.
The "administer nodes" permission is often considered too powerful to be used in a site. An administrator may want to allow a category of users to be able to administer (meaning (un)publish, set authoring, etc.) nodes, but only articles, while another group may do the same on another content type (pages).
This module tries to provide a solution to this problem by providing atomic permissions by content type. The list includes (Un-)publish content, (Un-)Promote content, (Un-)Set as sticky, and change authorship, applied on each content type.
Those permissions apply only on the content a user can edit, as they just alter the node's edit form.
This module shares similitudes with Publish Content module, provide more various permissions, but don't go as far concerning publish/unpublish permissions.
After enabling the module, just go to the permissions page and grant newly declared permissions to roles.
This module probably still needs improvements. Basic use case works, but it may be interesting to improve it, or to see if there is a way to integrate it to Content Publish.
None other than Drupal core's node module.
This module is developed by Alethia INC..
This sandbox is a fork of Domain roles module, in a hope to provide a working and full-featured version. The goal is to be able to grant specific roles (such as redactor, moderator) to users, only on designated domains (based on Domain Access module).
I forked so that development is not slowed down by any maintenance take-over process. When initial rewrite phase is over, I will suggest my code to current maintainer.
Right now, the module lacks many things, but foundation works.
The module stores a list of roles in a new column (roles) in Domain module's table domain_editors (which links a user uid to a domain domain_id). Two functions, domain_roles_revoke_roles() and domain_roles_grant_roles() allow to grant and revoke a list of roles to a user on a specific domain. When the user logs in a specific domain, he will automatically be given any role he should have on this domain, and will consequently be granted the associated permissions.
To do list
The module mainly needs two things:
- an interface to allow administrators to grant roles to users on specific domain (I'm thinking of an addition to user edit page, which will allow to grant roles on current domain)
This module restores the Priority feature of Node Access that was removed in Drupal 8.
Node Access Priority does not have a user interface itself, but if you use multiple Node Access modules, then those that support Priority will let you increase or decrease their priority relative to the others.
Allows granular access control to images and image style derivatives.
This module extends the content access module to put the view (any/own) [TYPE] to the drupal permissions form. So a user settings the access permissions doesn't have to switch between two forms and he doesn't need access to change content type settings.
The module is part of the ERPAL Distribution
This project is developed by Bright Solutions. We also offer paid Drupal and ERPAL integration and process consulting
The main ideas for this sandbox are
- ability to merge different domains into one multisite installation for single admin interface
- simplifying Domain Access to handle new outstanding features like entity and fieldAPI
- views and views bulk operations (actions) for mass editing domains data