Re: [Kolab-devel] Wallace and Invitation Policies

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? 

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

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

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)

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

Thanks in advance,

  Sergio.

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

_______________________________________________
devel mailing list
[email protected]
https://lists.kolab.org/mailman/listinfo/devel

--- /usr/share/pyshared/wallace/module_invitationpolicy.py.orig	2014-09-15 13:35:38.000000000 +0200
+++ /usr/share/pyshared/wallace/module_invitationpolicy.py	2015-01-12 20:38:09.916220384 +0100
@@ -65,6 +65,8 @@
 ACT_REJECT_IF_CONFLICT       = ACT_REJECT + COND_IF_CONFLICT
 ACT_UPDATE_AND_NOTIFY        = ACT_UPDATE + COND_NOTIFY
 ACT_SAVE_TO_CALENDAR         = 512
+ACT_FORWARD                  = 1024
+ACT_SAVE_AND_FORWARD         = ACT_SAVE_TO_CALENDAR + ACT_FORWARD
 
 FOLDER_TYPE_ANNOTATION = '/vendor/kolab/folder-type'
 
@@ -83,7 +85,9 @@
     'ACT_REJECT_IF_CONFLICT':       ACT_REJECT_IF_CONFLICT,
     'ACT_UPDATE':                   ACT_UPDATE,
     'ACT_UPDATE_AND_NOTIFY':        ACT_UPDATE_AND_NOTIFY,
-    'ACT_SAVE_TO_CALENDAR':         ACT_SAVE_TO_CALENDAR
+    'ACT_SAVE_TO_CALENDAR':         ACT_SAVE_TO_CALENDAR,
+    'ACT_FORWARD':                  ACT_FORWARD,
+    'ACT_SAVE_AND_FORWARD':         ACT_SAVE_AND_FORWARD,
 }
 
 policy_value_map = dict([(v, k) for (k, v) in policy_name_map.iteritems()])
@@ -398,9 +402,12 @@
             delete_event(existing)
 
         if not nonpart or existing:
-            # save new copy from iTip
+            # save new copy from iTip & forward the iTip or stop working
             if store_event(itip_event['xml'], receiving_user, targetfolder):
-                return MESSAGE_PROCESSED
+                if policy & ACT_FORWARD:
+                    return MESSAGE_FORWARD
+                else:
+                    return MESSAGE_PROCESSED
 
     return None