Posted by AlexisWilke on June 13, 2009 at 8:29pm
25 followers
| Project: | Rules |
| Version: | 6.x-1.x-dev |
| Component: | Provided Rules integration |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Issue Summary
Hi guys,
There is a small patch to add two conditions on terms. Although one of them (i.e. comparing two terms together) may not really be achievable at this time, it is available right now!
The other condition is to test the existence of a term. Returns true if a term exists. It can be used to avoid creating the term multiple times, for instance. Or to allow/forbid something as I was thinking it could be useful to have a way to deny access to a node from the Rules module. 8-) But I'm not too sure there is a hook available for that purpose...
Thank you.
Alexis Wilke
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| rules-6.x-condition_term.patch | 4.31 KB | Idle | FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch rules-6.x-condition_term.patch. | View details | Re-test |
Comments
#1
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. :)
#2
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
#3
fago,
Should the user load the vocabulary in a previous rule? Or should it be hard coded? (and see the problem of variable naming I submitted...#501336: Help with rule sets configuration: variable already exists)
Josh,
That should be doable since the comma is accepted as a separator in the taxonomy tag entry we can assume no tag would include a comma (and if it does, fix it.)
Thank you.
Alexis
#4
>Should the user load the vocabulary in a previous rule?
Yes!
#5
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"
#6
Yes, that function offers that functionality:
rules_condition_term_exists()
I have not been using Rules for a while so I do not know whether this patch is still applying and works. But from what I've seen, there weren't that many changes so if you're using 1.x you should be good to go.
Thank you.
Alexis
#7
@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.
#8
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
#9
aleighs,
If you fix the patch as asked by fago in #1, maybe it will be checked in. At times I wonder why such demanding authors don't do that work themselves. 2 lines to edit... A big killer. 8-)
Thank you.
Alexis
#10
Subscribing.
#11
the current patch
#12
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
#13
How come you changed the $Id: $ ? And note that a proper $Id: $ include a colon and a space, although I think the CVS in Drupal is smart enough to understand the $Id$ it is not conventional.
Thank you.
Alexis
#14
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....
#15
#16
#17
The last submitted patch, V3_rules-6.x-condition_term.patch.patch, failed testing.
#18
sub.
#19
Cleaned patch committing again
#20
+++ 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.
#21
Cleaned up and re-attached.
Condition to compare vocabularies dropped from the patch
#22
The last submitted patch, rules_490898_2.patch, failed testing.
#23
Cleaned up and did fresh patch
#24
#25
@klausi , I have redone the patch, Cleaned up the parts that you had pointed in previous review.
#26
Perfect! Works fine for me!
#27
Thanks Ravi for the extra work. 8-)
#28
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.
#29
rickvug,
The very point of this patch is to match items by name. If you do not like it, you may want to work on your own version and provide another patch. It is very useful to know whether a term exists. It's not because you don't need it that it's not useful.
If I recall properly, the vocabulary selection is the same here as it is in other places and it was required to get the list of terms.
Thank you.
Alexis Wilke
#30
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.
#31
#19: rules_490898.patch queued for re-testing.
#32
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.
#33
mstrelan,
No way. With a taxonomy that has 200,000 terms, checkboxes won't work at all. Now having multiple auto-complete and a way to add more is a good thing but not having anything to check terms is much worse. So blocking the existing patch to add yet another feature is not smart.
Thank you.
Alexis
#34
#35
Really wishing for the "term set on node" here
#36
any progress with getting this committed?
#37
#23 patch does not seem to work for me, condition returns always FALSE whether a term exists in vocabulary or not.
#38
I am going to take another stab at this , hopefully will be able to get it to RTBC ..
#39
There is a patch with all my changes as of 1.4. This includes everything I've done, not just what is supposed to be part of this issue... but maybe one other person will enjoy the features offered.
The patch in #23 was very similar to mine so I don't right now see why it wouldn't work... More later if I find something's wrong.
Thank you.
Alexis
#40
Okay, there is a problem with the vocabulary ($vid) which uses the wrong name in the settings array.
There is a fix to patch found in #23 for that problem. However, it does not explain the problem reported in #37.
Thank you.
Alexis Wilke
#41
@aerodub,
Are you testing with the NAME of a term? (opposed to its identifier which is what you are supposed to use)
Thank you.
Alexis
#42
fixing the title
#43
+1 subscribing
#44
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
#45
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 contentIF node type = customer
AND execute php code returns true
load vocabulary
create new term
The php code to check if the term exists is
<?php$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;
}
?>
#46
cato,
Did you try applying patch in #40 to see whether you could do what you're trying to do?
Thank you.
Alexis
#47
@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
#48
Well... I guess you have a point since I opened this on June 13, 2009 and the author (fago) did not yet apply the patch to the Rules code... 8-)
So you have two solutions: you keep Rules the way it is or you use the patch here and you don't have to write the code. Now, writing your own solution in a separate module may be a good solution too.
Thank you.
Alexis Wilke
#49
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.
#50
Katrina B,
You may want to test with the patch in #40 and see whether it works for you. If so, then mark the status as RTBC.
Thank you.
Alexis Wilke
#51
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.
#52
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.patchpatching 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!
#53
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.