Tutorial for Rules Scheduler Module

New docu page with a basic example is online now: http://drupal.org/node/517674

There are now 3 examples on the tutorial page, please have a look and report any questions!

@Use-case 1:
>We want to recognize the content somehow, so we fill out the Identifier field with "[node:nid] - [node:title]" to get the node ID and the title of the created content.

Why do we want to do so? Actually I don't know why either as your example makes no use of the identifier later on. Perhaps shortly explain when and why to use an identifier?
Also as we talked, I think the the id suffices as id.

@Use-case 2:
You never mention that the task is updated on update, I think that should be explained. Also at there is now the possibility to cancel a task I think it should be used in that case if the node is deleted. So the task isn't fired just to see that the node is gone.

I split up the page now in three separate tutorial pages to highlight the use cases in the tutorial title.
I think I also addressed your comments, however I left the user provided identifier to be "node [node:nid]", because the nid alone could be confused with an uid or comment ID etc.
See the tutorial overview page to get to the scheduling tutorials: http://drupal.org/node/298482

Great done! I see "node [node:nid]" really makes sense for deleting.

Automatically closed -- issue fixed for 2 weeks with no activity.

Thank you for those tutorials!

I've followed Tutorial 3: Publish content based on a CCK date field, and this works quite well, except for one problem: we end up with two scheduled rulesets, one that publishes and one that unpublishes the given node. The problem is that both of these modify the node, which triggers the Update rules to reschedule the rulesets. This is done on every cron run, and it never ends until you manually delete the entries!

I've tried adding actions to remove the scheduled rulesets, but I haven't been successful. The problem is that the nodes are not saved (and the rulesets rescheduled) until the very end, after any remove actions have already been executed.

Is there a way to avoid this problem in the current implementation?

Does it even make sense to allow scheduling rulesets in the past? If Rules Scheduler would ignore such requests, the problem would go away...

I was irritated enough by the watchdog pollution to write the patch in #643464: Avoid scheduling past-due rulesets.

> Does it even make sense to allow scheduling rulesets in the past? If Rules Scheduler would ignore such requests, the problem would go away...

Yes, because Rules Scheduler relies on Cron. We don't know how often cron runs on a site, so Rules Scheduler is designed to execute all rule sets that are in the past and not yet removed from the scheduling table. After execution the scheduled item is removed, so it won't be scheduled again.

An action to remove already scheduled rule sets has to match the identifier assigned to the scheduled rule set.

Yes, because Rules Scheduler relies on Cron. We don't know how often cron runs on a site, so Rules Scheduler is designed to execute all rule sets that are in the past and not yet removed from the scheduling table.

I agree with that, I'm not saying the scheduler should ignore past-due items when it gets around to execute them. I'm saying they shouldn't be allowed to enter the queue if they're already past-due.

After execution the scheduled item is removed, so it won't be scheduled again.

That's correct, but when you follow Tutorial 3, then every cron run creates as many scheduled items as it removes. Try it...

An action to remove already scheduled rule sets has to match the identifier assigned to the scheduled rule set.

I've tried that, but the problem is that the node is saved (and the creation of the new items triggered) AFTER the remove action has run, even if it's in a separate rule set!

OK, to stop the re-scheduling loop, you have to add a condition "NOT Content is published", because it is pretty useless to schedule publishing if a node is already published. We should fix that in the tutorial.

Your point concerning the scheduling of dates in the past is valid, though. We should think about what most Rules users would expect in such a situation.

OK, to stop the re-scheduling loop, you have to add a condition "NOT Content is published"

I don't think this is enough to break the loop. At the point where the node is intentionally unpublished, the saving of the updated unpublished node will trigger the scheduling of the Publish rule again (the condition "NOT Content is published" is true at that point)...

My patch in #643464: Avoid scheduling past-due rulesets lets the user decide whether they want to allow scheduling in the past or not. It's the only way I've found to break the loop.

subscribing