[Kolab-devel] How to deal with multiplied Kolab UIDs (Re: RE :Re: Z-push most common issue with duplicateUID)
bernhard at intevation.de
Wed Jan 4 09:51:56 CET 2012
Am Tuesday, 3. January 2012 15:37:46 schrieb Bernhard Reiter:
> 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.
I believe several times a week for a productive installation
in a 500 person organisation in the secretary scenario.
There is another scenario, which I have also mentioned in
where an organisational unit uses common folders, e.g. for events.
I see a rise of "need for coordination" in customer installations
when more people get remote clients via less reliable internet connections,
especially more laptops. I believe the "need for coordination" case to appear
their each working day throught the organisation.
> > 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 employed.
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 devel