While I don't mean to discredit that work, a client is looking at
sponsoring that feature in SOGo. So if we reach an agreement, that
feature should be available for SOGo v1.3.7.
Regards,
On 11-03-07 6:37 PM, Ben wrote:
I've been working on taking Mohit's code for auto-accepting /
rejection calendar requests for use with resources and making it less
specific. Then idea is to have the script accept any requests that
don't conflict and reject any request that do. Right now, it grabs all
the events from the user's calendar and searches for any with the
status of NEEDS-ACTION. Then is determines yes or no and posts that.
I've added some documentation and removed the file queue and inotify
part of the original perl script.
I'm having one problem, which is probably very simple. If you have an
empty calendar, it works fine and changes the event status, etc. If
you have events in the calendar I believe it correctly identifies
which to accept and which to reject. However, when it tries to post
the changes it replaces every calendar entry with the first calendar
entry. So if you have Event1, Event2, Event3, you get Event1, Event1,
Event1. The ICS that is sent to SOGo is (should be?) the entire ICS
calendar, not just the changed event and I think that is part of the
problem, although from my reading of Mohit's original script that is
how it was done.
I haven't looked into recurring events yet. Also, probably because of
the bug mentioned above, I was able to rail the SOGo CPU once when
testing this, so be careful.
Any ideas and code suggestions, feature requests, etc welcome.
Ben
On 3/4/2011 1:22 PM, Mohit Chawla wrote:
Hi,
On Fri, Mar 4, 2011 at 11:54 PM, Ben
<[email protected]
<mailto:[email protected]>> wrote:
I was wondering how your perl interface for resource management
was working and if you'd be willing to share the code? I'd be
interested in testing / debuging / using it.
Here's how it works.
For the particular organization for which the solution was devised -
the criteria for resource booking is pretty simple - first come,
first serve.
So, keeping that in mind, the process involves calculating the
appropriate recurrence ( in case of recurring events ), breaking 'em
down and comparing for conflicts. Otherwise, a straightforward
affair. If there's a conflict, that particular user's event will be
rejected. Infinite events are rejected as well.
There are some great modules that perl provides which we use -
http://search.cpan.org/~alexmv/Data-ICal-0.16/
<http://search.cpan.org/%7Ealexmv/Data-ICal-0.16/> and
http://search.cpan.org/~simonw/Data-ICal-DateTime-0.7/
<http://search.cpan.org/%7Esimonw/Data-ICal-DateTime-0.7/>
Currently, the code is integrated with the email sub-system ( based
on qmail ). Also, the code can be made a lot efficient if I could use
object-oriented paradigms. But anyway I am attaching the particular
script.
You would probably want to avoid the email parts.
So, mainly there are two queues - the first reads off the iCal
objects and the other one puts a paticular mail in a separate queue (
$m_dirq ) .. .which you would avoid, unless in a similar situation.
Let me know of any problems - the script is quite specific - and
hasn't been generalized, so there might be a few things to watch out
for.
--
Ludovic Marcotte
[email protected] :: +1.514.755.3630 :: www.inverse.ca
Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence
(www.packetfence.org)
--
[email protected]
https://inverse.ca/sogo/lists
