Splitting this off from #1031530: Add a User action "Send account e-mail", as it's really a distinct feature request from the user mail action that patch also contains.

Problem/Motivation

It would be useful to be able to test entities for properties.

Proposed resolution

Modelled on existing action "Fetch entity by property", add a condition "Entity exists by property".

Files: 
CommentFileSizeAuthor
#15 Screen Shot 2013-06-03 at 13.20.50.png53.13 KBlathan
#15 Screen Shot 2013-06-03 at 13.21.15.png76.51 KBlathan
#14 Screen Shot 2013-06-03 at 13.19.05.png61.67 KBlathan
#11 rules-entity-exists-1777204-11.patch2.42 KBlathan
FAILED: [[SimpleTest]]: [MySQL] 355 pass(es), 0 fail(s), and 2 exception(s). View
#8 rules-entity-exists-1777204-8.patch3.09 KBlathan
PASSED: [[SimpleTest]]: [MySQL] 329 pass(es). View
#5 rules-entity-exists-1777204-5.patch1.75 KBnedjo
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch rules-entity-exists-1777204-5.patch. Unable to apply patch. See the log in the details link for more information. View
#1 rules-entity-exists-1777204-1.patch1.81 KBnedjo
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch rules-entity-exists-1777204-1.patch. Unable to apply patch. See the log in the details link for more information. View

Comments

nedjo’s picture

FileSize
1.81 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch rules-entity-exists-1777204-1.patch. Unable to apply patch. See the log in the details link for more information. View

Attached patch is updated a bit from the version in #1031530: Add a User action "Send account e-mail" (removed an unneeded 'callbacks' array, updated the type of the 'value' parameter, moved code to entity files that presumably were added subsequent to the previous patch).

nedjo’s picture

Status: Active » Needs review
rszrama’s picture

Looking at the language I used in descriptions again, it seems like the wording might falsely lead the user to believe this condition will actually load the entities it finds. I wonder if we should change it from fetched to something else, but I'm not sure what I'd change it to. : P

nedjo’s picture

Good point. Maybe this?

[type] Specifies the type of the entity to be tested for.
[property] The property by which the entity is to be selected.
[value] The property value of the entity to be tested for.

nedjo’s picture

FileSize
1.75 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch rules-entity-exists-1777204-5.patch. Unable to apply patch. See the log in the details link for more information. View

Updated patch with some simpler and, I hope, clearer descriptions.

kilik821’s picture

How does the property field formatting work?

I have a field named MB_ID with machine name field_mb_id and I've tried all of the following and I still get a fatal error: "mb-id", "mb_id", "field-mb-id"

The fatal error is:
Fatal error: Unsupported operand types in /DRUPALROOT/sites/all/modules/entity/includes/entity.property.inc on line 113

It would be really nice if the property field had a drop down like when using the "fetch entity by property" action.

skyredwang’s picture

Status: Needs review » Needs work

The PROPERTY option is indeed confusing. First all, the "PLACEMENT PATTERNS" below actually can't work at all; we should remove "PLACEMENT PATTERNS". Second, user has to input a case sensitive property name; e.g. "mail"

lathan’s picture

FileSize
3.09 KB
PASSED: [[SimpleTest]]: [MySQL] 329 pass(es). View

Here is a reworked patch that looks up the properties and provides a drop down for the user to select from.

lathan’s picture

Status: Needs work » Needs review
lathan’s picture

Status: Needs review » Needs work

patch is broken..

lathan’s picture

Status: Needs work » Needs review
FileSize
2.42 KB
FAILED: [[SimpleTest]]: [MySQL] 355 pass(es), 0 fail(s), and 2 exception(s). View

Here is one that works, sorry should have tested it first.

Status: Needs review » Needs work

The last submitted patch, rules-entity-exists-1777204-11.patch, failed testing.

okday’s picture

hi,

I've tried the last patch and i can't set conditions. I only have the negate box and the save button.

thank you.

lathan’s picture

Can you please give some more feedback @okday.

Attached is what you should be seeing.

lathan’s picture

And here are some screen shots when creating the condition (you first need to select the entity). Maybe you missed that?

skyredwang’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, rules-entity-exists-1777204-11.patch, failed testing.

skyredwang’s picture

although the test failed, but the patch works for me

samhassell’s picture

applying the patch to the latest non-dev release requires clearing the cache before it displays correctly. Otherwise you just get the negate box, as described in #13.

Bobík’s picture

It will be very useful when it will be possible to check multiple fileds. For example I want to validate if there is another node with same values at two separated fields.

Paul B’s picture

Does this work with integer properties?

The reason I'm asking this is, I have an entity in mongodb (with the mongo_entity module) that has a property that is declared as integer in its hook_entity_property_info() implementation. I also have an integer field (stored in MySQL) attached to the user. Using the 'Entity exists by property' condition from the Commerce module, I'm trying to set up a rule that checks if a mongo entity exists that has a property matching the userfield. I can set up this rule (Rules recognizes that the property and the userfield are both integers) but the action doesn't trigger. If I edit the property in mongodb and make it a string, it triggers.

