shared calendar as long time reminding system?

Bernhard Reiter bernhard at intevation.de
Thu Sep 10 12:10:56 CEST 2009


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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/users/attachments/20090910/d7730f6f/attachment.sig>


More information about the users mailing list