Add support for rules actions

rules_core_action_execute() is a d6 function, thus somehow you have some d6 .rules.inc lying around?

Im having the same error. I have D7 alpha6, rules 7x. Here is the exact error:

ReflectionException: Function rules_core_action_execute() does not exist in ReflectionFunction->__construct() (line 1182 of /var/www/sites/shop/public/sites/all/modules/rules/rules/includes/rules.core.inc).

And here is rules.core.inc starting at line 1181 (1 line before):

  protected function getFileName($function, $includes) {
    $reflector = new ReflectionFunction($function);
    // On windows the path contains backslashes instead of slashes, fix that.
    $file = str_replace('\\', '/', $reflector->getFileName());
    foreach ($includes as $include) {
      $pos = strpos($file, $include . '.inc');
      // Test whether the file ends with the given filename.inc.
      if ($pos !== FALSE && strlen($file) - $pos == strlen($include) + 4) {
        return $include;
      }
    }
  }

Im posting views info here because from readon some posts there seems to still be some issues between rules and vbo.

rules

; Information added by drupal.org packaging script on 2010-07-13
version = "7.x-2.x-dev"
core = "7.x"
project = "rules"
datestamp = "1279023284"

views

; Information added by drupal.org packaging script on 2010-07-15
version = "7.x-3.x-dev"
core = "7.x"
project = "views"
datestamp = "1279196333"

vbo

; Information added by drupal.org packaging script on 2010-07-11
version = "7.x-3.x-dev"
core = "7.x"
project = "views_bulk_operations"
datestamp = "1278836277"

So if this is a d6 error. it's in the code. maybe the function was removed and the code above is still looking for it for some reason. Im not sure.

Please update the rules integration or remove it for now. It breaks the site for people as rules_core_action_execute() doesn't exist any more. For d7 Rules doesn't support core actions directly any more, but usually they can be supported just by adding the appropriate rules action info that describes the action's parameters.

If you need help with the Rules integration just ping me. I've not written API upgrade docs yet, but a short overview can be found here: http://drupal.org/node/832046#comment-3117640.

@VBO+Rules in d7:
Generally I'd like to improve support such that actions can be configured on the fly. Thus if an action needs further configuration (except for the entity to operate on) an interim form should be displayed, which configures the action. This should work already, but I need to give a test first.

Yes i discovered earlier that it was VBO that was breaking it. disabled and it works. thanks @fago

more info here - http://drupal.org/node/841362

It looks like one issue is that as soon as VBO is enabled, rules_core_action_execute() is called in views_bulk_operations.rules.inc, which doesn't exist in rules-7.x. Additionally, if a view is changed to use the VBO style, rules_get_configured_items() is called in ruleset.action.inc, which similarly doesn't exist in rules-7.x.

Disabled Rules integration in the latest dev until I figure out the new Rules API.

I had the same error adding modules to a new install (everything the latest). There are four varying reports of this bug.
See Please add faces to the module dependency list, December 2010.

Subscribe

subscribe

Subscribing.

Any update on when Rules might be integrated into VBO in D7?

Subscribing.

Subscribe

I've worked on the part of the Rules 2.x integration that allowes VBO to use rule-actions (eg. rules, rule sets and action sets). Should I create a new issue for this or should I post the patch here?

Please post a patch here. I should be working on VBO D7 starting next week.

Here it is. :)

subscribe. Thanks for working on this.

I couldn't get #19 to do anything for me, but I'm naive about rules/VBO integration.

