Condition: does term exist?

Yep, some conditions would definitely make sense. Some points:

1. There is no need for this code comment:
+ // I suppose this cannot be achieved yet...
+ // It could be used to compare the parent of two distinct terms...

2. Code style:
Please keep array definitons in 1 line as long as the aren't longer than 80chars,
e.g. I think
+ 'term1' => array(
+ 'type' => 'taxonomy_term',
+ 'label' => t('Term 1')
+ ),
could be one line.

@rules_condition_term_exists
I think this should also take the vocabulary as argument. The problem with that is only, that as of now arguments may not be optional (again rules 2..). However I think usually the user wants to check in an existing vocabulary nevertheless, as there is no possibility to use a term from one vocabulary in others, thus I think it's ok to enforce a vocabulary argument.
This should also help to simplify the condition's code itself. :)

Subscribing, I would like to be able to define a condition that checks to see if the content has been tagged with a term that is in a specific set of terms. For instance, to say "this condition is met if the content has been tagged with the terms blue, yellow, or green in the 'colors' vocabulary."

-Josh

>Should the user load the vocabulary in a previous rule?

Yes!

Is there a way for me to alter this patch to let me have a condition on if a node has a certain term?

Using the above example, I'd like to fire off an action if a new node has the term "yellow"

@endorn have you come out a solution for that?? I am also trying to use the rule for if a node has a term "whatever" and do some sending email actions.

Thanks.

While the UI is a bit confusing with the drop-down or VID and then typing the term name, the patch is actually functioning well for me. Thanks.

Also, this issue is a duplicate of http://drupal.org/node/343403

Subscribing.

the current patch

I'm excited to test this functionality.

Does this patch apply to the 6.13 rules.module found at rules\rules\rules.module? The hunks fail through cygwin when I attempt to apply...
Edit:
nevermind found the file path declared in the patch

Hi,

i add a patch V3 with the following extension:
- an additional condition, which checks the existence of a term on a given node object (e.g. after node events like "update node" useful)
- some improved commentation of the functions (old comments have been still from "user"-rules-conditions)
- elimination of the next potential killer issue "$Id$" ;)

Both patches have been created on version "6.x-1.2" of rules module.

Sry foor the late posting, I was not able to finish the work yesterday....

sub.

Cleaned patch committing again

+++ rules/modules/taxonomy.rules.inc	7 Oct 2010 16:30:01 -0000
@@ -277,5 +277,101 @@ class rules_data_type_taxonomy_vocab ext
 /**
+* Implementation of hook_rules_condition_info().
+*/
...
+/**
+* A simple user comparison
+*/

Ugly formatting, see http://drupal.org/node/1354

+++ rules/modules/taxonomy.rules.inc	7 Oct 2010 16:30:01 -0000
@@ -277,5 +277,101 @@ class rules_data_type_taxonomy_vocab ext
+  // TODO: add support for named vocabularies

we use "@todo" to mark future work

+++ rules/modules/taxonomy.rules.inc	7 Oct 2010 16:30:01 -0000
@@ -277,5 +277,101 @@ class rules_data_type_taxonomy_vocab ext
+    // term of any vocabulary is a match

Comments start with a capital letter and end with a dot.

Powered by Dreditor.

Cleaned up and re-attached.
Condition to compare vocabularies dropped from the patch

Cleaned up and did fresh patch

@klausi , I have redone the patch, Cleaned up the parts that you had pointed in previous review.

Perfect! Works fine for me!

I think there are a number of areas needing work here. The first is that the user interface is strange, specifically when selecting a vocabulary. Why is the option to select a vocabulary by vid present? The select box should be sufficient.

Related, I'm wondering if matching on term name is a good idea. What about if the term is retitled? Selecting a term id would be more inline with how taxonomy works. Perhaps autocomplete would work best here? This would require more complexity (multistep) in the form since autocomplete would depend on the vocabulary being set.

Another major issue in the last patch is that the condition only checks if the term itself exists, which isn't very useful. Instead, the condition should accept node as the argument so one can check if that term is attached to the given node (or any other node that is loaded).

Finally, I see the following error when the condition is configured (E_STRICT report with D6 dev):

notice: Undefined index: vocabulary in /Users/rick/Sites/d6-dev.dev/sites/all/modules/contrib/rules/rules/modules/taxonomy.rules.inc on line 77.
notice: Undefined index: vocabulary in /Users/rick/Sites/d6-dev.dev/sites/all/modules/contrib/rules/rules/modules/taxonomy.rules.inc on line 84.

Alexis - Sorry if the patch review came across harshly. Perhaps two taxonomy conditions should be developed: one to check if a term with a specific title exists, another to check if a specific term is attached to a node. As for the configuration forms, I'll take a look at other taxonomy rules forms. If it is consistent that may also be another issue. 

#19: rules_490898.patch queued for re-testing.

