Administration

This is a module, not a theme. It extends the Drupal admin theme page options (admin/settings/admin) to allow settings of custom CiviCRM user and admin themes. So you can set a separate theme for public pages and admin section.

Note:
For drupal 7.x this module has been move to CivCRM core and it will be available in CiviCRM v4.0.5 onwards.

The Multiselect module defines a widget to be used with CCK fields. It allows the user to select multiple items in an easy way. It consists of two lists, one of all available items, the other of selected items. The user can select an item by moving it from the unselected list to the selected list. This module relies on the built-in jQuery features of Drupal and does not require any additional modules other than the CCK module set (Drupal 7 version has no dependencies).

This tiny module provides a new tab which allows a user to post a new revision of the body of a node only, this is, she will only be able to edit the body of the node. No other part of the node form is shown, besides the title for information only (no editable). In order to have this functionality without having to give 'administer nodes' permission to the user, this module needs a patch for the node.module. This patch creates new permissions on revisions and nodes (delete).

I have never had the time to develop this module as planned. I believe that other modules now available may do what it aimed to do. Please contact me if you can confirm this (or want to take this over).

RESTfulness lets you build and manage a REST API to a Drupal site via administrative pages on your Drupal site itself.

In the simplest use of RESTfulness, any functionality that is currently available via a menu hook can be exposed as a REST function. Using the full complement of the standard HTTP verbs (GET, POST, PUT and DELETE), you can provide, for example, a blog API that looks like this:

• GET /blog/entry/add (get "new blog entry" form)
• POST /blog/entry/add (post new blog entry)
• PUT /blog/entry/[nid] (edit blog entry)
• DELETE /blog/entry/[nid] (delete blog entry)

You use the Accept: header of the HTTP request to specify what kind of content you want to get back. This content type is mapped to a theme. So you might specify text/html or application/xhtml+xml to request a response in (X)HTML. Or you might ask for text/xml or application/xml to get an XML version of the same content. The content type - to - theme mapping you specify determines which theme gets used.

All of this configuration happens via administrative pages, and the REST functions and content type mappings you define are stored as Drupal nodes. Hence, your API itself becomes content that you can manage using the full gamut of Drupal capabilities. You have the ability to insert code as "glue" to connect your REST API to Drupal core functionality and modules, but RESTfulness aims to provide as much GUI-based configurability, and management of the API using Drupal's own and other APIs (such as Views), as possible.

Since the permission system only lets the admin allow/disallow creation of content types and can't specify WHERE they can be used, this module tries to solve that problem. This module allows the admin to limit content types available site-wide and by group. Group owners can then choose which types to use within their group. Group owners can use ALL content types ALLOWED to that group, even if that owner only ACTIVATES a subset of those types for use by his members. All regular permissions and roles are still valid and this module will not override your settings there.

Use 1.4 version. Looking for co-maintainer. See message in issue queue.

If you have a ton of users and a ton of roles on your site this module aims to eliminate errors in assigning roles and simply make it easier to keep track of who should be able to do what.

The site admin -

1. defines account types
2. assigns roles to each account type via checkboxes

Either the site admin or user admin -

1. assigns account types to users
2. assigns roles to users based on the limits of the account type

The user -

1. can't tell the difference

Permissions and roles behave as they always have. Account types pretty much just disable the role checkboxes on the user edit page so that the wrong role can't be assigned the user. This is important if you have a person that is a little technically challenged helping to administer users or who doesn't understand that a particular person isn't supposed to be assigned a role just because they requested it.

NEW FEATURE! You can now select roles that will be auto-assigned when the user gets the Account Type assigned to them.

The Util module is a grouping of commonly-needed utilities that are simple to code, everyone wants, but nobody actually codes them.

Right now, we have the following features:

Looking for co-maintainer. See message in issue queue.

Finally, a D6 update! Sponsored by www.iofc.org, so thank them.

This module adds custom disclaimers to registration and content creation forms.