If I change the hook_entity_property_info() implementation and make it a string, Rules of course notices that the types don't match.

mjcarter’s picture

Sweet, works well, though I'm not getting an option to switch to direct input with token replacement, whereas there is one in the Commerce_checkout version does.

I got it to work how I needed by changing the code in the patch so that the type of the last 'value' field is 'text' rather than 'unknown'

nykooa’s picture

patch #8 doesn't work for me (rules 7.x-2.6).
patch #11 works so fine! Thank's :-) But I'm worried about the failed test... Is there a way to correct it?

jetwodru’s picture

Hi,
#8 or #11 ? Rules should have this feature included coz we always want to check if the entity already exists before creation.

Often, I'm worried with patches as all these will become broken after upgrading to the newer version of the module. Recently just patched the Drupal Core, Entity API and now Rules, I wish all these patches will be included in the newer version without breaking the existing sites. Very often, I'd also forgotten which modules I'd patched and only I realized when it's broken after upgrade :p Thanks

Bojhan’s picture

I am not sure how to resolve the failing tests, how do you specify a type when it is actually unknown?

The patch itself works fine :)

eileenmcnaughton’s picture

Just looking at the patch - it returns true or false depending on the existence of the fetchable entity - would be more useful if it provided the list that exists back too - as the list could then be used for the next condition

tobiasb’s picture

In patch #11 there no callback for the option list.

LeeUDO’s picture

Is there any way to extend this by allow the checking of multiple fields?

example

Is there a ball which is "blue" and "10ft wide"??

TanvirAhmad’s picture

Issue summary: View changes

Though #11 failed the test, but it is working for me.

Cheers

mjcarter’s picture

Any feedback on whether the value being currently 'unknown' should be 'text' as in how this is set up in commerce_checkout?

value' => array(
          'type' => 'unknown',
          'label' => t('Value'),
          'description' => t('The property value of the entity to be fetched.'),

In commerce_checkout is:

value' => array(
          'type' => 'text',
          'label' => t('Value'),
          'description' => t('The property value of the entity to be fetched.'),

This then allows direct input with token replacement.

nykooa’s picture

#11 works fine for me... until I update entity to 7.x-1.4

kitikonti’s picture

Is it possible that this condition has a conflict with an access module? I have a custom access module and if i enable it, it seems the condition dont work. If i disable it the rule works like expected. My custom access module creates records for the same content type i use in the condition. Is it possible that the condition dont have access?

nykooa’s picture

Sorry, my mistake. #11 works with the Entity update. But, it's the update of entityform to 7.x-2.0-beta3 version that is the source of my problem.
No conflict with any acces module. It's a simple rule that create a new user (if user exist) with values from an entityform submittion.

kitikonti’s picture

So for everyone who comes to the same problem. There is a problem with access modules if the user who triggers the rule has no access to the entity i use in the condition. The same problem is with the "Fetch entity by property" which was the model for this module. The problem is because this action and condition use a function which checks the access. This must not be a Problem for everyone.

So but in my case it was a problem, so i created a module with my own condition which uses EntityFieldQuery(), because there i could set a user to run the query. My condition searches for a email address in a profile content type. Here is a code example:

/**
 * Implementation of hook_rules_condition_info().
 */
function yourmodule_rules_condition_info() {
  return array(
    'yourmodule_condition_profile_exists_by_email' => array(
      'label' => t('Profile exists by email'),
      'parameter' => array(
        'profile_email' => array(
          'label' => t('Email address to search for existing profile'),
          'type' => 'text',
        ),
      ),
      'group' => t('Node'),
    ),
  );
}

/**
 * Condition implementation.
 */
function yourmodule_condition_profile_exists_by_email($profile_email) {
  $query = new EntityFieldQuery();
  $query->entityCondition('entity_type', 'node')
    ->entityCondition('bundle', 'profile')
    ->fieldCondition('field_profile_e_mail', 'email', $profile_email, '=')
    ->addMetaData('account', user_load(1))
    ->range(0,1);
  $results = $query->execute();

  return !empty($results);
}
ShaunDychko’s picture

Another solution is to use the condition which checks the number of results from a VBO view. You can pass Rules tokens as arguments to the View.

Bojhan’s picture

I am wondering if this is something the Rules maintainers could take a look at. I have been patching rules, every update.

The approach in #11 seems to still work, although its failing tests.

The last submitted patch, 11: rules-entity-exists-1777204-11.patch, failed testing.

khiminrm’s picture

#11 works for me

ayalon’s picture

Status: Needs work » Reviewed & tested by the community

I also patch rules for every update and the patch is working for me..

ynosh’s picture

Hi!

There are any solution for 7.x-2.8 versión?

Thanks

sonicthoughts’s picture

Hi - also need way in 2.8 to see if a different entity exists. Trying to do what seems simple: create a new entity if one does not exists (by property value)

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 11: rules-entity-exists-1777204-11.patch, failed testing.

lamp5’s picture

+        'value' => array(
+          'type' => 'text',
+          'label' => t('Value'),
+          'description' => t('The property value of the entity to be fetched.'),
+        ),

Better solution to change type to 'text' instead 'unknow'