This module provides permissions to view user profiles depending on what
roles the profile requested to be viewed has.

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.

Example 1:
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.

INSTALLATION

- Just enable the module;)

REQUIREMENTS

- 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

SUPPORTED MODULES

http://drupal.org/project/content_profile

RECOMMENDED MODULES

http://drupal.org/project/view_own

Other similar modules with access functionality through references:
http://drupal.org/project/nodeaccess_nodereference

This simple modules aims at linking group members and nodes via taxonomy.

What is the purpose of this module?
This module will enable you to test out different roles, all from one and the same user.

Under pacs, every drupal node turns in a container wich can hold normal content but also other nodes of any type, much like a directory in an apache web server. You can control the access permissions on each of the nodes for each single defined user role. Nodes with no explicit permission settings inherit them from its parent node, like in a directory tree.

Provides a framework for selling access to local or remote resources.

In practice, this means that there’s a license entity, usually created during order checkout, that holds information about accessing the purchased resource, and it has a status and an optional expiration date. This allows selling access to anything from files to node types, or perhaps ZenDesk tickets and accounts on remote sites, all using a common API, while always having a record of the purchased access for the benefit of both the store administrator and the customer.

Drupal 10

Use 3.0.x. If you were using a recent dev release of 8.x-2.x, the code is identical. The only differences are related to dependencies.

Works with Commerce Recurring for license subscriptions.

See the README for configuration instructions.

Drupal 9

If you are working on a new site, use 3.0.x.

If you have been using a beta or earlier dev release, you'll need to upgrade to the latest 8.x-2.x release first. See the release notes for step by step instructions.

Works with Commerce Recurring for license subscriptions.

See the README for configuration instructions.

Drupal 7

Features

• Any kind of local or remote resource be licensed.
  Licenses are entities. Licensed types are implemented as classes (thanks to Entity Bundle Plugin) and contain all relevant logic.
• A license can be configurable, allowing its fields to be edited straight on the add to cart form (through Inline Entity Form), or through a checkout pane.
• Remote licenses are synchronizable, allowing a remote service to be contacted each time the status changes (to create / suspend an account, or anything else).
• A checkout pane for the "complete" step shows the access details of the bought licenses, and in the case of remote licenses, refreshes itself until advanced queue processes the sync.
• Licenses can be time limited, and are automatically expired (by cron) once that time passes.

Submodules

• commerce_license_example: demonstrates the API for both local and remote licenses.
• commerce_license_role: allows roles to be licensed. The customer receives the role
  referenced by the purchased license product. Changing $license->product_id (from "Basic Membership" to "Premium Membership", for instance) changes the owner's role.

Control access to OG content by OG role. Uses OG Role Reference Field (og_role_field) to choose the allowed roles for each node, so you can have select lists, checkboxes, radio buttons, etc.

Private is a very simple node access module that gives each node a 'private' checkbox.

Provides a field that generates an entity access link.

This module allows any user with the "invite new user" permission to send role invites to an email address assuming that you are using external authentication (such as LDAP or Shibboleth) and that

This module provides a simple way of adding IP addresses to Fastly ACLs.

Unpublished Nodes Redirect is a simple module to allow admin users to setup redirects for each node type on their site. They can also set different types of redirects per node type.

This is simple module that adds a trigger when a user password is updated. It uses the built-in trigger module from Drupal core.

The trigger can be setup at build/trigger/node.

Field required by role is a module that improves core "required" functionality.

Better Passwords attempts to help users create better passwords by adhering to current recommendations from the US National Institute of Standards and Technology (NIST).

This module makes it possible to make people be able to create users, without granting them the permission to "administer users".

Overview

Creates auto login URLs on demand and through tokens.

Mobile Number is a field type that provides mobile number validation and verification, and can be used for two factor authentication.

Helps you do more with users on your Panopoly site!

Scheduled Publish

This module contains a field type for nodes and medias to update the moderation state of some contents via a cronjob.

This module allows an administrator to import and register user accounts from a CSV file.

Openlayers 3: features

Openlayers

This module disables the "Username" field on user registration and user edit forms and generates a username automatically using a token or module provided pattern. The pattern could therefore be based on other profile fields (like first/last name), a regex version of their email address or a random string.

This module is complimented by logintobogan, which allows users to login with their email address (and therefore makes usernames redundant for the user, but of course still necessary for Drupal's backend - where auto_username fits in). The realname module also compliments this module, because it ensures any username displays are displayed as "Firstname Surname", which may be easier to read.

Required Modules

• token (any version)

This module was originally developed by Palantir.net for the Chicago Public Schools Virtual-Kindergarten program.

This simple module adds a 'Show password' checkbox to password fields. This allows users to toggle masking of their password.

Further reading on the usability benefits of this:

Sometimes we wanted to be able to allow some users to add other users, but not change any user's password.

This module: