[Kolab-devel] Private calendar/tasks items
bernhard at intevation.de
Thu Jan 5 12:14:54 CET 2006
Am Mittwoch, 4. Januar 2006 11:56 schrieb Pieter Vanmeerbeek:
> I'm using the kolab/Kontact/Konsec combination for a while now (which is
> really great), but I'm missing one important concept: private items.
Please note that some of the discussion has been done on the kolab-format list
https://intevation.de/roundup/kolab/issue1041 (private event not private).
(If choosing a place for in depth discussion, I think that we should use
kolab-format or kolab-devel and I tend towards the devel list,
so please all reply to kolab-devel for this discussion.)
There is no conclusion yet and it looks like any solution will not be easy.
Also note that PDA handling is considered a topic that needs serious resources
to get right and the Kolab-Konsortium (KK) has not found major funding for it
to full steam work on a solution. Phrasing this more positively: If KK had
more resources to work on the problem, e.g. by a large contract or even more
smaller ones, a solution would be a lot faster in coming.
In the following I give you my state of mind on the issue.
This is subject to further discussion of course
and their are dissenting opinions.
> Both Konsec and Kontact have the property to make a calendar appointment or
> task private. However kolab does not private a mechanisme to achieve this.
> This is an advantage for exchange as they do support this.
I consider the possibility to have a second folder with other access rights
a good solution for this problem so I say that Kolab has a possibility to make
private appointments/tasks/contact card/emails.
It is just a bit uncomfortable right now.
Technically the Kolab concept has advantages that counter weight
the exchange solution for it:
a) It is better security wise, because it has a cleaner seperation
helping security rule number one: Keep it simple.
b) You avoid the frequently seen: To keep a group calender you need to copy
the event -- effect.
> Other groupware clients also tried to implement this, however they put the
> implementation logic in the mail client itself, which is not good as
> consulting your mail account using another mail client will reveal private
I think there is agreement that this is a fake solution,
as the event is not secured reasonably (even in cases somebody can control
the client software and the network to a great extend).
> A simple solution which is currently possible is to add a second calendar
> (task folder) which is not shared with other users for private items.
> However this calendar can not be synced with palm/pocketpc as most
> synchronization software only allow syncing of one calendar. Secondly
> reminders will not work on a second calendar in outlook (don't know if the
> same is valid for contact). So I don't think this is a very good solution
The KDE Kolab client (based on Kontact) actually can do reminders
and together with the KDE framework we can make the sync work.
Note that this is only one fraction of sync problems that Kolab and other
Groupware solutions have.
My idea to make this solution better for Outlook, we should convince Radley
Network Technologies (makers of Toltec) and Konsec to implement a simple
reminder handling for other folders. They should be able to get the
necessary information (hardest case: Offline work, no sync) and fireing up
a dialog is comparatively easy I would assume.
This would leave the PDA sync problem, which could be attacked several ways
i) Make the sync applications also sync other folders.
ii) Use a server side sync anyway
I cannot say if i) is possible at all and
ii) will be a lot more difficult to do than a local sync on Windows and KDE.
> In my opinion two solutions exist for this:
> 1. Use some kind of encryption key
I guess this is very hard as it would mean to completey implement
real encryption in the Outlook connectors which is a haunting task.
> 2. Use the same idea of multiple calendars/task folders, however hidden by
> kolab towards the clients behind one combined calendar/task folder.
Not that Kolab is the name for the concept and the server and client
implementations. Thinking that you refer to the Kolab Server,
this is a bad place to implement this. It would mean massive
changes to the imapd which talks to the client
which probably would make it less secure.
On the client side this is already happening with the KDE Kolab Client
and within Outlook
it would have been done by the connectors in one way or the other.
> I believe implementing this feature will eliminate one of the few
> advantages left that exchange has over the kolab system. Certainly because
> both contact and outlook already provide an interface for private items
My current approach is to explain it to users
that what they see is a "sensitivity" setting for the Kolab.
As Kolab has better way to modell usage, one is mentioned above
as advantage b), there is a need to communicate with users anyway.
If they have been doing b) for most of their work releated appointments
it might eben be an improvement to copy dummy event in the main folder
only for their privat events now.
Using the access control in the folder properties then is a lot more inuitive,
because there is one place where access control is done.
More information about the devel