Let view arguments be passed as parameters to rule set

I tried using the patch from #2 but I don't see anything to configure my VBO to use the new functionality and now my view does not show the selected VBO action under operations.

If you can tell me how to use this, that would probably solve my problem. Also, I don't know what I can do to help, but if I can I will. I also need this functionality.

All the Best,
Steve

Even after removing the patched VBO module the VBO action buttons are not rendering.

I'm using Aegir and thus have have a multisite environment. I had installed the patched VBO module in the /sites/site/modules/ directory to override the VBO module in /sites/all/modules/ directory.

I've disabled and re-enabled the module cleared caches, but it still nothing.

I cloned my site to a development domain and the problem I described before was corrected. Something must have been saved that I couldn't otherwise clear. I couldn't totally uninstall VBO as I didn't want to lose configuration from other modules that use it too.

Like wickwood I patched 7.x-3.x-dev with the patch in #2, but I do not see any new configuration options on my VBO field for my rules components.

Is there a further trick to get this to appear?

Removed a use case since it is rather easy to accomplish already. Feeding arguments as parameters is still a new very useful feature though.

After searching and searching, this patch seemed to be the only thing that I've found to do what I needed to do which was to pass an integer parameter along with each user record selected in a View with VBO to a Rules Component.

What I apparently was doing wrong before was I was not defining the Views Contextual Filter before looking for a change in the VBO configuration. Once I did this a "Provide parameters" option was available where I could select my Views Contextual Filter for the appropriate 2nd argument for the VBO Rules Component.

In my case since I don't really need the Views Contextual Filter I configured the Views Contextual Filter to be Global:Null.

Hope this helps someone. This has been driving me nuts for months!!!

Steve

P.S. Thanks again Auth for creating the patch. I hope it gets added to VBO. It could solve a lot of headaches. I surprised more people don't need this. Now that I know how to do this I can see all kinds of uses for it.

I used this to create a view that allows you to assign users to an entityreference field in a node provided by a contextual filter. Works great - just what I needed.

You have some whitespace errors in your patch:

views_bulk_operations-add-view-data-as-parameters-to-rule-set-1967702-3.patch:119: trailing whitespace.
      if(count($parameterInfo) > 0 && count($parameterInfo) <= count($primitiveParameters) &&
views_bulk_operations-add-view-data-as-parameters-to-rule-set-1967702-3.patch:201: trailing whitespace.

views_bulk_operations-add-view-data-as-parameters-to-rule-set-1967702-3.patch:339: trailing whitespace.

I'm not very familiar with the inner workings of the VBO module, but I will try and review the code in the following days. Thank you for your contribution!

I'm not sure if this patch is what I need, or if I'm just configuring things wrong.

I am trying to create a VBO of users filtered by a taxonomy term reference on the user entity. The VBO should live on a page tab off the taxonomy term.

I'd like to have the rule component create a new entity (node) and populate it with all the users selected in the VBO plus add the taxonomy term argument that is filtering the view.

thank you so much, that helps!

When it will be added to official release ???

Not possible apply the #9 patch. Please re-rolled on the HEAD.

Trying to patch #9 against 3.x-7.x-dev and Hunks #6 and #7 fail:

[views_bulk_operations]$ patch -p1 < views_bulk_operations-add-view-data-as-parameters-to-rule-set-1967702-3.patch 
patching file plugins/operation_types/base.class.php
patching file plugins/operation_types/rules_component.class.php
patching file views/views_bulk_operations_handler_field_operations.inc
Hunk #1 succeeded at 137 (offset 7 lines).
Hunk #2 succeeded at 272 (offset 7 lines).
patching file views_bulk_operations.module
Hunk #1 succeeded at 211 (offset 1 line).
Hunk #2 succeeded at 226 (offset 1 line).
Hunk #3 succeeded at 244 (offset 1 line).
Hunk #4 succeeded at 670 (offset 24 lines).
Hunk #5 succeeded at 756 with fuzz 2 (offset 37 lines).
Hunk #6 FAILED at 1030.
Hunk #7 FAILED at 1110.
2 out of 7 hunks FAILED -- saving rejects to file views_bulk_operations.module.rej

And the rej file:

--- views_bulk_operations.module
+++ views_bulk_operations.module
@@ -1030,6 +1043,9 @@
       'progress' => $row['position'],
       'rows' => $row['views_row'],
     );
+    if($operation->getAdminOption('provide_parameters', FALSE)) {
+      $operation_context['parameters'] = $options['parameters'];
+    }
     $operation->execute($entity, $operation_context);

     unset($row_group[$row_id]);
@@ -1110,6 +1126,9 @@
       $operation_context['rows'][$row_index] = $row['views_row'];
     }
   }
