[Kolab-devel] Wallace and Invitation Policies

[Sergio Talens-Oliag]

El Tue, Jan 13, 2015 at 01:57:56PM +0100, Thomas Brüderli va escriure:
> > 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.
> 
> Please don't confuse calendar objects being stored as Mime messages in
> IMAP with the actual iTip invitation messages received via SMTP. The
> latter one doesn't have the UID in the subject but whatever the sending
> calendar agent has put there and thus is hard to locate.
> 
> And even worse: it could be moved to any folder either manually or by a
> sieve script. So ultimately we'd need to search all folders for it.

Ok, but that is only if we need to do something with the email message, if the
policy is to leave the invitation messages alone it does not matter where they
are, am I right?

> > 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.
> 
> Yes, the status is updated once you look at the invitation message
> again. But I was talking about locating and removing the invitation
> message from the Inbox once accepted. We'd like to apply the behavior
> configured in the 'calendar_itip_after_action' option, also when an
> invitation is accepted/rejected from the calendar view. This is
> currently not possible. When accepting an iTip invitation from the mail
> view, we have the context of the iTip message and therefore we can apply
> the configured action (e.g. move to trash).

Now I see the problem, but if the user chooses to save and forward the
invitations we can tell him or her that the 'calendar_itip_after_action' will
be ignored if the event is accepted from the calendar (if we do it from the
mail it will work as expected) or we can try to check the
'calendar_itip_after_action' value from wallaced and do the right thing when
we receive the message (in that case the invitation will only be available
from the calendar if the 'calendar_itip_after_action' policy implies a message
removal).

I don't know if there is a clean way to get a users' roundcube setting from
wallaced, but if there is a way to do it we can perform the desired action when
wallace processes the message depending on the user defined value:

- if it is '0' (do nothing) we forward the message

- if it is '1','2' or '3' (move to Trash, delete the message or flag as
  delete) we don't forward the message (if the user has those settings I see
  no point on copying the message to the Trash or setting the deleted flag, if
  the invitation is already processed we can remove it directly)

- if it is a 'folder_name' we store the message directly on the named imap
  folder from wallaced, as the mail client would do.

Just my 2 cent., I see that it is not an easy problem to solve, but I prefer
to be able to set the SAVE_AND_FORWARD option with a bad
'calendar_itip_after_action' processing than not having it (in fact, if a user
accepts the invitation from a client that does not have the
'calendar_itip_after_action', i. e. an iOS client that uses CalDAV, I imagine
that the outcome is the same as in our case, isn't it?).

I'll prepare the patch and submit it for your consideration in any case.

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