[Kolab-devel] Wallace and Invitation Policies

[Thomas Brüderli]

Sergio Talens-Oliag wrote:
> El Tue, Jan 13, 2015 at 09:33:56AM +0100, Thomas Brüderli va escriure:
>> Hi Sergio
>>> I'm working on having a functioning Kolab 3.3 on a Debian server using
>>> dovecot 2.2.15 (with the upstream metadata support); I'm not using all the
>>> kolab tools, but what I need is almost working.
>>>
>>> To be able to use the invitation policies module of wallace I've added a
>>> dovecot driver to pykolab (it's a quick hack, to distribute it the pykolab
>>> imap drivers will need to be reviewed, as there are some assumptions on
>>> different places that should be on the cyrus driver but are on the general
>>> code, i. e. dovecot does not provide the same namespaces that cyrus does, but
>>> there are some checks that expect three namespaces).
>>>
>>> Anyway, my modified wallace is more or less working, but I have two problems
>>> right now:
>>>
>>> 1. If I set the invitation policy to 'ACT_SAVE_TO_CALENDAR' (on the LDAP user
>>> config or as the default policy) the iTip xml file is saved as a message on
>>> the default calendar mailbox, but it does not appear on the roundcube
>>> interface (if I use 'ACT_TENTATIVE' it is shown); is this a a bug on the
>>> roundcube module? if so, has it been detected already or should I send a bug?
>> The invitations appear in a dedicated calendar "Pending invitations" but
>> that needs to be enabled in config (/etc/roundcubemail/calendar.inc.php):
>>
>>   // show virtual invitation calendars (Kolab driver only)
>>   $config['kolab_invitation_calendars'] = true;
> 
> Thanks a lot, it works... ¿do you know how other modules handle the pending
> invitations? Will they be shown using webdav or activesync or they are simply
> ignored? 

That's up the client. iRony - the CalDAV component of Kolab - will list
them and for example Mac OS and iOS clients will show them as open
invitations. I can't say about Activesync though...

>> It's been made a configuration option because these virtual calendars
>> will remain empty if no according invitation policy is set and in such a
>> case just add to the confusion of users.
> 
> OK, I get it, probably is just a documentation problem
> 
>> FWIW: the list of valid values for the invitation policy configuration
>> are listed here:
>> http://docs.kolab.org/architecture-and-design/mta.html#wallace
> 
> Well, I looked at that page but it uses the names with the prefix ALL_ instead
> of ACT_ and it did nothing and I ended up looking at the code... ;)

Then maybe your packages are not fully up-to-date. The latest and
greatest source code is here:
http://git.kolab.org/pykolab/tree/wallace/module_invitationpolicy.py

The ACT_* values are still supported for backwards compatibility but
since we also support iTip invitations for Todos, the distinction
between EVENT_* and TASK_* became necessary.

>>> 2. I see that no notification is sent if wallace processes an iTip
>>> invitation... I would like to be able to receive the iTip message
>>> when wallace processes it (for ACT_SAVE_TO_CALENDAR it would be the original
>>> message and for ACT_ACCEPT* or ACT_TENTATIVE would be the updated iTip)...
>>> ¿should I modify wallace to do it or is there some other way of doing it?
>> The iTip message would be a copy of an event that was already added to
>> your calendar. When further processing it from the calendar view (e.g.
>> accept the invitation), we have no means to relate the updated event to
>> the iTip invitation message in your inbox.
> 
> Hmm, why not? If it is the same iTip won't both of them get the same ID?

The iTip message is just a regular email message just so happen to have
an attachment with an ical block. Unfortunately there's no IMAP SEARCH
command to easily find an iTip invitation by its UID. The only way would
be to iterate over all messages and look into the attachment contents...
not very sexy.

> I just tried and with the $config['kolab_invitation_calendars'] = true option
> I see a POSTPONE option on the iTip message and if I click on it the event it
> shows on the pending invitations and the mail message still allows me choose
> the option I want (ACCEPT, MAYBE or DECLINE) except the POSTPONE button (it is
> disabled now, which makes sense, as the iTip is already on the calendar)

True, but here we have a similar situation where the iTip message
remains in your Inbox even if you accept he invitation from within the
calendar. We're yet lacking a proper solution for this. That's also a
reason why the invitation calendar thing is disabled by default and more
of an experimental feature.

>> I understand the use case of getting a notification in your inbox about
>> new invitations but that's actually what iTip was meant for in first
>> place. Using EVENT_SAVE_TO_FOLDER basically disables the regular iTip
>> process.
> 
> Well, I've applied the attached patch to my instalation and the behaviour is
> the one I wanted using the policy ACT_SAVE_AND_FORWARD... if it does not break
> anything else could this or a similar patch be applied upstream? 

We'd be happy to receive that patch for review, yes.

Best,
Thomas