[Kolab-devel] KDE Client: events, invitations and several folders trouble

[Bernhard Reiter]

Looks like our current KDE Clients - especially enterprise35 - can lead to 
some unwanted behaviour in the situations where a client sees the same event
from within several folders it can write.

This is something client development is struggling with and the problem is not 
easy. In the last two weeks, people following the e35 development will have 
noticed that we did a lot of improvements in that area (overall e35 
development has been quite fast).

We are trying to sort out the problems and find the conceptual good solutions.
I have not been successful yet, but I attach a small overview with some 
thought and relations of some technical issues that have been battled 
currently.

One solution idea is to save per event the user email addresses for which this
saved object is maintained for. But this has not been fully considered in all 
cases.

I will sync up with Till next and guess that I really need to start a wiki 
page to slowly sort out the whole situation.

Bernhard

[1] A good place to see the overal progress is the Newslog.txt for e35:
http://websvn.kde.org/branches/kdepim/enterprise/kdepim/NewsLog.txt?revision=HEAD&view=markup

-- 
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 --------------
Trying to get the overview for the calender invitation issues:
(20090814ber1)

Status with 
Version: 4:3.5.10.enterprise.0.20090807.1010452-kk3

The problems can be categorized from the point of view of 
one specific single event 
and behaviour of one Kolab Client:

Group A:
The client has no access to calender folders where other users would 
want to write the event.

Possibly the client has several calender folders, 
also from others users or from several dimap accounts.

Defects from group A can of course lead to symptoms in group B.
Given a request to create or change an event, the client cannot
be sure to decide if it is in group A or B, because later access rights
in folders might change or other resources might be taken away or added.
So an algorithm must always consider the group B problem.
For testing group A is in the area of simple problems.

Group B:
The client has access to calender folder where other user
would want to write the event as well.

=========Group A
  kolab/issue3776 (On invitation updates, I get asked for the calender folder to save in (rt#5803))
  -> can cause group B problem. Looks better with 20090807.1010452-kk3

  kolab/issue3802 (Event update not registered correctly (also causes wrong color) (rt#5803))
  -> fixed with 20090807.1010334-kk2

  kolab/issue3779 (With two dimap account, updates do not find the corresponding saved event (e.g. leading to inability to remove deleted appointment)) 
  -> fixed, 20090731.1006813-kk3

  kolab/issue3780 (Rejecting an invitation for an event that the user has not seen before, leads to an error message) 
  -> fixed, regression
  
=========Group B problems
  kolab/issue3724 (Appointments vanish, when having access to other participants calender folders (rt#5803))
  -> still open at least because issue3811 is open

  kolab/issue 3811 (The appointments of an organizer vanish, when an attendee has the calendar shared and rejects(rt#5803))
  -> still open, solution suggestion in the issue as of 14:56Z.

-------------- 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/devel/attachments/20090814/87a5e214/attachment.sig>