Closed (works as designed)
Project:
Rules
Version:
7.x-2.x-dev
Component:
Rules Core
Priority:
Major
Category:
Feature request
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
18 Dec 2008 at 17:35 UTC
Updated:
11 Sep 2019 at 12:59 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
WorldFallz commentedI 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.
Comment #2
fagoyou 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.
Comment #4
mrwhizkid commentedHi,
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
Comment #5
jpoesen commentedSomething like this:
Comment #6
mrwhizkid commentedThanks 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.
Comment #7
rdeboerHi 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
Comment #8
rdeboerComment #9
rdeboerAttachment would be handy wouldn't it?
Comment #10
mrwhizkid commentedThanks very much, RdeBoer! I'll try it out this weekend. Looks very promising.
Comment #11
Bilmar commentedI will be trying this out over the weekend as well. Thanks for the great work!
Comment #12
mrwhizkid commentedHi 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
Comment #13
fagoCould 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.
Comment #14
rdeboerRe #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
Comment #15
rdeboerRe #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
Comment #16
robby.smith commented+1 subscribing
Comment #17
rburgundy commentedTested 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!
Comment #18
rdeboerI don't see why not... it's just a matter of finding the time to do it!
Comment #19
rburgundy commentedawesome 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.
Comment #20
Bilmar commentedhello 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.
Comment #21
fago>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.
Comment #22
YK85 commented+1 subscribing
Comment #23
YK85 commentedMay I kindly ask if there has been any further development? Thank you
Comment #24
3dloco commented+1 subscribing
Comment #25
rdeboerWell 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" ?
Comment #26
YK85 commentedhello 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!
Comment #27
3dloco commented+1
Comment #28
YK85 commentedI was wondering if the additions in #9 will be committed to the core rules module?
Comment #29
fagoI'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.
Comment #30
mitchell commentedComment #31
fagoRules Engine is for bugs in the engine itself. Fixing component. :)
Comment #32
mitchell commented@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.
Comment #33
zeezhao commentedsubscribing
Comment #34
mitchell commentedIMHO, 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.
Comment #35
mitchell commentedComment #36
rdeboerI 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?
Comment #37
mitchell commented@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)
Comment #38
mitchell commentedActually, 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.
Comment #39
rdeboerAnother 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.
Comment #40
andyf commentedI'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.
Comment #41
YK85 commentedDoes anyone know if rules_xt is included in Rules 6.x-1.x-dev now or still not?
Comment #42
YK85 commentedIt 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
Comment #43
vkareh commentedI 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.
Comment #44
fagoThat 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.
Comment #45
geek-merlin@fago: can you point out where these items would go in the new code layout?
Comment #46
fagoWe 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?
Comment #47
geek-merlina good one is in the original issue description ;-)
Comment #48
fagoBut I don't need the granularity option to check whether a duration is greather than 30 days?
Comment #49
geek-merlinright.
another current use case of mine:
* perform a bulk node upgrade when a new day / new month has come
Comment #50
capynet commented#43: rules-348731.patch queued for re-testing.
Comment #52
mitchell commentedSee #43.
Comment #53
mitchell commentedUpdated component.
Comment #54
mitchell commentedThe patch in #43 was for 6.x, but fago said that new features were only accepted for 7.x to then be backported. Yet, 7.x already has this feature, by and large (..kinda confusing), and the rest of the use case in OP and #49 seems best suited for separate calculation actions, rather than extending the existing data comparison condition. Therefore, I'm marking this issue as won't fix.
If anyone wants to open a new issue for backporting the 7.x condition or some variation to 6.x, then please open a new issue.
Also, I believe there are some other UX related improvements discussed here that may be worth pursing in future issues, but let's move any of those to separate issues as well.
Comment #55
mitchell commentedMore accurate.
Comment #56
Kuàilè de xīn commentedHow can I implement this in drupal version 7?
I want to check when the page was last updated and trigger mail if it was not updated in last 30days