Hello General Discussion forum.

I want to know if anyone would be interested in some modules I've written for a job recently (a site using Drupal 4.7). Under contract law, I have to get permission to release them, and having a number of people interested would be a bonus to my side. Or a disadvantage, depending on when and how I ask. But that's for my discretion, so here's the list.

These are the modules I feel would most benefit the community:

== wizard.module ==
Creates a multi-step wizard using Forms 1.0. Easy to port to Forms 2.0. Creating a wizard is trivial; call wizard_get_form($form_id, $stages) where stages is a list of callback functions which will return a form array.

Features include (listed, since I have competing modules, but they can't do all of this!):
- Ability to go both back and forward
- Very little futzing with POST (just op and form_id)
- No bypassing Drupal's functions or use of private Drupal functions. I only ever call drupal_get_form()!
- Ability to skip a stage if certain conditions match
- Ability to have more than one wizard per page
- Checks all input values up to current stage
- Ability to have different forms depending on what the previous stage does
- Ability to buffer input for end, or send it to a stage's submit function (for safety, once sent to a submit function, you can not go back to a stage before the submit)

In short, it's a damn good Wizard generator. It's all the benefits of Forms 2.0, but in Forms 1.0.

== acl.module ==
A mid-powered access module. This module fills the void between user_access and node_access modules, yet is fully capable of performing both roles. It even has a drop-in replacement for user_access, and [soon] a node_access extention!

The ACL module allows you to specify than any user / role of user / group of user / {whatever} can do some action on some item / node / {whatever}. It really doesn't matter.

You can create a hierarchical of permissions which children inherit from parents, too.

I wrote this module because I needed to be able to segregate certain portions of the site from certain users. IMO, I would love for this to become part of Drupal core, it's just that handy.

== widgets.module ==
It's like a block, only it takes some item (say, perhaps a node) to produce its information. Offers a super-set of the block features, while still retaining the ability to act just like a block. In fact, it can wrap a block, and a block can wrap it.

== groups.module ==
Building on the features offered by widgets.module and acl.module, the groups module allows you to group users together for whatever purpose. This is similar to the taxonomy module, only it allows free-form relations, and doesn't require a tree. Cyclic relations? No problem. This is a group, as per the mathematical definition.

Perhaps you have an e-commerce site? Well, why not make it so that everyone who bought a certain package is part of a special group? Or maybe you want to give a certain group of users certain rights, just like a new role (only you'll have so many different groups that it would overfill the number of roles), you can. via acl.module, you can even give group #1 permission to do "things" on group #2!

The entire body of a group is made up of widgets, so the display of a group is not static - display purchasers in order from latest-to-first, or whatever you want!

=============

Yes, these modules really do exist. They are highly orthogonal, and, IMO, would make great additions to Drupal 7 if the core developers were interested. But I need people to LET ME KNOW they'd like to see them to be able to convince those I have to convince!

~Mike

Comments

kleorn’s picture

Hello Mike,
YES, I think that all of these modules are of a very wide use in the Drupal community! Thank you for at least groups+acl idea released :) And I'll be sincerely involved with your success!

dickson.michael’s picture

A small snippet of one of the cooler things you can do:

/**
 * Implementation of custom hook_acl_access()
 *
 * This function will get all groups related by the parameter "ACL Rights" and transform
 *  an acl_access() on 'group' $item_key into an acl_access() on related groups.
 *
 * As such, if any group, by an "ACL Rights" transfer - direct or indirect (up to 6
 *  degrees of separation) - grants access to the group in question, access will
 *  be allowed (provided the results are not overridden by a lighter module;
 *  eg: user_acl_access(), whose per-user ACLs override per-group ACLs).
 */
function related_groups_acl_access ($op, $param, $item_class, $item_key) {
  static $recursed;
  
  if (!$recursed && $item_class == 'group') {
    $recursed = true;
    $user->groups = groups_get_with($user->uid);
    
    $gids = groups_get_relations($item_key, "ACL Rights", 6);
    
    $legal = NULL;
    $l = sizeof($gids);
    for ($i=0; $i<$l && $legal !== TRUE; $i++) {
      $legal &= acl_access($op, $param, 'gid', $gids[$i]);
    }
    
    $recursed = false;
    
    return $legal;
  }
}

I sure as all heck hope they'll let me release it. Anyone good at putting together a good business reason? I was thinking: if we release this code, and it gets picked up, other people will start using it. When other people use it, you can use their code without having to pay me to get it to play nice in the sandboxed environments.

kleorn’s picture

Oops, double post( Anyway good luck!

kleorn’s picture

Sure your company will benefit from releasing these modules under GPL. There will be more potential developers (so more functions, porting to future Drupal versions, support, integration with other modules), more (many more!) testers, so no bugs, at least some good reputation of the company in the open source community :)

ianr’s picture

acl would be the most useful!