I'm currently working hard on the drupal 7 compatible 2.x version of Rules. So what's new?
- The whole API has been revised, so it's more modular, extensible and easier to use. So now all rule elements (conditions, actions, ORs, ANDs, LOOPs) are reusable components on its own, e.g. a module not interested in Rules could easily reuse just the conditions.
- New rule elements may be contributed by modules. Rules comes now with support for loops (and data lists) too.
- Builds upon the entity API for CRUD and default rule configurations (exportable entities).
- Builds upon the entity_metadata module, which is now a dependency. I decided to move all general usable metadata needed for rules to that module. So other modules can easily rely on it too, which hopefully helps to increase metadata availability.
- Action arguments can now be filled with fixed user input values or dynamically assigned values. Previously that depended on the data type and created quite some headache. Rules uses the metadata for new so called 'data selectors'. Thus you may use the value ef any entity property as argument, e.g. when an action works with an user just assign node:author. That can also go further, e.g. send mail to node:author:mail.
- Rules comes with generic useful conditions and actions which all work with data selectors, e.g. there is now a generic data comparison condition and actions for modifying data, fetching data, saving data, deleting data and creating new data. Haves this generic actions makes the the list of available actions much shorter and so clearer, but also saves bunch of code and action definitions.
- Now rules incorporates access callbacks, which one may use to specify usage permissions for events conditions and actions. Also the data selectors incorporate per entity property access permissions, so one may use the Rules ui without needing to have full site access then. E.g. if you don't have administer comments permission, you won't be able to deal with comments.
The API is already pretty fine right now and comes with docs (see rules.api.php) and a lot of tests, so modules can already start with doing d7 rules integration. As of now there is no UI, so creating and executing rules can be only done by code. E.g. this creates an reaction rule and saves it:
<?php
$rule = rules_reaction_rule();
$rule->label = 'example default rule';
$rule->event('node_update')
->condition(rules_condition('data_is', array('data:select' => 'node:status', 'value' => TRUE))->negate())
->condition('data_is', array('data:select' => 'node:type', 'op' => 'IN', 'value' => array('page', 'story')))
->action('drupal_message', array('message' => 'A node has been updated.'));
$rule->save('mymodule_myrule', 'mymodule');
?>So this rule checks whether updated node is not published and of type page or story. If it is, it just outputs 'A node has been updated.'. For just executing this rule for a given node you could just use:
<?php
$rule = rule(array('type' => 'node', 'label' => t('The node parameter'));
$rule->condition(rules_condition('data_is', array('data:select' => 'node:status', 'value' => TRUE))->negate())
->condition('data_is', array('data:select' => 'node:type', 'op' => 'IN', 'value' => array('page', 'story')))
->action('drupal_message', array('message' => 'A node has been updated.'));
$rule->execute($node);
?>For more examples have a look at the tests coming with the module.
About the UI:
* The UI will be overhauled to and get some drag&drop/JS enhancements. We'll start with the beginning of February and hope to have it finished, or at least something useful with the end of February.
* As the API, the UI will be reusable too. E.g. a module could provide a default condition set and incorporate it's UI in its own. So users could specify all rules conditions as usual there, while the module just can make use of the rules API for saving changes and executing the condition set.
How to write module integration
Event, action and condition integration works basically as before, I just renamed some keys and there are some new, e.g. to specify access callbacks. But what is much more important usually one won't need to code a lot of conditions or actions, e.g. the node module integration of rules comes with zero conditions and actions. This is thanks to the entity metadata.
So for any new property your module introduces, integrate with the entity metadata module, then rules can make use of it. If you have a new data type, if possible/suitable make it an entity and integrate with the entity metadata module to provide metadata about the available properties, but also specify CRUD and access callbacks. Then add a rules data type (see the existing ones in data.rules.inc) and you are done - so your entity is usable with the usual rules data set/fetch/create/save/delete actions.
If that's not possible/suitable, you could still create your custom rules data wrapper, conditions and actions.
What has also changed, is how rules includes files. Now only the files really needed during the evaluation of a rule are included. Still it's suggested to use rules.inc for your hook implementations, but your actual action and condition implementation can reside in any other files as rules includes it automatically for you. For that to work just specify your file in the hook_rules_file_info(). The suggested pattern is now to use an optoinal yourmodule.[rules_]eval.inc for stuff needed during execution and yourmodule.rules.inc for the rest (hook definitions and UI stuff).
Also as now rules comes with an API that makes it easy to execute single actions or rules, it's much easier to do tests for your module integration. So don't wait - write them! ;)