+  if($operation->getAdminOption('provide_parameters', FALSE)) {
+    $operation_context['parameters'] = $options['parameters'];
+  }
   $operation->execute($entities, $operation_context);

   $context['results']['log'][] = t('Performed aggregate %operation on @items.',

A re-roll would be much appreciated. Thanks for this patch!

Lunk

Great! Exactly what I needed.

Here is a rerolled patch against latest HEAD.

Thanks marcusx patch #17 works against 7.x-3.x-dev

Patch in #17 applied with whitespace warnings

$ git apply -v views_bulk_operations-add-view-data-as-parameters-to-rule-set-1967702-17.patch
views_bulk_operations-add-view-data-as-parameters-to-rule-set-1967702-17.patch:119: trailing whitespace.
      if(count($parameterInfo) > 0 && count($parameterInfo) <= count($primitiveParameters) && 
views_bulk_operations-add-view-data-as-parameters-to-rule-set-1967702-17.patch:201: trailing whitespace.
    
Checking patch plugins/operation_types/base.class.php...
Checking patch plugins/operation_types/rules_component.class.php...
Applied patch plugins/operation_types/base.class.php cleanly.
Applied patch plugins/operation_types/rules_component.class.php cleanly.
warning: 2 lines add whitespace errors.

Applied this to the last commit on 12/23/2013 which has SHA ID:1796c1dbad033e41f5addfb8da0f159cf11c44e4

I had the same issue as wickwood, which then continued...

After applying the patch and attempting to add VBO Content to a view, I received several errors. Here are the messages from my log report:

Warning: Missing argument 5 for ViewsBulkOperationsRulesComponent::__construct(), called in C:\wamp\www\mysite\sites\all\modules\contrib\views_bulk_operations\views_bulk_operations.module on line 226 and defined in ViewsBulkOperationsRulesComponent->__construct() (line 41 of C:\wamp\www\mysite\sites\all\modules\contrib\views_bulk_operations\plugins\operation_types\rules_component.class.php).

Notice: Undefined variable: operationsField in ViewsBulkOperationsRulesComponent->__construct() (line 42 of C:\wamp\www\mysite\sites\all\modules\contrib\views_bulk_operations\plugins\operation_types\rules_component.class.php).

Notice: Trying to get property of non-object in ViewsBulkOperationsRulesComponent->__construct() (line 47 of C:\wamp\www\mysite\sites\all\modules\contrib\views_bulk_operations\plugins\operation_types\rules_component.class.php).

This was patched against the latest dev version of VBO, updated 2014-Feb-10

(Running Drupal 7.26, PHP 5.3.10)

I am having the same problem as #20

The problem is that patch in #17 does not contain all the changes from the patch in #9

+++ b/plugins/operation_types/base.class.php
@@ -49,8 +49,12 @@ abstract class ViewsBulkOperationsBaseOperation {
+  public function __construct($operationId, $entityType, array $operationInfo, array $adminOptions, $operationsField) {

This will only work if views_bulk_operations_get_operation
and other changes from the #9 patch are also applied.

$operations[$operation_id] = new $plugin['handler']['class']($operation_id, $entity_type, $operation_info, $options);
Doesn't pass the $operationsField so that is why you get the error " Trying to get property of non-object in "

I suspect the only reason that it was working for some people is that had already applied on of the previous patches. The patch needs to be re-rolled to include all changes from #9.

OK here is patch re-rolled with the changes from #9 included also.

Also ran the patch through Coder. This is always a good idea so that it is more likely to be adopted by the module maintainers and to save them time.

Also I like the idea but I think limiting the values you can pass to the Rule to only the parameters of View is limiting.

If you instead used the regular "Replacement Patterns" for the View Row then you would be able pass not only the Views contextual filter values but also the values for other fields on the Row.(unless I am missing something this can't be done by the current patch.

Thank You, tedbow. I just applied and tested your patch from #22, and it appears to be working great.

The "provide parameters" option showed up in my VBO form as it should, the rule and operation fired off perfectly, and there were no error messages to report.

Thanks for catching that problem and rolling the new patch. Much appreciated.

@tedbow this patch works great, thank you.

I tested the patch #22 this week, and it appeared to work sometimes. I figured out that the problem is with panels and using panel context in the view panes.

I'm using in a view Global Null to get the current node ID for the integer parameter in a rules component.
The obvious approach would be: In the view, in Pane settings, Argument input, I set Global: Null source to "from context" with "Content ID"
However, that is not recognized as a parameter in Rules.

On the other hand, when in the view I set the Argument input as "Input on pane config", and in the Panel pane config I insert %node:nid, then Rules does recognize it as a parameter.

I have noticed another issue: that the 'Provide parameters' in VBO settings changes its value when the contextual filters are rearranged in the view.

#22 is working for me but sometimes when i update the rules component the "provide parameters" form resets to "none"

This would be very useful! I would like to help but I am not a developer.. please review and include it!

This would eliminate the need of a lot of entity reference fields on the entities and a lot of conditions (loading fields etc.) in the rules, thus making them lighter and faster!

I just realized that I never reported back that patch 22 has been working for us. We haven't had any issues that we are aware of.

Which version of the module should I be using for a clean apply of the #22 patch? I tried the most recent 7.x-3.x-dev, but had a fail on a hunk. I tried to apply that hunk manually, but the rule isn't seeing the argument so it's still prompting me for the value that I'm trying to populate automatically, and I'm assuming something got lost in the mix. Here's the reject from the hunk fail:

--- plugins/operation_types/rules_component.class.php
+++ plugins/operation_types/rules_component.class.php
@@ -304,8 +486,13 @@
       $element = $this->rulesElement;
     }
     else {
-     $element = rules_action('component_' . $this->operationInfo['parameters']['component_key']);
+      $element = rules_action('component_' . $this->operationInfo['parameters']['component_key']);
+    }
+    if (array_key_exists('parameters', $context) && is_array($context['parameters'])) {
+      $element->executeByArgs(array_merge(is_array($data) ? $data : array($data), $context['parameters']));
+    }
+    else {
+      $element->execute($data);
     }
-    $element->execute($data);
   }
 }

Is there a version I can install from drush that already has the patch? Or one I can install and then apply the patch cleanly?

And a HUGE +1 for this feature. I'm surprised it isn't part VBO already.

Thanks!

Patch in #22 wasn't working for me, as I have a rule which has non-primitive input parameters, so I couldn't configure the vbo settings.
Also the data wasn't passed correctly to the executeByArgs() function.

I rerolled the patch to work wit the latest dev version, removed the primitive parameter requirement and cleaned up the code to follow Drupal Coding standards.

Great patch. Thanks for sharing. One question though: Although I've selected "Skip confirmation step" in settings, I still get a page with "Next" "Cancel" after clicking the button that triggers the rules component. It doesn't immediately process the selected items as what I would expect when selecting "Skip confirmation step". When I enable this option, I'm asked twice to confirm. Is this by design or am I missing a setting somewhere? I'm using VBO 7.x-3.3.

I experience the same issue as delphinx. In my mind I didn't have this issue with patch #22 and a previous dev version of VBO. I haven't tested that yet though. I'm using 7.x-3.3+2-dev (2015-Nov-28)

It would be very very very useful to be able to include any field in the current view in the format of regular replacement tokens! :)

Although it works, the issue is still present mentioned in #33 and #34, the 'Next / Cancel' page shows up even if 'skip confirmation step' is selected. This was not happening in the first patch versions.

It looks like @mollux's update in #32 was a little aggressive in cleanup and removed the 'configurable()' method for the ViewsBulkOperationsRulesComponent class. When I brought that in, it still didn't work for me, but only because for my particular component rule there were 0 primitive parameters. What should happen here is, this rule should be marked as "not configurable" when the following conditions are met:

1) there are no primitive parameters
2) there aren't enough advanced supplied parameters for the list of required providable parameters.

