[Kroupware] Questions about Shared Resources & Concurrent Access

[Diego Rivera]

Something that just occurred to me after reading the tech docs: 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.  If you REALLY want to throw a
monkey wrench into the gears then picture them using different software
clients to access Kolab (Kroupware, Outlook 2000 (in legacy mode),
some-other-thing [Evolution?]).

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.

Has anyone thought about scenarios like these?  Am I talking out of my
rear end?  I do see this case being more common for larger installations
- am I missing something?

I think it may (likely) be important to handle these cases - although I
do grant right off the bat that it might not be necessary (i.e., one
administrator per resource, well published), and it might even be
overkill.  However, as organizations grow larger this increasingly
becomes the case - coordinating for use of company transportation,
conference rooms, video-beam equipment, you name it: all resources that
need to be time-administered and it's possible that the corporate
infrastructure might already be in place to handle this.

Your thoughts?

Best

-- 
===========================================================
* Diego Rivera                                            *
*                                                         *
* "The Disease: Windows, the cure: Linux"                 *
*                                                         *
* E-mail: lrivera<AT>racsa<DOT>co<DOT>cr                  *
* Replace: <AT>='@', <DOT>='.'                            *
*                                                         *
* GPG: BE59 5469 C696 C80D FF5C  5926 0B36 F8FF DA98 62AD *
* GPG Public Key avaliable at: http://pgp.mit.edu         *
===========================================================
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mail.kde.org/pipermail/kroupware/attachments/20030517/a1b1f101/attachment.bin