Make scheduler more generic?

So, in essence, what you're proposing is a trigger where the triggering event is the passage of time, rather than some specific action being performed by a user.

Scheduler probably wouldn't need to provide any actions, unless you wanted to add the node deletion action, which doesn't exist in Actions (at least for the 5.x versions).

After playing with the 5.x-1.x and 5.x-2.x versions of Actions, Triggers and Workflow (and Triggerunlock, which is necessary for the 5.x-2.x & 6.x versions), the only two drawbacks I can see to this idea is 1) it seems as though a user can only schedule one state change at a time, and 2) the user can't edit the workflow at node creation time, which is when I would want to make that happen. If I were to use the Actions/Triggers/Workflow modules exclusively, I would have to create the node, edit it to set the timing for the first state change, wait for that change to happen, then set the timing for the next state change.

If what you are proposing can overcome the drawbacks, then I think it would be a fine idea.

subscribe...

Hi man, you don't need a customer trigger. Doesn't admin/build/trigger/cron for this purpose?

Generall, I think the current schedule module is too confusing. I'll suggest a total rewrite.

My idea of a schedule module should be some thing like this (in very pseudo code):

// database structure
// nid action time(utc) completed

function scheduler_form_alter() {
  
  //...

  // if node_form
  $user_timezone = _scheduler_get_user_timezone();

  $form['scheduler'] = array(
    '#type' => 'fieldset',
  );

  $actions = _scheduler_load_completed_actions();  
  $header = array('time', 'action', 'compeleted');
  $rows = array(...);
  // may show the completed scheduler action history here
  theme('table', $head, $rows);

  $actions = _scheduler_load_future_actions();  
  foreach ($actions) {
    // display existing actions for this node, editable
    $form['scheduler']['actions'][$delta]['time'] = array(
      '#type' => 'textfield',
      '#default_value' => 'now',
    );

    $form['scheduler']['actions'][$delta]['action'] = array(
      '#type' => 'checkboxes', // can have multiple actions for one time
      '#options' => _scheduler_get_supported_actions(), // publish, unpublish, delete, promte, sticky...
      '#default_value' => 'publish',
    );
  
    $form['scheduler']['actions'][$delta]['timezone'] = array(
      '#type' => 'textfield',
      '#default_value' => $user_timezone, // the user can speicify different timezone when entering
    );
  }

  $form['scheduler']['addmore'] = array( // add a line of scheduled action entry form, ajax
    '#type' => 'submit',
    '#ahah' => array(...),
  );

//...

}

function scheduler_nodeapi() {
  //  op presave
  // save the actions to db
}

// hook_cron
function scheduler_cron() {
  // get all actions which are not completed and time in the past 
  db_query("SELECT nid, action, time FROM {scheduler}". $where_not_completed_and_in_the_past);
  foreach($rows){
    $node = node_load($nid);
    if ($result = actions_do($action, $n, $context, NULL, NULL)) {
      $succeed[] = array('nid' => $nid, 'action' => $action, 'time' => time);
    }
    else {
      $failed[] = array('nid' => $nid, 'action' => $action, 'time' => time);
    }
  }
  db_query('UDPATE SET completed = 1'. $where_succeed);
  db_query('UDPATE SET completed = -1'. $where_failed);
}

?>

What are the differences between this proposal and the Scheduled Actions module? http://drupal.org/project/sched_act

I'd suggest you also have a look at the rules module, as it already offers scheduled execution of rule sets and so execution of arbitrary actions.

An additional UI like the mockup http://drupal.org/files/issues/Scheduler2Mock.png would fit perfectly. As so users would have an UI for configuring the scheduled actions on nodes. One could list all by rules supported actions in the dropdown box and once the form is submitted, just configure a rule set and its schedule programmatically and rules will do it.

>BTW: I would also like to schedule actions without a node relation. Think "point-and-click-cron"...

I also had this idea.. Basically you can do it already with rules, however there is no user friendly UI for manually scheduling stuff. Currently things get scheduled just by actions.

So the rules scheduling stuff is great for automatically created schedules like "unpublish the node in 10 days".

subscribing.

I was working with the Workflow module the other day and noted that it can do scheduled workflow state transitions.

It's also possible to trigger actions based on state changes. So, Workflow + Schedule state change + Workflow actions is one way to do this already. It's a bit more cumbersome than the way that scheduler currently works, but I thought I would mention it as similar prior art.

"Make scheduler more generic" - sounds very good ...

thanks momper

subscribing.

subscribing

subscribing

subscribing

Subscribing

It occurred to me that this might be best solved via a CCK field.
The CCK field already provides the option to do permissions and numerous hooks are integrated with different modules already.

In particular, CCK is integrated with the rules module.
The rules module supports responding to CCK field changes and also change them.

I then discovered that the Date module provides this already.
http://drupal.org/project/date

With this, the publish and unpublish scheduling functionality can be provided without doing any sort of code rewrites.

I think that the date+cck+rules replaces this project.

If this project is to be continue with a re-write, it might be more beneficial to find a way to wrap the data+cck+rules and simplify the use and management thereof.
(like a user-friendly UI suggested from #13)

At the same time, it may be better to have this project be separate from date+cck+rules.
There are probably users out that who do not want to or need to add date, cck, or even rules and want the simple & straight-forward solution that scheduler currently provides.

If this is the case, it may be best for this project to stay simple and not provide the requested functionality that is apparently already provided from date+cck+rules.
Perhaps not adding any new functionality and simply cleaning up, stabilizing, and perfecting the current functionality may be best for this project.

This sums up to two possibilities:
1) make scheduler a user friendly management UI to date+cck+rules.

