Tutorial for Rules Scheduler Module

@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.

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

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.

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"

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

subscribing

Based on Tutorial 2: Publish content exactly 24 hours after it was created if someone wants to schedule publishing of content at certain specific time how would we accomplish that? Currently this is not helping much when admins want to have a repeated weekly schedule that needs to be updated lets say at midnight.

I've set up Cron on my ISP to run every 1 hour.
I have 2 php scripts to be run one time per day, the first run at 2 AM, and the second at 3 AM.
I created an internal control in php script to check the time that it should run. As Cron runs every 1 hour, it works.
However, if I run cron manually within these times, the script runs in duplicate.
How can I have it working with the scheduler?