[Kroupware] Questions about Shared Resources & Concurrent Access

[Bernhard Reiter]

On Sunday 18 May 2003 03:15, Diego Rivera wrote:
> How is concurrent "control" of a particular shared resource's availability
> controlled at the Kolab level (manual, mind you - not Sieve-automated)?
> I saw no mention of this in the docs I read.
>
> I.e., a particular company's current operating procedures state that any
> Admin-Assistant can book (electronically) a conference room for use by
> whoever needs it provided they're A) authorized, or B) in need of that
> specific room for a good reason (avail. equipment, location, etc).
>
> They all (adm-asst's) have to add/remove appointments (potentially)
> concurrently, and must thus avoid clashes, but they're on different ends
> of the building - floors, aisles, etc.  
>
> How is a scenario like this handled?  In cases like this automation (via
> Sieve) might not be an option since human intervention might be
> necessary before assigning a particular timeslot (i.e., is this
> authorized by X, Y, are more than X people attending, do you require the
> room because of its equipment?) - or even deciding whether to allow the
> appointment request to proceed.

We've already thought of many scenarios and how to model them
using the Kolab approach. Not all of the possible applications
can be modelled with the current state of the software, though.

In this case the people who want to book a shared resource, like
a conference room, just invite that user dedicated for that room.
Let's assume that Kolab account for it is named room1.

At least on client has to work on "room1" to confirm the bookings.
For the KDE Kolab client there is already button that makes it
accept all invitations which are bookings in this particular case
if there are no conflicts. If you switch that feature off, 
somebody (e.g. a secretary) has to confirm this manually. 

As there can be many clients on one Kolab account,
you can have a group of people with the right to 
confirm or deny appointments.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3052 bytes
Desc: signature
Url : http://mail.kde.org/pipermail/kroupware/attachments/20030519/865a754c/smime-0001.bin