Drupal 7 Rules Relationships

Rules is a powerful module that allows you to script actions and results in Drupal without writing any code. Similar to the way Views allows you to structure complex queries, Rules lets you grab pieces of content and chain together reactions.

Rules syntax

When starting out with Rules it might not seem so simple. Just like the Views module, the learning curve requires that you familiarize and understand its terminology. I won't give a detailed tutorial that covers every part of Rules in this post, but I'll cover some parts that I found difficult.

note: To follow these examples, install Drupal 7, and enable Rules and the Rules UI. Rules depends on Entity and Entity Token, make sure you have those too.

Rules and Components

From the Rules config page, admin/config/workflow/rules, you can immediately create a new Rule, or click the Components tab where you can create a new Component. Components can be single pieces of a "Rule" or even a full Rule or Rule Set. These are defined on the Components manual page. The key difference between creating a Rule and creating a Rule from Components is the data it has to work with.

Data Selectors

Creating a Rule forces you to start with an "Event" such as After Saving New Content. The event you choose affects the type of data you can access from the Data Selector when you add conditions or actions on the next screen. This means that when choosing a node event like deleting, saving, or updating content, the data in the data selector will all be based around "nodes." If you choose a user event like After creating new user, then the data selectors will all relate to "account."

Standard data is always available, like site:current-user:uid or site:name. If the event is something non-content related, such as a "System" event like Cron maintenance tasks are performed, those parameters will be all you have to work with. This all works fine if the content you want to affect is directly connected to the Event, like adding a user role when you create a new user account. In any other case you might be frustrated when opening up the Data Selector menu and not finding the parameters you're looking for.

If you have a rule with multiple entities involved, you need to "Fetch" the entities you didn't start with. For example, if you wanted the site to email the author of a node whenever a comment was made on that node, think about the "chain" of connections and break it out.

Comment -> refers to a Node -> Node has Author -> Author has Email address

The Rule event would be After Saving New Comment, which gives you data selectors relating only to the comment itself. To get to the user, you need to follow this chain. Start by creating an action, Fetch entity by id. We're looking for a node id, so scroll through the Data Selectors until you see comment:node:nid. This is the id of the node the comment was made on. Give it a recognisable Variable label and name, such as "Fetched Node" and "node_fetched".

Repeat the process with a new Fetch entity by id action. Now the data from the node_fetched is available. Grab the node-fetched:author:uid to get the original author of this node, and call it "Fetched user" and "user_fetched".

A user entity has an email address, which is the crucial piece of data needed to send the mail- user-fetched:mail. Create an action to Send mail and use this in the "To" field.

Using Components with Rules

Components allow us to break out a single part of a Rule into something that can be re-used. In the previous example, a "chain" of fetched entities led to the result, sending an email to the author of a node. This single part of the chain could be something that gets repeated often, maybe you'd also want to email the author of a node when something else happens, such as when a page is updated.

That "chain" of relationships would be almost the same:

Updated page (node) -> Node has Author -> Author has Email address

Everything here is the same except for the event, so instead of repeating the same steps, they could be listed once in a Component that is used by two or more different rules.

A new component can be just a piece of a Rule, in this case we only need an Action set. Because a component is not triggered by an event, Rules doesn't know what data it should have access to, so it lets you add your own "Variables", such as a Node, User, or any other Drupal entity.

You can tell a component to "expect" certain data which it then allows you to act on. To put pieces of the previous rule into a component, start a new "Action" component, and tell it to expect a "node". Without adding that variable only the usual data selectors are available, but just by declaring that a node will be provided, Rules gives all the data selectors related to nodes, just as if this was a Rule with a node-based event.

From here, the same steps apply. Node relates to author, author has email address, send a mail to that address.

This component now only needs a node to function, so in one Rule the event could be After Saving New Comment, and another could be After updating existing content, but as long as we get to the node id, that can be passed into the new component.

Feeding Rules with VBO

Thinking about Rules as "chains" of components means that any arbitrary set of events can be triggered, as long as there is some way to "feed" the starting point into the component. In the next part, I'll go over how you can use Views and Views Bulk Operations to create custom lists of entities which you can pass to Rules to act on.