or

2) do not make scheduler more generic, just keep it simple, clean, and stable.

I agree. The workflow module has a generic action scheduler but it is quite complex. I think that the goal of this module should be "light weight node publish/unpublish scheduler" and nothing more.

+1 - keep scheduler simple, clean, and stable.

@Eric Schaefer: completely agree.

There do seem to be some handbook pages with a few different methods for doing this, but the ones I've run across so far seem to be outdated, like this one: http://drupal.org/node/175319.

It might be a good idea to post other similar links (maybe there are more updated methods described somewhere I haven't seen), which could help get the ball rolling on the handbook page?

@greggles: is there a any link for how to set up workflow's generic action scheduler (Workflow + Schedule state change + Workflow actions method)?

@thekevinday: similar Q... is there any description about how the date+cck+rules method works already? my question is how can this be done automatically (i understand a rule can trigger on 'content is going to be viewed', but for instance how can nodes be unpublished X days after datefield value without having to visit each one? I think Fago mentioned somewhere

@fago: maybe the last part of the above question is for you fago... in #13 you mention this possibility, but elsewhere someone said this can't work because "during cron maintenance tasks, Rules doesn't have a node object" (#4 in #366539: Rule sets on cron execution)-- is this right? or is there another way to do this using Rules?

Anyway, hope responses may go some distance toward putting togehter a provisinoal updated handbook page Eric mentioned...

@scottrigby: It was very awkward for me to do and was not obvious at first.
Heres what I did:

*I am using Workflow here as the example action to perform on the scheduler update. (That is, to change the workflow of a node to a new state..)

1) Create a new content_type
2) Create a cck field of the type "date"
3) Create your workflow as needed and enable it for your content type created in step #1
4) Create a Rule Set, supplying an Argument of type Number with a label of nid and a machine readable name of nid
- This seems to be possible only on creation so if the Argument is not supplied, you will have to recreate the rule set
5) Edit the rule set and add a rule
6) With this rule add a "Load content by id" with a Content ID: <?php print $nid;?>
- This nid is the name of the Argument passed to the rule set
7) In this rule add the action "Populate a field", select your CCK field created in step #2, expand "Advanced: Specify the fields value with PHP code" and inside of the "Code:" box add the following code:
return array();
- This deletes the existing scheduled date, but I wasn't sure if I should return NULL instead of array() (returning array() still works however)
8) Add an action to change the workflow to whatever workflow you desired
9) You are done with Rule Sets, the next step is to create 2 more rules; These rules are done through the normal rules page and not to the rule sets.
10) Create 2 separate rules: "After saving new content", "After updating existing content" that do the same thing, but one is on creation only and the other is on updates only
11) Inside of both of the said rules, I added the condition "Check a truth value" with the following PHP snippet:
<?php if (empty($node->field_change_workflow[0]['value'])) print("0"); else print("1"); ?>
- The print()'s may be an unnecessary extra step, but I felt safer doing them directly..
- field_change_workflow should be replaced by the machine name of the CCK field you created in step #2
12) Inside of both of the said rules, I added the action to call the Rule Scheduler for the rule sets created in Steps 4-8.
- The Rule set should appear in the drop down list under the bolded "Rule Scheduler".
- If it does not appear, then you may need to either refresh or double check that you create a "Rule Set"

What happens is that whenever the cck_field gets populated with some date for the custom content type, one of the two rules from #10 will schedule the Rule Set created by steps 4-8.
Then on the specified date, the Rule set will fire, delete the data in the CCK field from step #2 and then change the workflow.

thanks to all for their involvement ...

Subscribing

Subscribing

I am entirely unconvinced.

Scheduler is not currently a 'Scheduler.' It's a 'Schedule Node Publish/Unpublish' module.

The above, describes a series of somewhat bizarre hacks to accomplish Scheduling, AFAIKT. This is not the Drupal Way.

There is a need for a general Scheduler, which allows setting a time and making things happen. The best way is probably via Rules.

This would not be difficult to implement-- see Node Expire for example code.

>There is a need for a general Scheduler, which allows setting a time and making things happen. The best way is probably via Rules.

So what about trying the rules scheduler then?

Allow me to reopen this issue.

I agree to keep this module real simple, that is, for the end-user.
But in my opinion, all "Publish options" should be handled by this module, to be fully featured. The publishing options in drupal core are:

• Published
• Promoted to front
• Sticky at top of lists

This trio has been in drupal core for ages now, and this won't probably change in the near future.

Anyway, I'm working on a patch that adds in the promoted to front scheduling for the scheduler-7.x-1.x branch.

#1092934: Scheduled promotion / demotion from Front page

The same functionality already exists in rules module.
Just set the rule to trigger a promotion/unpromotion for a given date. (such as +7 days).

Just as a help for others who got here after hours of search.

There is module for Drupal 7 that does all the general actions (publish, unpublish, promote, denote ... etc) for nodes as you can see it in this video
Screencast video
https://www.youtube.com/watch?v=LeqU4Qyh3l4

Module page
https://www.drupal.org/project/scheduled_actions