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.

Response sent to kolab-devel@


>
> 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/users/attachments/20090911/2ccbd0b7/attachment.sig>