have one task type per site node

You may have already fixed these but there are a couple of issues that I noticed with the current patch that is attached here:

(1) when re-running a task it doesn't move it to the top of the task queue, the obvious change here is to order the task list by the node changed field instead of nid.

--- task/hosting_task.module	21 Sep 2009 10:10:58 -0000	1.75
+++ task/hosting_task.module	23 Sep 2009 15:41:15 -0000
@@ -506,7 +511,7 @@ function hosting_get_tasks($filter_by = 
     $cond = ' AND t.' . $filter_by . ' = %d';
     $args[] = $filter_value;
   }
-  $result = pager_query(db_rewrite_sql("SELECT *, t.task_status,q.status as queued FROM {node} n left join {hosting_task} t on n.vid=t.vid LEFT JOIN {hosting_task_queue} q ON t.nid=q.nid WHERE type='%s'" . $cond . " ORDER BY n.nid DESC"), $count, $element, NULL, $args);
+  $result = pager_query(db_rewrite_sql("SELECT *, t.task_status,q.status as queued FROM {node} n left join {hosting_task} t on n.vid=t.vid LEFT JOIN {hosting_task_queue} q ON t.nid=q.nid WHERE type='%s'" . $cond . " ORDER BY n.changed DESC, n.nid DESC"), $count, $element, NULL, $args);
   
   while ($row = db_fetch_object($result)) {
     $nodes[] = $row;

(2) the timestamp in the hosting_task_queue doesn't get updated, the main problem with this is if you had a lot of tasks queued you could end up with a case where tasks never get run. The fix is to set the timestamp when running hosting_task_update.

--- task/hosting_task.module	21 Sep 2009 10:10:58 -0000	1.75
+++ task/hosting_task.module	23 Sep 2009 15:41:15 -0000
@@ -274,7 +279,7 @@ function hosting_task_insert($node) {
     db_query("INSERT INTO {hosting_task_queue} (nid, timestamp, status) VALUES (%d, %d, %d)", $node->nid, mktime(), 1);
   }
   else {
-    db_query("UPDATE {hosting_task_queue} SET status = %d WHERE nid=%d", $node->queued, $node->nid);
+    db_query("UPDATE {hosting_task_queue} SET status=%d, timestamp=%d WHERE nid=%d", $node->queued, mktime(), $node->nid);
   }
 }

@@ -293,7 +298,7 @@ function hosting_task_update($node) {
     hosting_task_set_title($node);
     db_query("UPDATE {hosting_task} SET nid=%d, task_type = '%s', rid = %d, executed=%d, task_status=%d WHERE vid=%d",
       $node->nid, $node->task_type, $node->rid, $node->executed, $node->task_status, $node->vid);
-    db_query("UPDATE {hosting_task_queue} SET status=%d WHERE nid=%d", $node->queued, $node->nid);
+    db_query("UPDATE {hosting_task_queue} SET status=%d, timestamp=%d WHERE nid=%d", $node->queued, mktime(), $node->nid);
     if (is_array($node->task_args)) {
       # Wipe out old arguments first, since arguments could theoretically be removed.
       db_query("DELETE FROM {hosting_task_arguments} WHERE vid=%d", $node->vid);

The attached patch rolls these changes into the previous patch.

here's the latest version of the patch, so that non git people can play along.

It's a very good patch and it works as advertised, there are a couple of issues with it, primarily on the user interface level.

1. it's not clear that the task type link will create a task for you
2. some tasks are linked and some aren't, with no rhyme or reason
3. the linked 'executed' column is very confusing, you have no idea what you will be getting when you click on it.
4. the order of the items will be very important to make them useful, at the very least they should be something like :

queued tasks (in order of creation / processing)
completed tasks ( in reverse order of completed)
never queued tasks (alphabetical order).

The user always wants to see what's happening (first priority), what has already happened and then what they can further do.

5. even tho the disable task is queued there is still a link to it. this is a side effect of the text item being a link, you aren't clear if your creation worked or what is happening.

6. It feels kind of weird to have a disable and enable task in the same queue with no way of knowing what the last one was. this is a side effect of 4 and that we have 2 tasks for this, not a toggle.

concerns :

1. how is the permission checking happening in this new format? is the permission to view task logs broken down per task now too ?
2. what happens when someone else schedules a task, do i still get permission to see it? who owns them?
3. i know this is my because of how it is implemented, but the migrate tab on the platform now looks out of place, how about a hook to add additional 'tasks' even if they aren't really tasks?

I like this feature a lot, much cleaner way of seeing whats exactly happening with any site.

I think if you are going to divide the table, it should just be into 2 parts, task that you can add to the queue and tasks that are disable.

There are a couple of small changes I would suggest for the task table:
* leaving the executed column for dates (e.g. even if the backup is queued, its still useful to be able to see when the last backup was done).
* change the 'action' column to something more like 'status' and still use that for adding the "re-run/retry" task buttons on a failed task, but also use that as the place to display the state of any task like the message "queued". I can also see that column being used for other messages, like "scheduled" for tasks that get run automatically (e.g. backups).

I have attached a mock-up to illustrate better what I am meaning.