Dec 07 2015
Organic Groups (OG) has become a de-facto standard whenever a Drupal project requires granular permission control and many of our large scale Drupal installations use it extensively. In practice we’ve found some limitations, for example it doesn’t really provide an API and hasn’t always taken advantage of improvements of Drupal core.
I decided to do a rewrite of the concept using Entity API and Group was born. It’s a fresh look at how the functionality could be delivered and has received some positive feedback so far.,
Joining Deeson has allowed me to get the Drupal 8 version of Group out the door even quicker. Most of Group’s core functionality has been refactored using all the new, good stuff that D8 has to offer. In the D8 version I’m also planning new functionality, improved UX and some other minor improvements that I've noted while working on the D7 version.
In Group, everything is an entity. This means every group is a dedicated piece of content with the sole purpose of acting like a group. It also means the data is stored in a clear structure and allows us to expose a very rich API.
Developers love Group. Most of Group was written in an object oriented way. The main objects have classes with functions which a properly configured IDE will look up for you. A developer does not need to guess on the function names they expect to exist.
Group permissions are defined by the site builder and are then passed onto every group instance. This is done by configuring the “group type”, which is comparable to a node type for nodes. So you can configure a set of permissions for different types of groups, yet don’t have to worry about group members being able to fiddle with them.
In order to make the above work, the Group module defines a concept called group roles. These behave exactly like user roles would globally, but can be defined on the group type level. Group provides three special roles to make your life easier too: Anonymous (no account on the site), Outsider (account on the site but not a member of the group) and Member (account on the site and a member of the group).
In Group, there is no confusion about how to create a group. As soon as you enable the module, a link is added to the administration toolbar that leads to everything you need to make the magic happen.
The Group codebase is very well documented allowing other developers to quickly understand how it works. This has helped development of add-on modules for Group. Extra effort has gone into explaining all of the hooks exposed by Group.
Groups as a concept is something which exists on its own. With OG, the grouping functionality must be attached to a parent entity such as a node or taxonomy term. This means that grouping functionality in OG is mixed in with the functionality of its parent entity. Group is much more flexible because it can exist on its own.
Group has been developed with extensibility in mind. Group can be easily extended with a large number of hooks into the code. As the maintainer I have carefully tried to not privilege my own code over anyone else’s. Have a look at the group.api.php file for all the details.
If all of the above isn’t convincing enough, Group ships with built-in support for Views, Rules, Title, i18n, Node... Because it’s completely built on Entity API, any modules that integrate with entities such as Entity Translation will definitely work with Group.
Deeson has used Group in a few D7 projects already and I know personally of it being used in the US, Sweden, the Netherlands and Belgium as well. It has a few hundred reported installs on drupal.org which is pretty cool given how much of a standard OG has become.
About the author