[Kolab-devel] How to deal with multiplied Kolab UIDs (Re: RE :Re: Z-push most common issue with duplicateUID)
bernhard at intevation.de
Tue Jan 3 15:37:46 CET 2012
Am Tuesday, 3. January 2012 14:28:53 schrieb Georg C. F. Greve:
> On Tuesday 03 January 2012 14.00:04 Bernhard Reiter wrote:
> > b) there is a need for human coordination, because secretary S1 entered
> > something while secretary S2 entered something else at the same time.
> What are the statistics how often this happens in practice?
I do not have measured stats, but I consider it relevant.
> Do we know how many percent of our users have two secretaries which happen
> not to be sitting in permanently connected offices and thus would be
> subject to this occurring?
Usually the higher up in the organisation the greater the need is for
managed appointments. And usually there are a number of people editing
appointments in the same calender. I estimate this to be a relevent problem
and all customer I know sooner or later start editing with several clients
on the same object folders. As this is a strength of the Kolab concept it
usually requires a bit of time within the organisation before this gets fully
> > Again, the last modification *must* not win in case b).
> FWIW, I don't agree.
This has been a core point of the Kolab Concept.
> Point (b) seems very much a fringe case, and requiring user interaction for
> this puts an onerous burden on all clients which substantially reduces
> usability in all the most common scenarios.
Doing this differently means loss of information in some scenarious
and makes a groupware unusable, because just the loss of a hand-full
of events to top managemant a year will kill the trust in your groupware.
As outlined above I have seen those issues in practice with customer
and consider it a relevant case.
Managing Director + Owner: www.Intevation.net <- A Free Software Company
Kolabsys.com: Board Member FSFE.org: Founding GA Member
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...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the format