Summary | Provide a notification that a task has been added to your tasklist |
Queue | Nag |
Queue Version | HEAD |
Type | Enhancement |
State | Resolved |
Priority | 1. Low |
Owners | |
Requester | kevin_myer (at) iu13 (dot) org |
Created | 07/25/2005 (7290 days ago) |
Due | |
Updated | 11/25/2005 (7167 days ago) |
Assigned | |
Resolved | 11/25/2005 (7167 days ago) |
Milestone | |
Patch | No |
State ⇒ Resolved
line up Nag 2.1 with Kronolith 2.1.
New Attachment: nag-notification[2].patch
if the return value of _add() is an error and don't proceed in this
case.
Are you going to update the patch to hook into editing and deleting,
or should I commit it for now?
guess I never added it. Here's an updated version and it handles
editing and deleting too.
the return value of _add() is an error and don't proceed in this case.
Are you going to update the patch to hook into editing and deleting,
or should I commit it for now?
thinking that it could be used to set the X-Priority header in the
email that is generated.
New Attachment: nag-notification[1].patch
currently only handles notifications when tasks are added but could be
extended in the same manner for modifications or deletions. I added a
$uid parameter to the kolab driver, only because it existed in the SQL
driver, but it looks like they are autogenerated anyway, so it might
not be necessary. The notification could be changed to work with a
user's 'date_format' and 'time_format' preferences, but I think that
would only make sense if time_format was in the horde preference scope
and not imp.
State ⇒ Feedback
History logging and notificiation would be done in add() and the
actual adding in _add().
specific code in Driver_foo::add() and drawing the common code into
Driver::add()?
because you will call these methods from the parent class, not the
parent class' method from the inherited class.
sense to make those changes, I can certainly try :)
with *all* driver at once.
History logging and notificiation would be done in add() and the
actual adding in _add().
specific code in Driver_foo::add() and drawing the common code into
Driver::add()?
I really only wanted to get notifications working, but if it makes
sense to make those changes, I can certainly try :)
History logging and notificiation would be done in add() and the
actual adding in _add().
New Attachment: nag-notification.patch
simpler to model the Kronolith code for this, so this also implements
a (largely unused) Nag_Task object, based on the Kronolith_Event
object. Notifications are currently only supported in the SQL driver,
although it should be easily adapted to the Kolab driver, but I have
no way of testing that.
Priority ⇒ 1. Low
Type ⇒ Enhancement
Summary ⇒ Provide a notification that a task has been added to your tasklist
Queue ⇒ Nag
State ⇒ New
where you can choose the types of actions for an event on your
calendar that generate a notification for you. Example, if someone
adds a task to your tasklist, you could choose to be notified by email
that a new task has been addded.