An alternative method to role management in #drupal

Posted by Craig Aschbrenner

 
 
I'm putting together a small drupal site for a group of very non-technical users.  There are three departments that together make up the whole team.  Each department has different responsibilities (i.e. roles / permissions) on the site.  I needed to find an easy way for this role management to be handled by department heads and not the site administrator (user #1).  

A couple of modules exist that provide role management capabilities / permissions.  These include the RoleAssign and Roll Delegation modules.  These modules were not ideal however.  

The RollAssign module required the administer users permission which gave too much power.  They would be able to modify users and roles outside of their department.  The Role Delegation module creates a hierarchy (of sorts) where we can configure (by role) what roles can assign other roles.  But then I would have to create a role for each department head just so they could add their department role.  

Luckily one of the other requirements for the site was that each department would have their own group with the department head owner of those groups.  The department heads were already adding / removing users to those groups so let's trigger off of those events to assign roles.  This turned out to be a lot easier than I thought!!

So as it turned out, I used the organic groups module with the rules module to handle role management for these departments. Here's how we accomplished this.

Step 1 - Create each role and assign the permissions
There was nothing out of the ordinary with creating the roles so not much to explain here.

Step 2 - Create each department group
I had already created out department group node type so all we had to do was actually create the groups themselves.  The one thing to note however is that I did write down the node ID for each group.  This will become important later on. 

Step 3 - Setup department heads
This simply was editing the group and changing the authored by field to the username of the department head.  I also manually added their department roles to them.

Step 4 - Create the rules
This isn't as difficult as it may sound but it does make use of the group node IDs we wrote down from step #2.  

Triggered Rule - Add Department Role (repeat this for each department)
  1. Create a rule to trigger off of the event: User approved to group by admin.  The department groups used membership moderation so this event made sense.  

  2. Add the condition: Execute custom PHP code.  We use this condition to check and see if the user is joining a particular department.  In the text box labeled PHP Code I entered the following:

    return (module_exists('og') && og_is_group_member(INSERT_GROUP_NODE_ID_HERE, FALSE, $acount->uid));

    This code first checks to make sure the organic groups module exists.  If we forget this check and the module is removed from the system for some reason, bad things happen.  The second part of the code uses a function provided by the group module to check if a user (based on user ID) is a member of a group (based on node ID).  You'll notice where we need to insert the group node IDs we wrote down from the earlier step.

  3. Add the action: Modify user roles.  For the arguments configuration of this action we want to make sure we select User that subscribed to the group and not the active user.  Select the department role we want to add and save the rule.
Triggered Rule - Remove Department Role (repeat this for each department)
  1. Create a rule to trigger off of the event: User unsubscribes from group.  I tested and verified that this event is triggered when a user manually leaves a group or if the group admin removes them.

  2. Add the condition: Execute custom PHP code and enter the following into the PHP code section:

    return (module_exists('og') && $group->nid == INSERT_GROUP_NODE_ID_HERE);

    This code first checks to make sure the organic groups module exists.  The second part verifies that the group this code is triggering off of is the group we want.  Remember we're removing one role for each rule.

  3. Add the action: Remove user role.  Select the role to remove and also don't forget to set the argument configuration to User that subscribed to the group.  Save the rule.

Step 5 - Drink Beer!
This is the most important step in the whole tutorial.  Let's not forget to follow it.

So what we're left with now are departmental groups that are managed by the department leads.  Simply by managing those groups the group members are assigned the appropriate roles to perform their duties throughout the rest of the site.  After this initial setup, at most the site admin (user #1) will only need to change the group owners should the dept. lead change.  

So there we have it, a nice clean way to manage roles using activities that the users were already doing.  I like that!

Comments [3]

How to create tabs within groups with friendly URLs

Posted by Craig Aschbrenner

 
 
I've had several folks ask about how I created group home pages that included tabbed content.  I had several threads on the Drupal forums that discussed how to accomplish this but I had always intended to follow up with an actual tutorial. 

Modules used in this tutorial
The following are the main modules I'll be discussing, however several of these modules depend on other contrib modules like token.  

Step 1 - Planning

Content Types
Planning is important so let's make note of what we want and what we're expecting to see.  To begin with let's assume that we're going to have two types of groups:

Social - This is a generic group for members to create and socialize with the community.
Team - This is a generic group for members to work together as a team.

Now it's time to decide what type of content can be posted to a group.  For this tutorial we're going to go with two content types (News, Photos).  Assumption is that the reader has basic knowledge of creating photos/images as nodes.  We are going to want a tab for each of these content types.

