[dev] Proposal for Resource booking extension for Kronolith

[Stephane Pointu]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Rubinsky wrote:
> Quoting Jan Schneider <jan at horde.org>:
> 
>> Zitat von Stephane Pointu <stephane.pointu at purplelabs.com>:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Jan Schneider wrote:
>>>>
>>>> Stephane Pointu wrote:
>>>>> Hi all,
>>>>>
>>>>> Below is our proposal for implementing resources management in Horde.
>>>>> It will be based on Kronolith.
>>>>>
>>>>> The principle:
>>>>> When creating/editing an event, the user will be allowed to select a
>>>>> resource to be added to the event. If the resource is available, it
>>>>> will
>>>>> be booked (for recurrent events, only the 1st occurence is
>>>>> checked). If
>>>>> not, the user will be allowed to update the event to match a period
>>>>> where the resource is available, or remove the resource from the
>>>>> event.
>>>>> A view link is added next to each resource for the user to be able to
>>>>> view the free-busy information for the resource.
>>>>>
>>>>> Optionnally, for recurrent events, we can ask the users to confirm
>>>>> their
>>>>> next booking just after the previous event to make sure a booked
>>>>> resource is really used. The resource will be freed if the user
>>>>> does not
>>>>> confirm after x days.
>>>>>
>>>>> Optionnaly again, old bookings can be deleted automatically after a
>>>>> defined period of 1 month, 3 months, 6 months, 1 year.
>>>>>
>>>>>
>>>>> Database table to be created:
>>>>> events_resources
>>>>> + event_id -> Taken from events table
>>>>>   resources_names
>>>>>   event_date -> confirmed booking
>>>>>   next_event_date -> next event to be confirmed
>>>>>
>>>>> Below are 2 screenshots that will help to better understand our
>>>>> proposal.
>>>>>
>>>>> Please comment on this.
>>>>>
>>>>
>>>> You are working against the release version of Kronolith, but you
>>>> need to
>>>> work against CVS HEAD if you want your patches to be accepted.
>>> Of course we will work against CVS HEAD. Guillaume has not started the
>>> coding yet.
>>>
>>>>
>>>> Why don't you "userless admin shares" like proposed by Chuck?
>>> We missed this part. So to make sure we well understood, what is needed
>>> here is just an interface to create these shares? Then for the rest of
>>> the resources booking, we can do as we suggested but using the shares?
>>
>> Yes, that should work.
>>
>>> Where would you suggest the creation of these shares? In the
>>> Administration section?
>>
>> Yes.
>>
>>>> Specifying resources in the configuration seems too inflexible to
>>>> me. If
>>>> using shares you could attach real names, descriptions, resource
>>>> types etc.
>>>> to the resources.
>>>>
>>>> I don't quite understand the recurrence functionality yet.
>>> For recurrence we will ask the user to confirm his next booking. This is
>>> an optional feature. We wanted this feature because we saw that a
>>> meeting room is booked every week without being used at all occurences.
>>> So the resource will be booked for a specified time and a mail will be
>>> sent to the user. If he does not confirm before this specified time, the
>>> resource will be freed.
>>
>> I'm not really sure if I like this approach, but I can't come up with
>> anything smarter at the moment.
> 
> 
> Just to add my .02 here, I'd personally feel a little more comfortable
> with this approach if the 'confirmation email' is more of a gentle
> reminder to free the resource if it is not going to be used, instead of
> it automatically getting released if there is no confirmation.

Good point. Moreover it will ease our work.

- --
Stephane Pointu
Purple Labs S.A.
stephane.pointu at purplelabs.com
http://www.purplelabs.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGJ5EdWWLMt96bzSoRAlkgAJ91V0WtILGIcUlK0WyEqr2Mc1IvNwCfRARJ
I4oM89k1FTykJDWpvqOsu7U=
=sDbX
-----END PGP SIGNATURE-----