[Kolab-devel] Wallace and Invitation Policies

[Sergio Talens-Oliag]

El Tue, Jan 13, 2015 at 11:15:22AM +0100, Thomas Brüderli va escriure:
> >>   // 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...

OK, I'll look into other clients, but it looks promissing ... ;)

> >> 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

I'm working against the latest 3.3 packages for Debian, I wasn't planning to
do development, the plan was to use the stable versions, but I can work with
the development packages in my test machine (I assume that they are based on
the latest code, are they?)

> 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.

Ok, I see, I will change the policies once I deploy the newer versions ... are
there any estimated dates for the next stable release? I can try the
development version but for deployment I'll prefer to use the latest official
stable releases...  ;)

> >>> 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.

But it is doing it right now... I've looked at the Calendar's messages and
their subject is the iTip's UID, so it is easy to find them, or at least it
looks like it is.

> > 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.

In my installation roundcube shows the updated state of the invitation when
you open the message, so I don't see a big problem here... maybe with other
clients is a problem, but as long as the calendar has the right contents and
the events are not duplicated it is OK for me... maybe I'm missing something
else, I'll do more testing and see.

> >> 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.

OK, then I'll patch and test the latest wallace version and once it works I
will send an issue to the wallace component of the bugzilla's pykolab product.

Greetings,

  Sergio.

-- 
Sergio Talens-Oliag <sto at iti.es>               <http://www.iti.es/>
Key fingerprint = FF77 A16B 9D09 FC7B 6656 CFAD 261D E19A 578A 36F2