User access/authentication

This module is useful for people that plan on integrating a software licensing system on their site.

Out of the box, it provides the following:

• Ability to generate, edit & delete unlimited unique license keys.
• Ability for users to 'register' their key when they sign up for a drupal account, or by visiting a page when logged in.
• Users can have multiple keys registered to one account, and they are all displayed on their user page.

This module does provide functionality out of the box, however - it's power is in the hooks it provides which allow you to extend this further.

For developers:

• Licensing provides various hooks to add extra functionality to the licensing system
• Nearly all output is themable

Future plans:

• Rules module integration
• Views integration

If anyone is interested in helping out to progress this module, or has any ideas to make this module better - drop me a line in the issue queue! Your support would be greatly welcomed!

View some screenshots of this module in action:

• License overview
  

This module allows users to have a public name, shown as attribution and identity but not used for login. There are some significant limitations you must know about if you choose to use this module. See also http://drupal.org/project/realname for a more sophisticated module that accomplished something very similar.

Block Content Per Role allows a block to be defined which contains content that is displayed depending on a weighted set of roles. This is useful, for example, if you want one block for a subscriber role, one for authenticated and one for anonymous.

This is difficult to do with Drupal out of the box as a users with the subscriber role will also be logged in and therefore also have the authenticated role. The Blocks system in Drupal does not allow a "complex" selection such as "Users with roles XYZ but not ABC".

Each role's content is run through Drupal's filter system. This allows you to use any of the contributed modules which provide new features. I can strongly recommend the Token Filter module (along with its dependency, Token). This module allows you to define an input format which converts tokens in the content to their value. Why is this useful? Using the Token Filter module you could (once an input format is configured) add the following to any content for an authenticated role: [token global user-name]. This block will then dynamically contain the current user's name in the block.

This module is useful to publish nodes that require an agreement to be signed by each user before they can access the content. Examples of agreements include Non-Disclosure Agreements, End-User License Agreements, etc. Nodes of any type can be protected by agreements, and each node can have its own specific agreement.

QUICKSTART GUIDE

• Create a new content type to hold the agreements (e.g., Agreement).
• Open the admin settings (admin/settings/node-agreement) and select the content type you just created.
• Create a new node of type Agreement and write the terms of the agreement.
• Create a new node of any type and click the Agreement tab. You'll get a list of available agreements - just the one created above, so go ahead and select it, then submit.
• Try to access this new node: you're first shown the agreement to accept before you can access the node.

CREDITS AND SPONSORSHIP

Sponsored by AdHack. Thank you for your generous support.

If you feel this module is useful to your business, please consider the following:

• Make a donation through PayPal.

The Premium Content Access Permissions By Term module allows access to content to be restricted to certain roles by taxonomy term and Drupal role permissions and supports multiple access tiers.

It does not use the node_access table. It integrates with views via its use of taxonomy terms. It is similar but different to the Taxonomy Access Control, TAC Lite, Restricted Content and Premium modules.

When access is denied to a content item it supports redirecting the user to another path, or giving them the access denied page. Support for more behaviors can be added reasonably easily.

Installation instructions

1. Create a vocabulary for the access levels. A suitable name for the vocabulary is "Restrict access to". It must not be hierarchical or multiple. It can be required if you want, though this is usually not recommended.
2. Enable the vocabulary for at least one node type for which access can be restricted.

Grant individual users access to the results of specific webforms.

Adds a tab to each webform "edit section" that allows you to add users that should be able to access the results of a webform, but not adjust the form itself.

Users who are granted access this way then don't see the "edit" tab on the webform but only the "results" tab. They can then view results, download them, ...

How can you get involved?

• Help write or improve the documentation.
• Write a review for this module on drupalmodules.com.
• Help translate this module at http://localize.drupal.org/translate/projects/webform_submissions_acl.
• Report any bugs, feature requests, etc. in the issue tracker.
• Contact the maintainer with any comments, questions, or a quote for custom module customizations.

How can you be kept up to date?

• Enable the updates module.
• Read my blog.
• Follow me on twitter.

Author

Davy Van Den Bremt