I probably shouldn't label this is a bug although it did cause me some consternation last night. I'm developing a custom module that automatically schedules workflow state change. I did this by inserting a row into {workflow_scheduled_transition} from the custom module. The problem is that the workflow_execute_transition function in workflow.module purges this table right after it is updated. There may be a call that avoids this deletion this but I didn't see it. To workaround this problem, I moved the deletion line to the workflow_cron where it deletes transitions scheduled before current time. Maybe I missed something but this patch works for me.

Running Drupal 5.1, PHP 4.3.10, Linux, MySQL 4.1.15

CommentFileSizeAuthor
#7 workflow_scheduling_1.patch654 bytesamanire
#6 workflow_scheduling_0.patch654 bytesamanire
workflow_scheduling.patch834 bytesamanire

Comments

mfredrickson’s picture

mfredrickson commented

I'm guessing you are trying to schedule two transitions? Eg. One to scheduling publishing and one to scheduling unpublishing.

The reason the scheduling code deletes all entries for a given node id is because of the following use case:

Admin schedules state change for node X on Monday at 7:00pm. Later, she realizes that it should happen Tuesday at 3:00pm. On node submission, we don't know the previous scheduling, so we have to clear all schedules for node X - otherwise the state change would occur at the scheduled time.

I would like to meet your needs, but I have to be sure the use case I just listed will be met.

amanire’s picture

amanire commented

Thanks for the prompt reply! That case makes sense. I am using one transition change to schedule another. Here are my workflow states concerning this issue:

Viewed
Accepted
Followup

When the user changes Viewed to Accepted I want the module to automatically schedule a transition to Followup, 30 days from the time of the change. Appending to {workflow_scheduled_transition} seemed like an easy way to accomplish this until I encountered the deletion for the case that you've described.

Perhaps the solution involves somehow setting the scheduled transition after update in workflow_nodeapi executes, but it isn't clear to me how to do this.

amanire’s picture

amanire commented

Actually, it just occured to me that the case you described shouldn't occur during the update, since it is deleting the contents of the table when Schedule: is set to Immediately. That should be a simple fix.

amanire’s picture

amanire commented

Well, that's not so easy since workflow_scheduled is set to true by the custom module insertion prior to the deletion.

amanire’s picture

amanire commented

In fact, a simple check on workflow_scheduled before deleting all the entries in {workflow_scheduled_transition} for that node id did work for my purposes.

if ($node->workflow_scheduled) {
  db_query('DELETE FROM {workflow_scheduled_transition} WHERE nid = %d', $node->nid);
}
amanire’s picture

amanire commented
StatusFileSize
new workflow_scheduling_0.patch654 bytes

oops, forgot to attach the patch

amanire’s picture

amanire commented
StatusFileSize
new workflow_scheduling_1.patch654 bytes

Argh.. ignore that previous patch. This is the one.

Bastlynn’s picture

Bastlynn commented
Status: Needs review » Closed (won't fix)

Hi,

With the release of Drupal 7, Drupal 5 is no longer receiving security updates, reviews, or development from many contributed modules. Since 5 is now considered a depreciated version, you really should seriously look into upgrading to Drupal 6 or 7. The newer versions of Drupal work better, have more support, and will be safer (literally! security patches!) for your website. We are currently working on a new release for Workflow to Drupal 7. In light of that, further support for Drupal 5 issues is infeasible at the moment. Please consider upgrading to Drupal 6 or 7 in the near future - you'll be glad you did.

- Bastlynn