Provide a rules action that allows loading all entities from a view into Rules.

@renat: It is in dev!

@bojanz: The use case I have is almost always "update a number of nodes" or "send e-mail to a number of users". (Mostly the former.) Pretty often it includes arguments sent off to the view (or "contextual filter values", in the modern language). I have never used the exposed filter options.

@bojanz: Note that this functionality is not VBO specific – you can load nodes from any View. It may still make sense to have this functionality in VBO, since it integrates Views and Rules, but I'm not 100% sure.

(Updating the title to reflect this point.)

Oh!
My idea was to just take the objects corresponding to the base table of the view, but allowing flexibility is of course a good thing.

Sweet! Looking forward to trying this one out, and creating simple examples with awesome results. (Here's one example: Flag this node to get e-mail notifications on new comments.)

Sorry to re-open this issue. I just tried the new feature, and have a comment.

When loading a list of entities in Rules, I couldn't find any way to tell Rules what kind of entities are loaded. The result is that Rules becomes unable to do more or less anything at all with the entities – such as sending e-mails to users or publishing nodes.

I tried to add conditions "entity is of type", but no luck. To investigate further, I tried adding two different VBO fields to a view – acting on nodes or users. Rules didn't pick up this difference, which makes me believe that Rules doesn't really have a chance of knowing which type of entity should be treated as the base object in the loaded list.

I suggest changing this feature to an approach where each VBO field is listed as an action in Rules ("Load a list of users using field XYZ" or "Load a list of content using field ABC"), or possibly another option in the action configuration where you get to choose which VBO field should be used for loading the list.

Makes sense?

Edit: I'm opening an issue for a sub-module to VBO, dedicated to Rules/Views integration – #1243900: Separate most Rules/Views integration to a sub module.

I think we need one action per VBO field.

Example: You have a node view, with a relation using a node reference field. You add a VBO field utilizing this relation. When invoking this from Rules, you want to fetch the related nodes, not the base objects. If only fetching a selected entity type, Rules won't be able to know this.

Oh, now I get it. Thanks. (If you have two different node VBO fields on one view you would still have the problem though, but that's a rather hypothetical case even for a VBO maniac like myself.)

The choice of action name is pretty tricky. I think me and most others think "I wanna load users", which speaks in favour of "Load $entity_type entities from a VBO view". On the other hand, you have probably just built the VBO you want to use to load users, so "Use $view_name to load entities" might be a better candidate.

In either case, I think it is just a minor difference in usability. If one is significantly easier to code, I say that's the choice.

What's your opinion?

I am shocked to hear that fago had a smarter solution.

I tried the patch, but got AJAX errors when trying to use the action "Load a list of entities from a VBO View.", saying that the $view on line 186 in views_bulk_operations.rules.inc isn't an object.

Some more digging around tells me that the function _views_bulk_operations_rules_get_field() gets called without the proper arguments sometime during the configuration form building, but I can't really tell when.

When bypassing this (by hard-coding a view name into the rules.inc file), it seems to be working nicely. (There were some error messages on the config screen, but that is most likely due to the missing function arguments.)

What do you say about having a BoF in London and talk more about VBO + Rules? It would be interesting to hear fago's ideas as well.

Thanks for good work.

Works like a charm!

@GlitchFreak: You'll have to loop through the results from the View, and then call a rule set (or something) inside the loop – doing conditions and subsequent actions from the rule set.

Kind of quirky, I know, but that's the only way to do condition checks inside loops right now.