Hi Ben Luey
On 09/28/2011 06:56 PM, Ben Luey wrote: > I believe I have resource planning setup in my ldap and sogo config > correctly (Sogo 1.3.8b, tb 3.1, sogo plugins 3.105). I made > multiplebookings set to 1 for this resource. Below is the behavior I see > and I want to check if this is as expected: > > Thunderbird: > If user A creates an event and invites Resource B and B is available, B > accepted invitation. User A does not get notification that B accepted, > but the calendar event shows B has accepted. An email is sent to > resource B, which could be forwarded to some third party (for monitoring > the resource?). Yes, this forwarding is supposed to reach the "owner" of that resource. So she can override the automatic booking when necessary. > If user A creates an event and invites Resource B but B is unavailable, > then that conflict shows up in the freebusy, but if the user doesn't > notice or care, they can proceed without warning. When they try to save > the event, then get "An error has occurred" when they try to save the > event with the error message "MODIFICATION_FAILED" > > Sogo: > Same behavior a T-bird if there is no conflict > If there is a conflict and you happen to be in the invite attendees > page, you will get a warning about the conflict, but you can ignore it. > If you ignore the warning (or create a conflict by changing the time in > the main panel) then when you save the event, you get a popup saying > "Maximum number of simultenous bookings (1) reached for resource > Resource B". > > Is this normal? Yes, all four cases are the expected behaviour. > Is there a way to get T-bird to at least report a error > message that users can understand when they try to book a busy resource. The problem with Thunderbird is, that it doesn't have an appropriate error/warning message for this kind of situation. So in order to change this you have to change Thunderbird. AFAIK there is an enhancement bug report in mozillas bugtracker for this. (Sorry, don't have the number at the moment.) > Alternatively, having the event go through and an e-mail to the event > organizer saying that Resource B cannot accept would work as well. Nice idea, perhaps this should be a user configurable option. Kind regards, Christian Mack -- Christian Mack Gruppe Informationsdienste Rechenzentrum Universität Konstanz -- [email protected] https://inverse.ca/sogo/lists
