[Kolab-devel] shared calendar as long time reminding system?

[Gunnar Wrobel]

Quoting Bernhard Reiter <bernhard at intevation.de>:

> Am Donnerstag, 10. September 2009 10:12:18 schrieb Thorsten Schnebeck:
>> we are searching for a solution to set-up a reminding system for tasks in
>> the remote future. This can not be a per user setting as it is not sure
>> that the user still works in the company when the task arise. So, every
>> Kolab user should be able to create such a reminder and the system should
>> send a reminder email to a distribution list. This distribution list
>> contains all users that take care of these tasks in the future.
>> So, I set-up a shared calendar and used Horde to insert the reminder.
>
> An reminder for a task or an event is saved in the groupware object
> in order to be used by a client. How the client notifies the user,
> is something the client can decide up to a point.
> Of course to be able to read the object, a client must be running.
>
>> This seems to work for stuff like creating and deleting but the
>> email- reminder  seems to be a per user setting.
>> But I need this as a feature of the shared  calendar.
>
> A shared calendar folder (which should belong to an account, but  
> this does not
> matter) has the object, thus all readers can see that there is a reminder
> wanted with this object and could react. In other words: All users already
> have the reminder information, if it is saved in a folder those users have
> access to.
>
> The issue here is that you would want someone to send out the email reminder
> even if no client is running. So we need a daemon on the server which
> periodically watches the folder in question and issues a reminder.
>
>> Maybe someone has an idea how to solve this issue or knows a
>> better way how to handle the whole problem? Maybe its better to use the
>> shared calendar of a virtual user?
>
> I guess the hackish solution would be to make sure a webclient is running all
> the time that has access to the folder and will just send out emails for each
> reminder. You might need a script to keep the horde sessing alive, though.
>
> A better solution would be to implement a daemon that does the same job. It
> would be less code, more robust, secure and flexible.
>
> An even better, but more long time solution would be to enhance Kolab Storage
> format and add a standard daemon for such purposes or come up with something
> else that does time based events.

I think it would also be possible to extend the Kolab Free/Busy system  
to keep track of reminders. Or to use something similar that allows  
triggering. We'd only export data relevant for the reminder on  
triggering and thus wouldn't compromise security of the imap system.

Cheers,

Gunnar

>
> Best,
> Bernhard
> --
> Managing Director - Owner: www.intevation.net       (Free Software Company)
> Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
> Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
> Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.kolab.org/pipermail/devel/attachments/20090911/a413a79b/attachment.sig>