<HEAD><TITLE>Todo Manager ACS Module</TITLE></HEAD>
<BODY bgcolor=white>
<h2>Todo Manager</h2>
by <a href=http://ben.adida.net>Ben Adida</a>
<hr><p>
<h3>Purpose</h3>
The Todo Manager is meant to allow collaboration of task-list creation
and completion. It is initially closely modeled on the PalmPilot ToDo
app, with added collaboration.
<p>
The Todo Manager also includes plugability for other modules to
display their information as todos. This allows as single
organizational module to display tasks to the end-user.
<p>
<h3>The Todo Plugin Architecture</h3>
A few important things about the plug-in architecture.
<ul>
<li>There is a runtime association between the
todo module and other modules. Nothing in the database represents this
association.
<li>One plug-in can declare multiple categories for a given user, each
of which will correspond to one to-do list for that user.
<li>It is the plug-in's role to register with the todo manager and to
provide a call-back API to display todos.
</ul>
The registration proc will be as follows:
<p>
<pre>
proc todo_plugin_register {plugin_name plugin_procs}
</pre>
<p>
where plugin_procs is an ns_set containing the callback API. The
todo plugin registration expects the following callbacks:
<ul>
<li> GET_PERSONAL_CATEGORIES: a procedure that takes a db connection
and a user id and returns the categories that that user can see that
are personal to him.
<li> GET_OTHER_CATEGORIES: a procedure that takes a db connection and
a user_id and returns the categories that that user can see that
belong other to users.
<li> ITEM_CHANGE_ALLOWED_P: 1 or 0 depending on whether the user
can change the item from the todo interface or not.
<li> ITEM_CHANGE: the name of a procedure that takes the following
arguments:
<ul>
<li> a db conn.
<li> user_id: the user.
<li> todo_id: the id of the item. This id only has a meaning to
the plug-in, it is not the id of a real to-do item.
<li> new_date: the new date in standard SQL format.
<li> new_priority: the new priority
<li> new_item_details: the new item details
</ul>
This procedure may be blank if the date is not allowed to change.
<li> MARK_COMPLETED_ALLOWED_P: 1 or 0 depending on whether the user
can mark an item as completed from the todo interface or not.
<li> MARK_COMPLETED: the name of a procedure that takes the following
arguments:
<ul>
<li> a db conn
<li> user_id: the user performing the operation
<li> todo_id: the id of the item.
<li> completion_date: when the item was completed. This argument
is not mandatory.
</ul>
<li> ONE_ITEM_URL: the url for a single todo. This will be given the
todo_id as argument.
<li> ITEM_LIST_SQL: a procedure that takes the following arguments:
<ul>
<li> a db conn
<li> user_id: the user for whom we're querying.
<li> category: the category of the todos.
<li> date_prettifier: a PL/SQL proc that prettifies the due date
according to the to-do way of doing things.
<li> n_days_to_show_completed_items: the number of days that
complete items should show up for after they've been completed.
<li> completion_status: "open" "closed" or "both" depending on
what we want to show.
</ul>
the SQL that produces the list of todos. This must
return the following named columns:
<ul>
<li> todo_id: the id number. This means something only to the
plugin itself, not to the todo list. It is an identifier that
will be used to throw the user back into the plugged-in module.
<li> due_date: in the classic todo format of yesterday, today,
etc... the todo PL/SQL can be used for this.
<li> one_line: a one-liner description of the todo item.
<li> priority: the priority of the todo item.
<li> completed_p: whether or not this item has been completed
</ul>
</ul>
</BODY>