Create entity fails when the user is anonymous

rules_action_entity_create() gets given a user object for "author" if this is set, or FALSE if the author is anonymous. When it calls entity_property_values_create_entity() this fails in $wrapper->$key->set($value); when $key is author and $value is FALSE.

Here's a very simple Rule that just creates a new "article" whenever a new node (not article) is created.

{ "rules_simplerule" : {
    "LABEL" : "simplerule",
    "PLUGIN" : "reaction rule",
    "REQUIRES" : [ "rules" ],
    "ON" : [ "node_insert" ],
    "IF" : [
      { "NOT node_is_of_type" : { "node" : [ "node" ], "type" : { "value" : { "article" : "article" } } } }
    ],
    "DO" : [
      { "entity_create" : {
          "USING" : {
            "type" : "node",
            "param_type" : "article",
            "param_title" : "Article about: [node:title]",
            "param_author" : [ "node:author" ]
          },
          "PROVIDE" : { "entity_created" : { "entity_created" : "Created entity" } }
        }
      }
    ]
  }
}

This works when the node created is owned by a real user, and fails when it's owned by Anonymous.

Here's a patch that addresses this specific issue only. Not sure if this is the right place to fix it, or the fix should be more general, but it certainly fixes the symptom reported above.

#4 works for me on 7.x-2.9 !

thanks lyricnz!

may want to determine if this doesn't create a security hole before this issue moves any further

I think this patch needs to committed as soon as possible. I just discovered that, after updating my Rules module a few months ago, this patch was not included but I didn't know that. So for far too long, my visitors where not able to submit events to my community calendar. I've added the patch back to the code and now it's working fine.

Likewise had to re-patch!

I don't think this will create a security whole, but I think it's wrong point to this change. The default value should be handled in the entity, or in the entity's property info callback.

Well something needs to change - either this patch get applied to the next release or this condition get handled correctly, like a warning message is displayed, rather than the rule failing to do anything at all and a non-descript message put in the log messages.

I update to Rules 7x-2.11 a month ago and forgot to apply this patch and I had the same problem all over again.

I agree with @fago. This patch should not be committed.

The whole point of an Entity API is to ensure that entities may be operated on in a uniform and consistent manner, regardless of entity type. If you have to make exceptions in the code - testing for certain modules, or doing special things for specific entity types - then this is an indication you're doing something wrong. Adding special cases like this into a general function is a step down the path to unmaintainable, fragile spaghetti code. So while no one is denying there is a small problem in Drupal, putting a hack into Rules does not fix the problem, it just avoids it for this one module and it does nothing to help the larger Drupal community. It also doesn't fix anyplace else in Rules where this might cause a problem.

Additionally, the patch above introduces its own new problem. Because it is testing $values['author'] without seeing if that element is set first, it will generate a PHP warning for ALL entities which don't have an 'author' parameter. And adding an additional isset() is not the answer either - that's just making another exception which again should be a red flag that this is not the place to fix the problem.

The issue with the user being set to FALSE for anonymous users (and the related problem that drupal_anonymous_user() DOES NOT return a real User object, rather it is a stdClass() which is NOT populated with all the necessary User object fields or defaults) is something that has caused problems in may different modules as well as core, and solutions have been proposed for years. @fago for one has contributed to fixing that situation. You may search the core issue queue if you want all the gory details.

Regardless, this patch should not be committed because it's the wrong thing to do. For expedience, you could implement hook_node_create() in your own module and test/set the user there. Then you could post that implementation here to help other people avoid the problem without having to patch Rules and without having to contaminate your site's code base - doing this in hook_node_create() will prevent the solution from failing when you update Rules or core. In the long run, since this seems to affect you more than most, you could help out in the core issue queue to move the issue along and eventually get core fixed.