+++ b/ruleset.action.inc
@@ -3,28 +3,27 @@
+  foreach (rules_get_components(false, 'action') as $component_key => $component) {

false should be FALSE.

+++ b/ruleset.action.inc
@@ -3,28 +3,27 @@
+    if (count($parameterInfo) == 1) { // For now, we only accept rulesets with one parameter (taken to be the 'type')

Inline comment should be above the commented line.

+++ b/ruleset.action.inc
@@ -3,28 +3,27 @@
+      $actions["views_bulk_operations_ruleset_action_{$component_key}"] = array(
...
       eval(<<<EOS
...
+if (!function_exists('views_bulk_operations_ruleset_action_{$component_key}')) {
+  function views_bulk_operations_ruleset_action_{$component_key}(&\$object, \$context) {
+    rules_invoke_component(\$context['ruleset'], \$object);
   }
 }
 EOS

Instead of this evil ugly eval(), why do we define a dynamic function name in the first place...?

+++ b/ruleset.action.inc
@@ -3,28 +3,27 @@
-      );
+      );     ¶

Trailing white-space.

Powered by Dreditor.

Thanks for your corrections. All things you mention, except that ugly white-space (sorry!), are in the original VBO-code, just rewritten to use the updated Rules API. The decision to stop using eval isn't mine to make I guess, but I'd welcome an alternative. :)

registering rules-actions as core-actions won't allow us to leverage of all available rule actions. So what about integrating them separately?

As said, it's easily possible to show a form to input the remaining form parameters, e.g. something like that should work (example taken from the rules-component execution code):

    // $rules_config == component as retrieved from rules_get_components()
    $element = rules_action('component_' . $rules_config->name);
    $form['exec_help'] = array(
      '#prefix' => '<p>',
      '#markup' => t('This form allows you to manually trigger the execution of the @plugin "%label". If this component requires any parameters, input the suiting execution arguments below.', array('@plugin' => $rules_config->plugin(), '%label' => $rules_config->label())),
      '#suffix' => '</p>',
    );
    $element->form($form, $form_state);

    // TODO: hide form element of first "entity" parameter, ala
   $form['parameter']['node']['#access'] = FALSE;

    $form['submit'] = array(
      '#type' => 'submit',
      '#value' => t('Execute'),
      '#weight' => 20,
    );
    // Re-use the validation callback, which will also populate the action element with
    // the configuration settings of the form.
    $form['#validate'] = array('rules_ui_form_rules_config_validate');

Then on submit, the element will be in the form state and you can just execute the element. As the first parameter has no configured argument, you'll need to pass it on execution (as parameterInfo() would show you):

  $element = $form_state['rules_element'];
  $result = $element->execute($node);

That way, one could configure rule actions on the fly. E.g. use a send mail component/action and input the mail text to send on the fly.

+1 for integrating them separately. No need to touch core actions in this case.

Here's a patch that follows fago's suggestion.
It is against the reloaded branch since there are API changes there to make this possible (passing $form_state to action forms).

There's one hack in there that I hope to get help with:
If the component has only one param, there's no config form and $element->execute($entity) works as it should.
However, add another param, and the config form appears, so I get "node:source" in the settings as the first param (for nodes, as an example) and $element->execute($entity) doesn't work.
I solved this temporarily by just killing the first setting (you can see it in the patch after HACK:) but I'm hoping for a more elegant solution.

Also, this: http://damz.privatepaste.com/2aac386877 makes me wonder whether getting a list of actions every time is going to be a performance problem.
Rules seems to be doing a lot of work...

ad #27 indeed, I ran into a problem related to that recently too. Let's handle that in #1159026: fix providing variables with components.
ad #26: great, will review it afterwards.

The problem is that #access just takes over the values of the hidden form elements, what leads to $settings['node:select'] being ''. Instead of setting #access to FALSE just unset the parameter's form, then you'll be able to use execute() without the hack.

For access checks, you could call $component->access() at runtime.

Another alternative approach to integrating only fitting components you could integrate just-all actions (including components) by setting up a wrapping action-set on the fly, which establishes the execution context:

e.g.

$set = rules_action_set(array('node' => array('type' => 'node')));
$action = rules_action('drupal_message');
$set->action($action);
$action->form($form ,$form_state);

// and for execution just do
$set->execute($node);

That way, one could execute actions directly, like "send mail", "set data value" or "delete entity" - but one would have to go through the configuration form even for simple cases like using the node_publish action for nodes... But I guess in most cases having a component in between to pre-configure parts makes anyway sense.

Instead of setting #access to FALSE just unset the parameter's form

mmm, actually, removing form elements/sections is generally discouraged, because other modules (next to the original one) may depend on the form element or submitted form value. Same applies to conditionally exposed form elements/sections. Usage of #access, optionally along with a #default_value (where none exists), is preferred and much more reliable.

Drupal core suffered and still suffers from old code that didn't use #access. Prime example was comment_form() in D6, which was close to impossible to reliably integrate with. Took me a good chunk of time to clean that up for D7.

Generally, agreed - but this is no form alter. We are doing our own form here - we are just changing the defaults, so I think unsetting is fine in that case. Rules itself is fine with that as it expects that the defaults might have been changed, so I see no problem with it.

I agree with fago.
Here's a new patch.
Made the #access -> unset() change, made it respect $component->access() and made it only work if rules is enabled.

fago, RTBC is in your hands.

P.S. I'm fine with using components.

Retitling (to make this distinct from the other type of Rules support we are missing: executing VBO from Rules)

Also a question: we are currently displaying the config form only when the component has more than one parameter. Is there any additional case where the config form would be needed?

Patch looks good to me.

Just one thing, I suggested you wrong previously - sry:

+    $component = rules_config_load($operation['key']);
+    if (!$component->access()) {

This is about the access to configure the component itself, but we just need to the check access for executing the component via the action, which is the access of the action:

-> Just use rules_action('component_' . $name)->access();
This also makes more sense as you are executing the action later on.

>Also a question: we are currently displaying the config form only when the component has more than one parameter. Is there any additional case where the config form would be needed?
Nope, that should be fine.

Made the change, committed & pushed (to the reloaded branch).

Thanks everyone, this has been a real community effort.

It's awesome to see this resolved, but I'm wondering if there's any plan to cut a new development release with this soon? The last 7.x-3.x-dev listed is dated May 10th...

@zabelc
As soon as #769322: Create the "View as form" style gets committed to Views (the "reloaded" branch can't work without it), I will merge the reloaded branch to 7.x-3.x and release an alpha or beta (depending on how much hacking I get done this friday).
Until then, you'll need to use the reloaded branch (and views_form, which is the patch above packaged into a module).
I'm hoping all this won't take more than 10 days.

Other than the dependency, another reason for this line of thinking is the fact that "reloaded" breaks all existing custom VBO views and actions ;)