Drupal: Group Module, an alternative to Organic Groups Module

David G - DrupalI have had many projects lately where the content on the website is supposed to be available to groups of contributors. Eg, 5 staff members should be able to create and moderate content within a particular section of a website. Or, for sections of a website their should exist the idea that certain members are Editors, and other members are Publishers of content. A recent addition to the modules on drupal.org which support building group based or community based websites is the Group module. This blog post will provide a brief overview of the module.

What is the Group module?

The group module is similar in concept to the Organic Group module but seeks to be easier to develop against and to utilize Drupal 7 entities throughout the system. From the project page:

Organic Groups allows content itself to be groups, which isn’t always what people want. It relies on an entity reference field to keep track of the ties between a group (node, term, …) and its content (node, term, user, …)

Groups instead creates groups as entities, making them fully fieldable, extensible and exportable. Every group can have users, roles and permissions attached to it. Groups can also act as a parent of any type of entity. Seeing as a group itself is also an entity, creating subgroups is very easy.

This distinct may seem vague to some individuals. But, as an example creating subgroups in Organic Groups (for Drupal 7) requires an additional module OG Subgroups to achieve this functionality because it’s not baked into the native implementation of OG.

So the Group module is competition for the existing Organic Groups module and Monster Menus modules.

Example Usage of Groups Module

Since I require this functionality in upcoming Drupal sites I wanted to test drive it on a small site. On this site I wanted to create a private “IT Wiki” or IT section of website, and then be able to have custom public content within the website. So I went ahead and installed this module and it’s submodules, along with the entity_token module to supports Group based tokens for content.

After installing this module, the author went to great lenghths to centralize the administration of this module. It will add a Groups menu item to the administration menu. From this menu you can manage your:

  • Group Types
  • (global) Group Roles
  • Group based Permissions
  • membership lists and subgroup

… whew that was all a mouthful! Per Group if needed you can define if a group can be configured as a subgroup, or create Roles within a specific group specialized to that group.

So to add a Group you head over to admin/group/type and create a group and give it a name.

Example creating a new Group for private IT based section of a website.

Example creating a new Group for private IT based section of a website.

After creating a group you will likely want to create at least gobal group role(s) which can View, Edit, Delete and Create content for groups. By default the module only ships with an Administrator group role that can do everything — but your group members likely will be able to do a subset of permissions within a group, and not for example manage all Groups.

The module-wide Group permissions allow basically an override mechanisms for core Drupal roles to use Groups.

The module-wide Group permissions allow basically an override mechanisms for core Drupal roles to use Groups.

Globally using the Group module you may create Group aware Roles as needed; either global Roles for all Groups or per-group Roles.

Globally using the Group module you may create Group aware Roles as needed; either global Roles for all Groups or per-group Roles. Here I create a Contributor role for all Groups.

The Contributor role has its own set of permissions applicable for any Group.

The Contributor role has its own set of permissions applicable for any Group.

 

Once you’ve created some usable roles for your Group(s) you can then add members to a group. As an example I added a member called testmember, to my IT group as the role Contributor. This means this person is allowed to view this private IT section of my site and edit content.

Sample node showing group membership of the content to a Group.

Sample node showing group membership of the content to a Group.

When content is created/edited an option to set the group membership for the Node is given (eg, “what group does this page belong to?”). Depending on a members group memberships the list of groups would very per Contributor, it would be up to them to assure the content is assigned to the correct group on creation and save.

Lastly, I wanted to place this group based content into a particular menu section of my website. I actually struggled a little achieving the correct URL seen above for my IT page. The solution is to say for node content to use the Group tokens and menupaths to set the Pattern for the URL on save. So in the administration for URL aliases of my Drupal site I set the default content path to:

[node:group]/[node:menu-link:parents:join:/]/[node:title]

Assuming all content in your site is to be owned by a group. This works. See the URL in this screenshot to see the alias in action:

Group url alias in action for a given Node of content.

Group url alias in action for a given Node of content.

So as you can see from this tutorial. We’ve created a Group, assigned a user with a Role to access group based content they are a members of and assured to content appears to be within the correct section of the website to visitors of the website. The public, cannot access this section of the site.

Some closing thoughts on this module:

  • Personally I’m not sure how well it integrates with say Workbench for workflows. I believe workbench may only work with Node based content and Group provides it’s own Entity for a group so Workbench may not be able to see it. But, Group is fully Entity driven so Rules and other modules should be able to make use of it … implementing workflows probably isn’t impossible.
  • I think it would be nice to be able to say this group is Public (content) which all others are essentially membership based for Editing and Viewing. Right now to implement universally public content, that content should not belong to a group. I think it’s cleaner to think of all content on your community group based site as “group sets” where everything on the site is at least contained within 1 group.
  • If my above closing thoughts are wrong I apologize, as I’m primarily evaluating this module at this time (should the module maintainer read this :D).

Looking for quality web hosting? Look no further than Arvixe Web Hosting!

Tags: , , , | Posted under Drupal | RSS 2.0

Author Spotlight

David Gurba

I am a web programmer currently employed at UCSB. I have been developing web applications professionally for 8+ years now. For the last 5 years I’ve been actively developing websites primarily in PHP using Drupal. I have experience using LAMP and developing data driven websites for clients in aviation, higher education and e-commerce. If you’d like to contact me I can be reached at david.gurba@arvixe.com

Leave a Reply

Your email address will not be published. Required fields are marked *