Item number 1 appeared to be missing from the conditions for this, so I updated the return false conditions to ensure that if parameters are provided, and none are primitive, this gets correctly expressed as non configurable. once this happened, everything worked as expected.

Attached is a re-roll of #32 with the addition of the modified configurable implementation from #22. I would like to get some better eyes on the code I modified since it is pretty complex, and i suspect can be normalized to be a lot clearer:

      if (count($parameterInfo) > 0
        && (
          (
            count($parameterInfo) <= count($primitiveParameters)
            &&
            count($primitiveParameters) <= count(array_filter($providedParameters))
          )
          ||
          (count($primitiveParameters) == 0)
        )

      ) {
        return FALSE;
      }
    }

I'm getting this now in both dev and stable version, the argument option is no longer there.

An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: http://konsult-test.dev/_www/admin/structure/views/ajax/config-item/matc...
StatusText: Service unavailable (with message)
ResponseText: ArgumentCountError: Too few arguments to function views_bulk_operations_get_operation(), 3 passed in /www/sites/konsult-test/.platform/local/builds/default/public/sites/all/modules/contrib/views_bulk_operations/views/views_bulk_operations_handler_field_operations.inc on line 203 and exactly 4 expected in views_bulk_operations_get_operation() (line 216 of /www/sites/konsult-test/.platform/local/builds/default/public/sites/all/modules/contrib/views_bulk_operations/views_bulk_operations.module).

On line 203 and 220 in views_bulk_operations_handler_field_operations.inc I added ", null" as an empty fourth parameter, that cleared the error and the parameter works again.

$operation = views_bulk_operations_get_operation($operation_id, $entity_type, $options, null);

