Posted by toddwoof on December 18, 2008 at 5:35pm
19 followers
| Project: | Rules |
| Version: | 7.x-2.x-dev |
| Component: | Rules Core |
| Category: | feature request |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | patch (to be ported) |
| Issue tags: | data transforms, Scheduling |
Issue Summary
Quick question: Is it possible to have a rule based on the age of a node, or the time since the last update?
My goal: On a job board, change the status of nodes older than 30 days to "inactive." I'm not sure I want to unpublish the old nodes, since a user who posted a job might want to change it back to active later on, to fill another position.
Comments
#1
I would think so-- you could use the cron event, then write the condition with php to check for the age of the node, and use either existing actions or write a custom one with php as well.
#2
you can also use scheduling, once the node is created configure a rule set to be scheduled 30days later. Then 30days later the rule set can unpublish the job.
#3
Automatically closed -- issue fixed for two weeks with no activity.
#4
Hi,
I hate to open this up but I need a little help. I need to go back and use Rules retroactively. In other words, I can't use the Rules scheduling function because I need to execute a rule based on how old the node is and not on how many days will pass.
A previous poster said "write the condition with php to check for the age of the node." Can someone give me some code on how to do this? I need to check to see if the node is 30 days old and if it is, I will need to execute a rule set.
Thanks in advance
#5
Something like this:
<?php
/**
* Implementation of hook_rules_condition_info().
*/
function example_rules_condition_info() {
return array(
'example_condition_node_min_age' => array(
'label' => t('Minimum node age'),
'arguments' => array(
'node' => array('type' => 'node', 'label' => t('Node')),
'number' => array('type' => 'number', 'label' => t('Minimal node age'))
),
'module' => 'Node',
),
);
}
/**
* Evaluates the age of a node
*/
function example_condition_node_min_age($node, $number) {
// compare node creation date in $node object with $number here
// return TRUE of FALSE accordingly
}
?>
#6
Thanks for this. Where should I put it? Do I put it into the module or use it inside of Drupal with the Rules module? Sorry, I am quite new to all of this any help would be appreciated.
#7
Hi mrwhizkid,
I had a very similar requirement and have packaged jpoesen's code into a tiny module ("Rules Extensions", rules_xt, attached).
Install and enable like any other module at Administer >> Site building >> Modules.
The way I use it is to send out a reminder email to the author when content of a certain type (e.g. a "News" or "Events") has not been updated for, say, 14 days.
Having enabled the attached module, this is how I went about creating the appropriate Rule Set and scheduling this Rule Set as a Triggered Rule, fired by the "After updating existing content" event.
Administer >> Rules >> Rule sets >> Add a new rule set. Call it "If content unchanged, send reminder (rule set)". Inside create a rule "If content unchanged, send reminder (rule)"
For the argument select the Data type: Content.
Add a condition: "Node: Content was changed" (provided by the new module). Enter the number of days. Don't forget to tick the Negate box, to create the condition of the node not having changed for x days. For testing purposes enter zero for the number of days.
Add an action "System: Send an email"... To a role or fixed address, either is fine.
We now need to schedule the Rule Set thus created and instigate the act of scheduling whenever content of the designated type (page, story... or your own type) is updated.
So Administer >> Rules >> Triggered rules >> Add a new rule. Call it "Schedule email reminder for content of type some_type".
For the event use "After updating existing content"
Add a condition : "Node: Content has type". Select one or more types.
Add an action: scroll down to the section Rule Scheduler and find your Rule Set name, preceded by the word "Scheduled", i.e. "Scheduled If content unchanged, send reminder (rule set)".
For the Identifier enter: "[node:title]: scheduled check for unchanged content".
For Scheduled evaluation date enter "+ 14 days", or maybe "+1 minute" while testing.
Now edit a piece of content that is of the designated type and press Save.
Go to Administer >> Rules >> Rule sets >> Scheduling to verify that your triggered rule is scheduled. Then after 1 minute (or whenever cron next runs, i.e. manually by going to .../admin/reports/status/run-cron), the triggered rule should fire its action (i.e. rule set) after which the task will be removed from the Scheduling page. An email should be sent.
When it looks like all's working, change the "Scheduled evaluation date" to "+14 days" (or whatever value you like) and in the "Content was changed" condition set the period to a value just under what you put at "Scheduled evaluation date", e.g. 13.9
Hope you find this useful.
Rik
#8
#9
Attachment would be handy wouldn't it?
#10
Thanks very much, RdeBoer! I'll try it out this weekend. Looks very promising.
#11
I will be trying this out over the weekend as well. Thanks for the great work!
#12
Hi again,
I must be missing something. The extension of the file within the module folder is .tar_
I tried changing it to .module but to no avail.
How should this be uploaded? Thanks
#13
Could you include this with rules and roll a proper patch for that? I think this would make sense to ship with rules.
However, perhaps we should start introducing a new "duration" data type, which in the end passes the duration always in seconds but might provide some nicer form? Well for now the approach with the days is probably fine.
#14
Re #12:
Sorry mrwhizkid,
Typo.... Just rename the partly unzipped rules_xt.tar_ to rules_xt.tar and complete the tar/unzip process as per normal, using 7-zip or similar.
Rik
#15
Re #13
Can do fago.... For the moment it was just a quick patch to help these guys... and myself with an immediate need.
As you suggest, this may require some more thoughts before integrating it with Rules proper.
Rik
#16
+1 subscribing
#17
Tested and the rules_xt module works great.
I was wondering if 'user has not logged in for x days' condition can be added to this module?
Thanks!
#18
I don't see why not... it's just a matter of finding the time to do it!
#19
awesome awesome!
i'm only a web designer but will be prepared to help with extensive testing =D
please let me know if there is anything I can do to help.
#20
hello Everyone,
I believe 'User has not logged in for X days' would be very useful! I would use it to send reminders, unpublish nodes and deactivate accounts over 1 year etc. Would anyone in the community be able to give this some attention in the near future? Would really appreciate it!
I have opened it as a separate feature request at http://drupal.org/node/686498
Thanks very much in advance.
#21
>I was wondering if 'user has not logged in for x days' condition can be added to this module?
I would be fine with that. Just roll a patch.
#22
+1 subscribing
#23
May I kindly ask if there has been any further development? Thank you
#24
+1 subscribing
#25
Well the little module attached in #9 (installation instruction in #7) works.
Is the question about "further development" about incorporation into the Rules module proper or about 'user has not logged in for x days', which is discussed here: #686498: Rule "user has not logged in for x days" ?
#26
hello RdeBoer,
I was wondering if there has been any changes/development since #9 and if this custom module will be added to the Rules module in the near future. Thank you for the link to #686498: Rule "user has not logged in for x days"
Thanks!
#27
+1
#28
I was wondering if the additions in #9 will be committed to the core rules module?
#29
I'm open for adding this kind of condition. For that the condition need to be added to the rules module integration and then roll a proper patch. Also the wording of the condition label should be better.
#30
#31
Rules Engine is for bugs in the engine itself. Fixing component. :)
#32
@fago: Where's a good place to put this condition, and what's a good name?
Note: I don't think other conditions use 'not' in their names, because there's a negate option for that.
#33
subscribing
#34
IMHO, this issue primarily illustrates that rules_scheduler is underutilized, see also #686498: Rule "user has not logged in for x days".
The problem is that it is both a very advanced and very new feature that will require more effort to help users get over the initial hurdle. I personally haven't started using it because it seems too advanced and there seems to be a lot of confusion around it, see comments section in [#517674].
For those who are familiar with the module, please help digest the comments on the existing tutorial and in this issue to create a more robust tutorial.
#35
#36
I agree with the sentiment voiced in #34. However I'm not sure changing the title of this thread is appropriate, as it IS about a new feature/module in the context of the Rules Scheduler. (see #4...#9), rather than its documentation.
Should #34 perhaps be created as a new issue, "Improve Rules Scheduler documentation", rather than hijacking the original issue for this?
#37
@RdoBoer: I see your point. I was primarily going along with fago's logic in #2 and #686498: Rule "user has not logged in for x days" and trying to help along those lines. I see now that the scheduler isn't the answer to the functionality requested here because this is about evaluating the age of a node or how recently it was modified. This is best solved as a condition.
The implementations offered so far have been conditions for "Minimum node age" and "Content was changed within X," so I think we're on the right track, but wouldn't it be nice to use a single configurable condition for all use cases? Since both implementations are based on an evaluation of date and time, I think a single "Date & Time Comparison" condition could look like this:
- select first comparison source: date created, date published, date field, etc.
- select second comparison source: current date, latest modification, earliest modification, etc.
- select an operator: is on/at, is before, is after
The 'textual comparison' condition already offers a very similar template of this functionality, and I think an important question might as well be, "what is missing from a unified comparison condition?" 'Textual comparison' already offers "is equal to, is greater than, is less than" operators, so 'date & time comparison' could both use the same operators (the two groups of operators do have subtle differences though). In any event, I think they are similar and could eventually be a unified comparison condition.
Regarding the submitter's example for this requested functionality, to "change the status of nodes older than 30 days," you would still need to program some custom functionality to accomplish this in 6.x. See #371728-10: Load Multiple Nodes to perform actions on them. This functionality will however be available out-of-the box in 7.x since you can only load a single node in 6.x, while in 7.x you can load lists.
Additionally, here are some other implementations I found that may be helpful:
- http://wufoo.com/docs/rule-builder/#uio
- http://www.communigate.com/CommuniGatePro/Rules.html#Conditions
- http://www.w3.org/Submission/SWRL/#8.5 (represents comparisons as durations)
#38
Actually, I think this is pretty much solved in 7.x using the 'data comparison' condition and its operator_options. You could probably use the 'textual comparison' condition in 6.x in the meantime as well.
I created another issue which is basically a duplicate of this requested functionality in 7.x: #828788: Improve the operator names for date comparisons.
#39
Another example of "future date" comparisons in 6.x.1.3, using a simple logical expression and a token can be found on this project page: http://drupal.org/project/workflow_extensions.
The fully detailed example in the appendix of that project page relates to a workflow context, however, the method followed is generic in its use of rules, conditions, actions and the rules scheduler and may be applied --with minor mods-- in different applications.
#40
I've also been looking into using rules to send an email when content hasn't been changed in x days. Quick question: has anyone got any feedback on the performance of this method? It strikes me as a bit inefficient creating a new scheduled rule each time a node's updated, but I'd love to hear from folk who've used it.
#41
Does anyone know if rules_xt is included in Rules 6.x-1.x-dev now or still not?
#42
It doesn't seem to be included yet. I hope someone could help make it into a patch that can get into the core module.
Thank you very much
#43
I created a patch that adds a Date/Time Comparison condition for Rules. It's entirely generic and accepts token input (for the *:raw timestamp).
For the use case in the OP, the condition would be set to Date/Time comparison:
Please test and report back.
#44
That makes sense to me. However, new features have to go into d7 first right now. Once we fixed it there, we can backport it do d6.
#45
@fago: can you point out where these items would go in the new code layout?
#46
We have already a date/time comparison in d7, it works with the general data comparison condition. It does not feature the granularity setting though. What would be the use-case for that?
#47
a good one is in the original issue description ;-)
#48
But I don't need the granularity option to check whether a duration is greather than 30 days?
#49
right.
another current use case of mine:
* perform a bulk node upgrade when a new day / new month has come
#50
#43: rules-348731.patch queued for re-testing.
#51
The last submitted patch, rules-348731.patch, failed testing.
#52
See #43.
#53
Updated component.