Most of this form is fairly straightforward, add a label and description. Click over to the “Actions” tab and add a new action, select type “Send email” and click continue. First we’re going to work a bit backwards and create the send mail action. Now that we have our variable setup we can start creating some actions. The type will be “View result variable” click continue and give it a label, description and select the view we just created. Now that we’ve created the source of our user list we’ll head over to /admin/config/workflow/business_rules/collection First thing we’ll do in here is click the “Variables” tab and add a new variable. You’ll then add “user:mail” as the only field, click save and you’re done with views config! The only thing you’ll want to do is change the pager settings to “display all items” and add the filter “user:roles” filtered to the role you’d like to send the email to. Select show “Users” and click save and edit. First we’re going to start by building a simple view. Trust me, it’ll make sense when it starts to come together. So I’m going to build this in a way that might seem a little out of order if you’re used to the Rules workflow. You will notice though, that how we’re going to build it using Business Rules opens up the ability to create a list of email recipients from any arbitrary set of filters rather than just role. This is something that was a fairly simple action that could be fulfilled easily with Rules in D7 but is currently absent in the D8 variant without the use of a bunch of patches, one of which unfortunately is to core. What we’re going to do is create a rule that upon saving a new node of type “Page” it will send out a notification email to all users of a specified role. It takes advantage of some neat functionality within the module to achieve the end result. If you’re a little confused by any of those descriptions I’ve created a little tutorial based on a rule we have used often in the past. Variable - Variables store values for use within conditions and actions and can act as tokens to load in dynamic content where it is needed. Rule - Rules are the event types, this is where you’ll choose what you want to react on and bring all your other pieces of config together to trigger the desired action.Ĭondition - Conditions are used to evaluate an expression such as a data comparison, logical AND/OR, etc.Īction - Actions are where you’ll execute your desired functionality, actions can be placed within other actions or be part of conditions or rules. Here’s a list and a brief rundown of the various parts. Unlike Rules, this module uses different sets of reusable configuration that you can mix and match to create your rule. At any point in the process we can use “Variables” to dynamically add values to separate components of the rule. At its’ core you have “Rules” that are the events that will trigger “Actions” when a specific set of “Conditions” and contexts are met. To put it through its paces, I set out to try building a couple of rules in Drupal 8 that we used often in 7.Īlthough the workflow is a little different than you may be used to in Rules the concepts and language are pretty much the same. While still a fairly young module, it is already quite powerful and stable. After some googling and unsuccessful attempts with other modules I stumbled upon Business Rules. This left me looking for something else to step in as our Swiss Army knife that could help satisfy random functional requirements.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |