Action: "Modify an entity"

Yep, I think that would be a very useful action in many situations. I'd work on it if I'd find the time :/ Still I'm happy to provide directions if anyone wants to take care of it.

Something similar to Components/Rule or Rule Set? They accept as many variables as required.

Recently I added one to my Rules requiring 256 MB memory. Now 512 sometimes crashes. It seems memory hunger increases exponentially or even faster.

VBO has an action like this, so maybe it can be used for inspiration.
(uses entity metadata for properties, just like rules)

You should definitely be seeing "Modify entity values" in the VBO field settings (Views UI) for any entity type, including Content.
Retry as admin (if you weren't before), maybe it's a permission issue? And make sure you have the latest -dev (but then you say you found the modify.action.inc file, so it sounds like it is the latest...)

You need to have the very latest VBO -dev.

2. the first configuration form for the action would have the same entity selector field, then potentially some ajax to load all the properties and fields as checkboxes to select the ones you want to set. Once everything is chosen and you click continue, the next configuration form would have all those fields loaded for you to set.

I think that's the way it should work. Thus, we need a "properties" parameter which is just used to determine which properties we are setting. The general workflow for implementing such an action is to

1. implement action_info_alter() to alter in new parameters depending on already settings, i.e. alter in parameters for properties that should be changed.

2. implement action_form_alter() to implement the form-workflow using #ajax and multiple steps. Forms for added-in properties will be automatically generated once the form is reloaded and your alter-info adds in the properties.

An similar example working the same way is the existing 'entity_create' action.

You can define a list-parameter using an options list. I think it's going to be a multiple-select by default though. Still you can alter it using the form_alter callback.

Maybe in a few days. Or rather nights..

Thanks! Here is a review:

1. Not sure if the entity is validated for me or not to make sure we are infact dealing with a proper entity before updating. I think it is, but am relying on ->applyDataSelector to determine this.

It's fine to rely upon really getting an entity.

2. Not sure if I should check access for particular fields before allowing them to be changed? I am most certainly not doing this at the moment.

We should implement an _access callback to incorporate those checks, just as the data_set action does.

+++ b/modules/entity.eval.inc
@@ -138,6 +138,58 @@ function rules_action_entity_delete($wrapper, $settings, $state, $element) {
+    foreach ($element->pluginParameterInfo() as $name => $info) {
+      if (($name != 'data') && ($name != 'props')) {
+        try {

Let's better just read our "properties" variable.

+++ b/modules/entity.eval.inc
@@ -138,6 +138,58 @@ function rules_action_entity_delete($wrapper, $settings, $state, $element) {
+      $element_info['parameter']['props'] = array (
+        'type' => 'list<text>',
+        'label' => t('@label\'s parameter(s) to update', array('@label' => ($label) ? $label : 'Entity')),
+        //'label' => t('test'),
+        'description' => t('Check the properties that you would like to update for this entity.'),
+        'options list' => 'rules_action_entity_update_properties_list_options_list',
+      );

Let's come up with a better parameter name. What about just "properties" ? Also, let's fix the label to talk about modifying properties not parameters.

Then, we should use the type 'list' and just define the parameter as usually in hook_rules_action_info() with a constant label like just "Properties".

+++ b/modules/entity.eval.inc
@@ -138,6 +138,58 @@ function rules_action_entity_delete($wrapper, $settings, $state, $element) {
+        if (isset($element->settings['props'][$name])) {
+          $childinfo += array('type' => 'text');

I think we should add a validation callback that checks that each selected property exists and is writable (has a 'setter callback' set).
That way Rules is going to show errors if a modified property goes away afterwards.

+++ b/modules/entity.rules.inc
@@ -162,6 +162,27 @@ function rules_entity_action_info() {
+  ¶
+  $return['entity_update'] = array(
+    'label' => t('Update entity'),

Let's call the action "entity_modify" and "Modify an entity". I think that should better communicate you can use the action for newly created entities too.

Also, there is some whitespace in the empty line.

+++ b/modules/entity.rules.inc
@@ -162,6 +162,27 @@ function rules_entity_action_info() {
+    'parameter' => array(
+      'data' => array(
+        'type' => 'entity',

'data' should be called 'entity' as that's the usual variable name for entities.

+++ b/modules/entity.rules.inc
@@ -162,6 +162,27 @@ function rules_entity_action_info() {
+        'description' => t('Specifies the entity, for which you would like to update field/parameter values.'),

Let's say "The entity which should be modified."

+++ b/modules/entity.rules.inc
@@ -269,6 +290,93 @@ function rules_entity_type_options($key = NULL) {
+    // The possible values of the "parameter" are those of the particular entity "property".
+    if (isset($wrapper->$property_name)) return $wrapper->$property_name->optionsList();

Take care of the coding style.

+++ b/modules/entity.rules.inc
@@ -269,6 +290,93 @@ function rules_entity_type_options($key = NULL) {
+  return $options;  ¶

Trailing whitespaces.

I use VBO operation "Modify entity values (views_bulk_operations_modify_action)".
Well, it's possible to mass add references from some entities (nodes) to one entity.
But impossible to do mass unlink operation.
I hope this patch helps to solve such tasks?
Is it any progress?

Plus, there's even an open VBO issue for what Nick is describing: #1421656: Extend the "modify entity values" action to add a delete mode for multiple-value properties and fields. So, anyone interested in that can go there and make it happen.

Sorry that I miss by my question and thanks for answers - I take a look on that solutions.

I tested #28 and can't get past Fatal error: Call to undefined function rules_action_type_form_submit_rebuild() in .../includes/form.inc on line 1443 , either. So, changing this back to 'needs work'.
--

Marked #1721298: Action "Attach Fields" as a duplicate. The intended use case of #1472752: Add an "entity is of bundle" condition might also be covered here. Note from #1240364: Create a new entity: Ease populating custom fields, an important use case to cover in the docs will be loading entities from reference fields and modifying them. Also, raising priority based on the number of duplicate issues.

> form_alter & rebuild
See, #1681510: Add plugin factory to UI!

I applied the patch in #28 and also had the problem with "Fatal error: Call to undefined function rules_action_type_form_submit_rebuild() in .../includes/form.inc on line 1443", even after rebuilding the registry. However I was able to get around the issue by changing:
+ '#submit' => array('rules_action_type_form_submit_rebuild'),
to
+ '#submit' => array('rules_form_submit_rebuild'),

rules_action_type_form_submit_rebuild is in data.eval.inc, not entity.*.inc so it would make sense (to me) that it's not in scope. It just calls rules_form_submit_rebuild then sets $form_state['parameter_mode'] = array(); I don't know if that's needed for this form?

After fixing that I created a Rules component using WSClient module to retrieve a data structure, create a new entity (a node), and modify the entity.

When I tried to assign a property of the data structure that was (in this case) empty to a property of the entity, the whole Entity Modify action failed with a Rules Exception 'The variable or parameter %name is empty.' When I used a Set data action with the empty data property, I get no error.

I tried with my own custom data structure (in a custom module) and also had the same problem when trying to assign NULL values. I'm not sure if this is a problem with how I/WSClient are initializing our data structures or if this patch should prevent an exception in this case.

I'd love help continue with this patch but need a bit of guidance.

Here's the patch from #28 with the minor change I mention in #34.

I added an "allow null" to the property info alter callback for the action and that did the trick. I've been using this all day on a project for mapping and importing stuff and so far so good.

Right now, my only complaint is the UI is unwieldy especially with entities with a lot of fields. My current thought would be to get rid of the multi-select in favor of an "Add Another" and "Remove" field buttons.

I have applied the patch and it's working well. The UI improvements are great.

However, some fields have "sub-fields". For instance Addressfield which is required by Drupal Commerce. You can't assign the individual address components using "Modify Entity" the way you can with "Set a Data Value".

@acrazyanimal I understand what you are saying about assigning lists to lists but this seems a little different to me. I'm specifically talking about Fields that describe their underlying property info through the API.

When I use "set a data value", and use the data selector input with an AddressField it reveals:
billing-profile:address:country
or
billing-profile:address:thoroughfare
or
billing-profile:address:[whatever]
as assign-able options.

Unlike a list type which is a numerically indexed collection, AddressField has named components and somehow has provided the data selector in Rules with enough information to show the components.

If I chose "Modify an Entity", chose "billing-profile", why couldn't
address:country
address:thoroughfare
address:whatever
be available as checkboxes in your new UI? I don't even know if you can create an entity-less field data structure with Rules so just having "address" might not be helpful.

Not to be too obsessed with Addressfield or complex fields in general--it could be a future enhancement. I'm willing to mark as tested and reviewed if you think handling complex Fields is outside the scope of this patch.

In #37 the throw of RulesEvaluationException in rules_action_entity_modify references $settings['entity:select'] which is not defined in that context.

@acrazyanimal sorry for being vague.

On line 153 of the patched version of entity.eval.inc the variable $settings is referenced but is never defined in the function:

throw new RulesEvaluationException('Unable to modify the "@label" property for "@selector": ' . $e->getMessage(), array('@label' => $label, '@selector' => $settings['entity:select']));

This results in unhelpful exception messages like 'Unable to modify the "whatever" property for "": '.

Regarding multi-columned fields, I don't think the UI would change much at all. Just instead of having one checkbox for an "field_my_addressfield" instance you'd have a checkbox for field_my_addressfield:country, field_my_addressfield:city, field_my_addressfield:state, etc... But, anyway, better to get this RTBC first.

#45: rules-modify-entity-action-1421368-44.patch queued for re-testing.

Forgot to remove some pasted in text.

this seems, well, brilliant.
can I export the "modify entity" action as part of a feature?

Patch in #45 still applies.
This issue still needs reviews!

Applied #45 patch and tested the action. The only issue I encountered is with "body" field, which expects type "Field_item_textsummary". I do not know how to provide it "from scratch" (as opposed to copying it from existing entity). A workaround is to use "Set a data value" action just for this field, because that action accepts text as an input (does not force use of "Field_item_textsummary").

# very nice ... i love this idea

please when will it be RTBC ?

Thanks

@delacosta456: First, we've only had one review, #49, and that pointed out a problem. Someone needs to look at that problem and address it. You could also provide a review yourself - what did you test, did it work, were there any problems, etc. Second, I just triggered a re-test on the patch from #45 and you can see it no longer applies. It needs to be re-rolled to apply to the current development version of Rules. Third, the css needs to be fixed to include RTL styles. We finally got all the other css fixed in Rules after many years (see #2759199: RTL Rules Components tab), so I'm not about to go and break it again. Fourth, there are no test cases!

Regardless, these are all fairly easy things to do, but if no one in the community is willing to put in even a small amount of work to get these done then that indicates to me this isn't a priority. Introducing new features can be tricky when you have 300,000 users - there is a possibility of breaking sites - so I need to see that some care and attention has been put into this.

hi @TR ok many thanks on my own side i will try it and see what happen's

hi
i just try for some days patch #55

the patch applied correctly on latest D7. on top of with distro Panoply 7.x-1.71 is built .(php 7.1.30 +mysql 5.7)

The strange behavior i am getting while testing is that for an Event of "After saving node" action "Modify an entity" doesn't list the title field .

Thanks

If the a value for the "published status" param is provided, the action will always set it to "Published", regardless of the value specified. I used the Data selector to specify the value.