[kronolith] synchronization of the resource calendars

[Michael J Rubinsky]

Quoting Johannes Mock <mockjs at idmt.fraunhofer.de>:

> On 05/07/2014 03:53 PM, Michael J Rubinsky wrote:
>>
>> Quoting Johannes Mock <mockjs at idmt.fraunhofer.de>:
>>
>>> Hello together
>>>
>>> I have bind some resources to our kronolith server and made some tests.
>>>
>>> It was found that the resource calendars take a long time until they
>>> syncronize the input data of the appointments.
>>
>> Not sure what you mean by this. The resource's event is saved to the
>> resource's calendar during the same http request that saves the bound
>> event. In fact, the resource's event is actually committed to storage
>> before the bound event is saved.
> The usage of the resource is stored together with the appointments in
> the MySQL Database, but it may take a few minutes and repeated reloading
> until the data is displayed in the resource calendar (on the website).

If the the resource calendar (in fact, this is true for any calendar),  
is already displayed in the dynamic view any entries not explicitly  
added by the user using the GUI will not show up until the page is  
reloaded. I.e., Kronolith does not currently poll for new events in  
the background, though I believe there is an open enhancement request  
for this.

>>> Furthermore, resources remain saved in the appointments even if the
>>> resources were rejected for these appointments.
>>
>> Resources are handled just like attendees. If an attendee declines an
>> event, the attendee is not removed from the list of attendees. When an
>> event is saved, if a bound resource is going to decline, an alert
>> should be displayed indicating this before the event is allowed to be
>> saved, giving the user a chance to reschedule or select a different
>> resource.
> An alarm is displayed, but only after saving the appointment, and only a
> short moment. If the users do not realize this warning, it may lead to
> misleading double occupancy of a resource.

Not in Kronolith 4.2. This was enhanced to behave how I describe.  
I.e., it's a "hard stop" and the user cannot proceed until he/she  
makes an explicit choice as to how to handle the resource's rejection.


>>> If you have two appointments using the same resource at different times,
>>> for example: Appointment 1 uses the resource from 13:00 to 14:00 and
>>> Appointment 2 uses the same resource from 15:00 to 16:00 and you want to
>>> move Appointment 2 to 13:00 o'clock, in the resource calendar the
>>> resource further is blocked from 15:00 to 16:00.
>>
>> Not sure I follow. The resource should have rejected the move to 13:00
>> because there is a conflicting event.
> That's right. The resource usage reports, after saving the shifted
> appointment, a warning that the resource is already assigned.
> In the resource calendar the old time remains occupied, although these,
> after the shifting, has become free now. If someone now sets an
> appointment and want to use the resource from 15:00 to 16:00, he is told
> by a warning (after saving the appointment) that the resource is busy,
> which is not true.

I'll have to test this scenario again in 4.2 since the event would not  
have been allowed to have been saved until the user acknowledges the  
resource rejection. I.e., the event should not have been saved at that  
time slot, with that resource, since it would have rejected.


> If you delete an appointment, which uses one or more resources, the
> corresponding times in the resource calendars are deleted too, normally.
> Not so, at a appointment which as described above, shifted. The link
> between the appointment and the resource is lost in this case.

I'll look at this, as described above.


-- 
mike
The Horde Project
http://www.horde.org
https://www.facebook.com/hordeproject
https://www.twitter.com/hordeproject
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5869 bytes
Desc: S/MIME Signature
URL: <http://lists.horde.org/archives/kronolith/attachments/20140513/7c5254a1/attachment.bin>