So what we're going to end up with is three tabs (View, News, Photos).

Context & Friendly URLs
When viewing a group it's possible to have a different layout, theme, blocks, etc.  When viewing content within a group we want to maintain that feeling for the user.  We also want our URLs to be friendly and make sense.  Here are the target URLs we're shooting for:

Social: mysite.com/groups/social/<group name>
Team: mysite.com/groups/team/<team name>
News List: <group url>/news
News Item: <group url>/news/<news title>
Photo Gallery: <group url>/photos
Photo Item: <group url>/photos/<photo title>

Oh... and we want all this to happen without admin intervention.

Step 2 - Basic Installation

Install Drupal and the modules listed above.  I'm assuming some basic knowledge of installing and configuring drupal and modules.  The default configurations for the contrib modules should suffice for now.

Step 3 - Creating Content Types

A default Drupal installation comes with the Story and Page content types.  We will create a few more and at least one content type to act as the group.

Group Content Types
Let's first create our content type that will act as our group.  Head on over to Administer > Content management / Content types > add content type (/admin/content/types/add).  Provide the name and type of the new content type.  Make sure to scroll down to the Organic Groups Usage section and select Group Node.

2860808_d5d5.png

Repeat that step for both the social and team group type.

Posting Content Types
We'll follow the same steps as above to create our News and Photo except that instead we'll select the Organic Group Usage to be Standard Group Post.

2860852_8aca.png

Step 4 - Configuring Automated URL Alias Settings

Head on over to Administer > Site building > URL aliases > Automated URL Settings (/admin/build/path/pathauto) and make sure you're viewing the Automated Alias Settings tab.  Then expand the Node Path Settings section and you'll find where you can configure automated path aliases for each content type.

For each group type enter the following pattern: groups/[type]/[title-raw]
For each of the posting content types enter the following pattern: [ogalias]/[type]/[title-raw]

You can vary those patterns but the key piece is the [ogalias] token.  The way that will work is if content is posted to a group then it will create an alias that beings with the groups alias.  If a piece of content is not posted to a group then that token is left blank.  

Caveat (a big one)
There is one issue with this particular method.  If content is posted to multiple groups then we run into an issue with the [ogalias] token in the path.  Only one alias is created.  If we were to use the Rules module to create multiple aliases I believe the system will still pull the first alias that links to the node.  If the particular group post is marked as publicly viewable then that isn't too big of an issue even though we lose group context.  What will be a bigger issue is if the content is marked private.  In this case we get an access permission error if the user does not belong to the group for which the alias is pulled.

If we remove the [ogalias] from the pattern then this is a non-issue.

This particular issue luckily wasn't a deal breaker for the particular site I was creating so I continued on with the [ogalias] token.  What I ended up with was restricting most content to a single group.  And for the few cases where select users can post to multiple groups, I used the rules module to enforce that the post was publicly viewable.

There are probably other methods around this caveat, however this tutorial will walk through my implementation.  I would love to hear of other solutions.

So on that note... let's continue.

Step 5 - Enabling the Group Details Block

The Group Details Block will provide a list of content that can be posted to a group.  This is the primary starting point for most of my users to create content.

The OG module provides the Group Details Block, however it is not assigned to any region by default.  To enable this block navigate to Administrator > Site Building > Blocks (/admin/build/block).  Locate the block and assign it to a region.  

Step 6 - Moving the Create Content Menu (optional)

The reason this step is optional is due to the Rules module I use later on in this tutorial.

By default the Create Content link appears in the Navigation block.  Most of my users will not need to post content outside of their groups.  So what I did was create a new menu (/admin/build/menu/add) and then move the Create Content tree to the new menu.  

To move the Create Content simply open up the Navigation menu and click edit next to the Create Content item.  Scroll down to the Parent Item drop-down and choose your new menu.  

Now we want to provide this menu as a block to users of a certain profile.  Head on back to your block listing page and you'll find a block for the new menu you created.  Simply assign it to a region and then click on configure.  Scroll on down to the Role Specific Visibility Settings and select the roles that can post content outside of groups.

2861277_ffc9.png

Caveat: This doesn't actually stop a knowledgeable user from manually typing in the URL to the node add pages, however my users are not familiar with Drupal and I've also used the Rules module as noted up top to help catch issues. 

Step 7 - Configuring Organic Groups (optional)

The reason this step is optional is due to the Rules module I use later on in this tutorial.

