576 Modules match your search

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.

Panelizer Variants

Panelizer Variants

This module adds the functionality to have Panelizer Variants based off of List Defaults in Panelizer Full Page Override. What this does is allows you to have multiple layouts for one content type based off a field selection. The functionality doesn't seem to really exist yet. WELL, now it does!

Field Access

Field Access API provide an wrapper to let other modules easily implement any access criteria for fields, both for view and edit mode.
It let developers define any custom rule for granting or not access to a specific field.

It is an API module, so doesn't provide any end-user feature on its own, and is intended for developers. Install it only if another module requires it or you want to make your own implementation.

Add Term like Node

[EN]
With this module you can add new Term like you add Node in menu Navigation.

[RU]
С этим модулем Вы можете добавлять новые Термины также как Вы добавляете Материалы в меню Навигация.

The idea and Realization: Rysevets M.
Идея и Реализация: Рысевец М.

Group Forum

Private forums for groups. Works with the Group module to provide private forums.

README:
http://cgit.drupalcode.org/gforum/plain/README.txt

Simple Ready Workflow

Simple workflow module preview

This module adds a new "ready" publishing option on node bundles and fine-grained permissions on publishing options.
It gives you a simple worflow:

  • Ready not checked (draft)
  • Ready checked (ready to be published)
  • Published checked (and surely ready!)

If you need a more suitable and customised workflow, you better look at Worflow module: http://drupal.org/project/workflow

Domain Workflow Bridge Module

This module provides a bridge between Domain module and Workflow module. It makes it possible to have a multisite setup with Domain module and also maintain a consistent and working publication workflow.

Alternatives?

Shared Access

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.

Development Roadmap

  1. Implement field hooks to define the new shared_access field type.
  2. Define formatters and formatter settings.
  3. Define widgets.
  4. Implement an extendible access controller class structure for defining access realms and their underlying functionality.
  5. Define several default access realms (user, organic groups ... perhaps a few more).
  6. Implement field hooks so that a form shows up on the entity content page.
  7. Implement a standard sharing settings form that can hook into the access controller classes and be used to control access to the entity.
  8. Provide autocomplete functions and hooks for displaying user name/og suggestions as the user types
  9. Implement access hooks and query/query_HOOK alter functions to control access
  10. Implement field access hooks so that the form only shows when the owner or configured admins view the page.

Hierarchical Select Access

Hierarchical Select Access

This module prevents certain roles from accessing the enhanced hierarchical menu provided by the Hierarchical Select module in content types.

Provides a UI to manage roles and content types.

This module helps solve this issue: https://drupal.org/node/298611

After enabling the module, go to admin/config/content/hierarchical_select/access
and tick the checkboxes next to the roles that should not access the hierarchical menu in content types.

GeoIP Country

If you would like to restrict your content to only show in a certain country, use this module.

It depends on the location module to provide a list of countries, and geoip api module to determine the country a user is in.

Domain Field Access

The Domain Field Access module is an add on module for Domain Access allowing you to restrict access to Fields based on the domain.

For example, you can have a field on domains A and B but not C.

Email downloadable

Description

Super simple module that does 3 things:

  1. Provides a configurable “Download this node” link.
  2. Sends an email with a link to the download using a unique code.
  3. If the code is valid takes you to the download.

What a download is it’s up to you. The module provides a basic edwd-node.tpl.php you can override it in your theme or your module to customize it.

Total Moderation Control

This module provides integration between Workbench moderation module and Total Control admin dashboard.

  • It provides content panes for the dashboard based on moderation.
  • It changes the view paths so that they work with total control instead of workbench.

URL token

URL token is an API module to make token-based access control simple.

There are two main features:

  • Request a token
  • Check that a token is valid (usually via a URL)

You should only install this module if another module requires it. This module doesn't provide any functionality by itself, it provides features for other developers to use in their modules.

One-time File Download

This module allows you to provide single-use URLs to files stored in Drupal's private file-system.

Regex Registration Deny

regex registration deny admin page

Small module that allows you to use regex to validate fields on the registration form.

While there are alternative modules to validate fields on the registration form, I found that none of them allowed for regex checks on the name and email fields on registration. They also seemed to be overly complicated or only allowed for checking on the username or email address.
This module is quite simple and allows you to check any textfield on the registration form.

Domain ip

Domain_ip local tab

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.’

This module solves that issue. It is functionally a combination of two existing modules: ‘Ip_ranges’ ( http://drupal.org/project/ip_ranges ) and ‘domain_access’ (http://drupal.org/project/domain).
Domain_ip depends on Domain Access.

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.

OG Node Access

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 is in response to #1101738: Repairing node access permissions without rebuilding all, thanks to @btopro for getting the ball rolling.

Status

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.

Nodelocks

Nodelocks prevents any user from deleting a node if that node has been added to a list of "locked" nodes.

This module serves as a lightweight alternative to Content Access, which can be configured to prevent the deletion of certain nodes, along with much more functionality.

Limit Visit

Overview

This module will count the number of times an authenticated user visits a page matching a path pattern. If the views per hour reach the established limit the user will be redirected to either an established page or a will be sent to the standard 403 page.

Permissions exist to allow roles to ignore the limits so administrators can browse without limitation.

Use Cases

The use case I initially built this for is to deter users from manually scraping through other user's profiles to build mailing lists.

Domain SSL

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.

For background information, see the original issue: #758714: Allow both http and https for a given domain?

Brain Forum Moderation

brain_forum_moderation.png

With Brain Forum Moderation you can add "Moderation" field to your
Brain Forum posts.
It creates an ajax link that opens a popup with variety of moderation options when clicked.

Development has just started so it will take some time before even the basic features are ready for production.
You can help by opening feature requests so i can figure out which features are actually needed.
These are some planned features:

Workbench Access Content Type

Extensible editorial access for the Workbench suite for granular access permissions by content types.

This module will add a new tab "Content Types" at the configuration page of Workbench Access, to provide permission by Section by Content Type.

This module was developed by Vardot for Georgetown University in Qatar.

Vardot

Access Private

This module allow accessing private nodes with a direct link.

Domain Override

Allows overriding page nodes on a domain-specific basis.

Features

  • Provides an "Override" tab on node pages that removes the current domain from the node's domain access, clones the node, and publishes the clone to only the current domain.
  • Copies translations of the node being overridden (if any), too, so they're considered translations of the newly created node.
  • Sidesteps need to use multiple url_alias tables (with Domain Prefix). Makes Drupal interpret the URL alias for a node that's been overridden as a path to this domain's version of the node. Example: node 1 (the node at node/1) is published to all domains with the URL alias contact-us. You visit the node from the subdomain "cats" and select the "Override" tab. Now a new node has been created (node 2), that's published only to the "cats" subdomain, and node 1 is no longer published to the "cats" subdomain. When you visit http://site/contact-us you'll see the content of node 1. However, when you visit http://cats.site/contact-us, you'll see the content of node 2 -- node 1's override.

Predelete

The predelete module hooks into the deletion process of nodes. By default it is not possible to react on a deleteion attempt before the deletion of a node. This is cured by providing the hook_predelete_node(). Other modules may implement the hook and add custom checks on the node that is about to be deleted.

The module ships with an API documentation and an example module that provides a single checkbox field. Nodes that contain the field could only be deleted if the checkbox is checked.

Pages