That's not the solution of course but gets me through the day. I don't think the patch got applied cleanly. I'm running 4 patches on VBO, using a makefile, so it might be related to the order the patches get applied or something.

... to be continued.

It works for me with this old version I had on another site, but not with the latest stable or latest dev.

; Information added by Drupal.org packaging script on 2015-11-28
version = "7.x-3.3+2-dev"
core = "7.x"
project = "views_bulk_operations"
datestamp = "1448719743"

Can anyone else confirm the patch from #37 is not working with latest dev or stable please?

Indeed very nice addition to VBO.
Did not test the patch but subscribing to follow further development!

patch #37 gives me
Fatal error: Call to a member function get_handlers() on null in ../views_bulk_operations/plugins/operation_types/rules_component.class.php on line 45

the line mentioned is
foreach ($operation_field->view->display_handler->get_handlers('argument') as $arg => $handler) {

Retrying patch #22 gives me Fatal error:

Cannot use object of type ViewsBulkOperationsRulesComponent as array in ../modules/views_bulk_operations/views_bulk_operations.module on line 245

which line contains: return $operations[$operation_id][$entity_type][$cid];

function views_bulk_operations_get_operation($operation_id, $entity_type, $options, $operations_field) {
  $operations = &drupal_static(__FUNCTION__);
  // Create a unique hash of the options.
  $cid = md5(serialize($options));
  // See if there's a cached copy of the operation, including entity type and
  // options.

  if (!isset($operations[$operation_id][$entity_type][$cid])) {

    // Intentionally not using views_bulk_operations_get_operation_info() here
    // since it's an expensive function that loads all the operations on the
    // system, despite the fact that we might only need a few.

    $id_fragments = explode('::', $operation_id);
    $plugin = views_bulk_operations_get_operation_type($id_fragments[0]);
    $operation_info = $plugin['list callback']($operation_id);
    if ($operation_info) {
 $operations[$operation_id] = new $plugin['handler']['class']($operation_id, $entity_type, $operation_info, $options, $operations_field);
}
    else {
      $operations[$operation_id][$entity_type][$cid] = FALSE;
    }
  }
  return $operations[$operation_id][$entity_type][$cid];
}

I now used a vbo module from a site I made last year which included also patch #22. That works fine. So its something in VBO that has changed in the meantime which makes the patch incompatible.

Hi, I fixed the #37 patch against the latest dev release. It seems to work.
Please test.
Let view arguments be passed as parameters to rule set

#45 works for me.

This issue was referenced through direct URL instead of the proper bracket sequence in #1291312-10: multiple arguments from VBO to Rules, so I made them both Related Issues of each other, and am including proper references.

I’ll try out Patch #45 in a bit, but have my doubts since it was rolled against the then-dev in early October of 2017, and there’s been an actual stable release since then: 7.x-3.5 dated May 8, 2018, and the current -dev is dated May 17.

It did seem to apply cleanly in 7.x-3.5. Haven’t tested against the newest -dev yet. Will try out the functionality soon.

May I suggest a UX improvement for this for Rules proper? In Components and Rule Sets, for the Variables, there’s a “Usage” column with drop-downs for “Parameter,” “Parameter + Provided,” and “Provided.” These determine input, bidirectional, and output variables, respectively. There are also columns for “Data type,” “Label,” and “Machine name” before that one.

I propose adding a new column to the right of “Usage”: “Source.” Drop-down items could be added by other modules (such as Context or Global Filter) or plugins to VBO, but would initially include “User input” (default, what it does now without this patch), “URL param #1” (through #4 or so), and perhaps some others as well.

If the “Data type” is set to a primitive such as “Date” or “Text” or “Integer,” the parameter would be assumed to be such and treated accordingly. But if it’s an Entity type such as “Node” or “User” or one provided by a contrib module such as “Group,” then the URL parameter would be treated as an Integer and a Fetch Entity by ID of that type would automatically be done on it, with the fetched entity stored in the variable instead of the ID (or null if no Entity of that type by that ID exists). Lists could be done by using comma-separated integer IDs (“21,44,135”) notation.

I figure that for now the “Source” dropdown should be disabled (grayed out) on any variable in which “Usage” is set to “Provided.” Though, maybe this concept could be extended to those as well, to specify just how they would be Provided back to Drupal.

I think I need to suggest this as a Feature Request over at Rules, don’t I?

Does someone know if all this marvel is working in VBO Version: 7.x-3.5??

I have just stomped on a very similar use case and it seems that my need would be satisfied by the described improvement, but I just cannot see this PROVIDE PARAMETERS checkbox nowhere, even though going through the steps detailed at #8 and somewhere else.
I still need to input manually the second parameter that I was hoping to automate.

Any help?

Re-rolled patch from #45 for current 7.x-3.6.