Most of the OG configuration can be setup however you like, however there is a particular setting I use that restricts users from posting to multiple groups when using the add content links in the Group Details block.  To find this setting navigate to Administer > Organic Groups > Organic Groups Configuration (/admin/og/og) and scroll down to the Group Details section.  Here you'll find the Audience Checkboxes option.  I've unchecked this option so that a user will not have the option to post to multiple groups when using the links in the Group Details block.

2861454_53c4.png

Step 8 - Configuring the Rules Module

The Rules module is a pretty powerful module, however it can be confusing at first.  Without getting too deep into the different aspects of triggered rules, rule sets, etc. I'll just walk through the rule I created.

What we're essentially doing here is creating several triggers, one for each posting content type, that will call a rule-set.

8.1) Enable Rules Modules
The first thing we'll need to do is make sure the proper sub-modules for rules are enabled as shown by this screenshot.

2861856_d661.png

8.2) Identify Forms to Trigger Events
Navigate to Administer > Rules > Form events (/admin/rules/forms) then select the checkbox Enable event activation message on forms and hit save.  This will give us the option to enable triggers on forms but we'll have to choose which forms to handle this on.

2861921_3311.png

8.3) Activate Events on Content Forms
Navigate to each form that we want to trigger off of.  In our case we want to trigger off of the News and Photos create content forms.

News: /node/add/news
Photos: /node/add/photo

There will be a message similar to the one below with a link to activate events for the form.  There may be several messages if multiple forms exist.  Make sure to click only on the link for the content type form we're interested in.  Confirm the activation by clicking the activate button.

2861936_0e15.png

8.4) Create Triggers for each Content Type Form
Navigate to Administer > Rules > Triggered Rules (/admin/rules/trigger) and select to Add a new rule.   Complete the form similar to the image below.  The important piece is the Event field which is outlined in red.  Save the trigger.

2861986_8759.png

After saving your changes you'll be given the option to add conditions and actions.  We will not be doing that part just yet.  Instead, repeat this step for each posting content type (News, Photos).

8.5) Create Rule Set
Navigate to Administer > Rules > Rule Sets > Add a New Rule Set (/admin/rules/rule_sets/add) and complete the form similar to the image below.  The key piece is outlined in red.

2862063_0195.png

8.6) Add Rule to Rule Set
Open up the rule set we just created and select to Add a new rule.  Give it a label and category but do not change the rule set drop-down option. Save your changes.

8.7) Add Condition to Check for Multiple Groups
Select to add a condition for the rule we just created.  The condition we're going to add is Execute custom PHP code.  Select next and complete the form similar to the image below.  The key pieces are outlined in red.  Save the condition.

PHP Code (copy/paste): return (count($form[og_nodeapi]['#post'][og_groups]) > 1);

2862094_8d26.png

8.8) Add Action to Set Form Error
Select to add an action for this same rule.  The action we're going to add is Set a form error.  Select next and complete the form similar to the image below.  The key pieces are outlined in red.  Save the action.

Form element ID (copy/paste): $form[og_nodeapi]['#post'][og_groups]

2862125_f109.png

8.9) Add Rule Set to Triggers
Now that we've created the rule set, we need to return to all of the triggers we created earlier and add the rule set as an action. The resulting trigger rule should like the image below.

2862147_84d7.png

Step 9 - Adding Views Tabs

I'm going to assume some basic knowledge of views for this step, however I will highlight the key components of the view that will bring all of this together to give you tabs on your group nodes.

Navigate to Administer > Site Building > Views (/admin/build/views) and add a new node view.  Within that view create a page display.  Setup that page display similar to the image below.  The key aspects are outlined in red.

2862213_3820.png

Page Settings -> Path
What is important to understand about the path setting is that we begin with node/%.  What follows (e.g. news) can vary based on the content type, however node/% ties us into the group node.

Page Settings -> Menu
Setup the menu similar to the image below.  The key component is outlined in red.

2862235_41d1.png

Arguments
Setup the argument similar to the image below.  The key components are outlined in red.

2862243_6a13.png

Step 10 - Drink a Beer!!
Congrats!  You made it to the end of this tutorial.  Phew... now go get yourself a cold one.

Summary
  • (step 4) - [ogalias] token is powerful but also limiting if content can be posted to multiple groups. 
  • (step 8) - A rule can trigger off of a form and stop it prior to saving if multiple groups are selected and the post is not marked as public.
  • (step 9) - The correct views settings can make just about any page view act as a tab.

I hope you enjoyed my first tutorial.  I need another beer simply for writing this tutorial.  :-)

Comments [2]

1 page of 1

 
 
?