Before reading #28 I tested the patch and was going to write the exact same things. Also I don't think "term exists" is the best label. And finally I think there needs to be a way to allow multiple terms, which rickvug suggests should be term ids. Checkboxes would work well.

Really wishing for the "term set on node" here

any progress with getting this committed?

#23 patch does not seem to work for me, condition returns always FALSE whether a term exists in vocabulary or not.

I am going to take another stab at this , hopefully will be able to get it to RTBC ..

+1 subscribing

Looking for just this functionality or I'm stuck writing custom php code conditions. Status update? Anything I can do to help out?

//Christopher Cato

For anyone wanting this functionality, here is a little how to..
My usecase is that on creation of a node of the type Customer I want rules to create a taxonomy term in a specific vocabulary (customers) from the node title of the created content (node title = customer name). If it exists, rules should do nothing. For this we need a conditional.

Basically it looks like this:

ON event After saving new content
IF node type = customer
AND execute php code returns true
load vocabulary
create new term

The php code to check if the term exists is

$zvid = 3 // the vocabulary we are checking
$ids = taxonomy_get_term_by_name([node:title-raw]);
$ztid = NULL;
foreach ($ids as $data){
       if($data->vid == $zvid){
          $ztid = $data->tid;
       }
}
if(!$ztid){
    watchdog("rules-check-term-exists","term [node:title-raw] does not exist");
    return true;
} else {
    watchdog("rules-check-term-exists","term [node:title-raw] exists");    
    return false;
}

@AlexisWilke

No, I didn't try the patch - I generally avoid patching modules or core as it can make maintenance hard if , for instance, future releases provide functions that is not compatible with the patch.

Will this functionality be in the next release? It wasn't my intention to hijack this issue with my custom code by the way, sorry!

Thanks // Christopher

I am subscribing to this thread, as I need the ability to test for the existence of a term as a condition: If a node has a particular term attached to it, then do this (whatever "this" might be).

Where I work, I don't have the ability to patch modules (more accurately, I'm not allowed to), so I'm hoping this feature will be included in Rules soon.

Unfortunately, as I noted earlier, I cannot patch modules at my job; I don't have access to Terminal (which is what I would need to use on the Macintosh in order to apply a patch), so I don't have the ability to test the patch. I'll have to wait until the feature has been implemented in Rules.

Holy cow, what is wrong with issues like this? Started on June 13, 2009 - more than two years ago; several patches have been provided, and finally a patch has passed Simpletest, and nobody made founded objections, not even about the position of dots in comments. Still this code is not even in rules-6.x-1.x-dev. I don't get it.

The patch from #40 applies cleanly against rules-6.x-1.4:

# patch -p0 < rules-6.x-term_exists.patch 
patching file rules/modules/taxonomy.rules_forms.inc
patching file rules/modules/taxonomy.rules.inc

Also, it works exactly as advertised. I would even use it if it had no closing dot in the comments.

My use case: When creating a new node of a certain type, some data is pulled from an external source and made available as tokens. With Rules, I'm populating several vocabularies with these tokens. The vanilla rules-6.x-1.4 is totally useless in this scenario as it only allows to unconditionally enter a new term; the result are numerous duplicates. #40 solves this problem as it allows to compare a token with the exisiting terms. Works perfectly for me!

Please committ!

Holy cow, what is wrong with issues like this? Started on June 13, 2009 - more than two years ago; several patches have been provided, and finally a patch has passed Simpletest, and nobody made founded objections, not even about the position of dots in comments.

Looks like not enough people were interested into that... Here a review:

+++ rules/modules/taxonomy.rules_forms.inc	13 Oct 2010 12:44:28 -0000
@@ -187,6 +187,41 @@
+ * Condition Taxonomy: form to enter a term to check

Condition Taxonomy? That does not tell me anything. Should end with a trailing point.

+++ rules/modules/taxonomy.rules_forms.inc	13 Oct 2010 12:44:28 -0000
@@ -187,6 +187,41 @@
+    '#description' => t('Optional: Enter the vocabulary id (<em>not the vocabulary name</em>) that should be loaded. If this field is used, the "Select a vocabulary" field will be ignored.'),

Why should the vocabulary be loaded? Anyway, I don't think we need that by-id stuff. Let's just go with a select for vocabularies.

+++ rules/modules/taxonomy.rules_forms.inc	13 Oct 2010 12:44:28 -0000
@@ -187,6 +187,41 @@
+    '#description' => t('Enter the name of the term to search for. Remember that the case is ignored.'),

Needs to improved. I cannot remember something I don't know yet.

Anyone have time to help get this committed?

Is there a way to do this in Drupal 7?

Thanks :)

Drupal 6 end-of-life was more than two years ago - there will be no new feature in D6 Rules, and D6 Rules is no longer supported.

That said, this could go into Rules for D7 or D8 if someone is willing to contribute code or fund the development of this feature.