Actively maintained

WF Tools is a collection of Drupal modules for building a WF management node. The management node is standalone Drupal site that is responsible for coordinating deployments of code, content and config in a coordinated way between multiple environments.

Modules

WF Tools consists of the following modules:

WF

The base configuration feature for WF.

WF Environment

Entity module for managing the individual environments for the site. The wf_environment_generic module is a feature which contains the recommended configuration for WF Environment.

WF Job

Each change for the site is handled in a job which tracks the content, code and config (in code as features). wf_job_generic is a feature with a working configuration.

WF Jenkins

Jenkins module for WF that contains many of the jenkins rules pre configured.

WF Git

Git repository configuration for WF.

WF SSH

Configuration of SSH key management to ensure SSH keys are properly synced.

WF Storage

Simple persistent key/value storage system.

WF User

Contains the roles and basic permissions required for a functioning WF management node.

Installation

It is recommended to use the WF Example installation profile to install the WF Tools. Additional steps are required to build a complete management node.

Development

Use Piazza through Drupal.
* Single sign on
* Automatically provision classes

API for integration with the Ponoko making system.

Loyalty Management is a drupal module which basically involves user's points and rewards. This would be further enhanced with many features.

Proin augue libero, tristique at consectetur at, dapibus a metus. Nulla condimentum urna nec magna sagittis sed sagittis quam rhoncus? Aliquam erat volutpat.

Target audience:

Before you read on, please understand this is an API only module. In other words, it provides extra features for module developers. It does nothing by itself. If you're a module developer, read on.

Overview

Drupal's core Field API defines a hook for field access, hook_field_access, that is restrictive as all module developers are aware. In other words, given field F, if a single module implementing hook_field_access returns a Boolean false, thus denying access to the field, Drupal will deny access to the field even if there is another module that absolutely requires access to the field.

Normally, this is acceptable but sometimes a module might want to override the grants for a field denied access by another module. Or, a module might contain logic to grant access to a field but another completely independent module has denied access. Because of the restrictive nature of the field_access function, which internally invokes hook_field_access, access will be denied.

There are numerous scenarios that are similar in nature to hook_file_download_access and hook_file_download_access_alter. For a possible scenario, read on.

Possible scenario: