I applied the fix into Kolab Winterfell installation, and I still see "infinite" processing loop with the same traceback. I restarted wallace and kolabd.

I think I know why we don't use kolab.calendaring to parse iTip data. It's because it does not support VTODO. Grrrr... Lets start from the beginning...

From what I see iTip attachments are parsed using iCalendar. From what I see we could fix this issue by using kolab.calendaring instead. This is quite a big change, but I'm working on this, I've got a few unit tests failing. If there was any reason to not use kolab.calendaring please speak now.

My "it should" should be verified with Jeroen ;)

It was already fixed in master, but not in release-1.1. Done in 8e2fdee671.

The field has autocompletion feature implemented. So, should give you search results while typing. I know some people prefer addressbook widget, that's why we have it in mail compose screen.

It was committed to -3.2 in rRPKa9f51f2d4d0e69c9

I always do this. I just skipped it in comment as the customer is interested in KE14 now. 073961a1b66076f10b

I missed that we actually can't get specific folder type of other user folder because it is stored in a private folder annotation. I don't really like the idea of recognizing folders by their name, which as I understand, you propose.

=?iso-8859-15?Q?Stellenausschreibung-=C4nderung:_16-2509-075, IT@M, A10/E9_TV=F6D?=

This is not a valid header value according to RFC2047. Encoded-word can't contain spaces. What client created this?

It is not possible at the moment. Note that in IMAP it is possible to have many shared and other users namespaces. So, it might be problematic in such environments. However, maybe we could assume we have only one of each in Kolab. Still, replacing the namespace name with localized label in all places, may be not a simple task.

Well, what is special for one user don't have to be for the other. I could agree with an icon change, but not label.

"the implementation" here is cyrus.

To disable Settings section of the UI I propose to set:

$config['kolab_auth_admin_rights'] = array(
    'settings' => 'entry:delete',
    '*' => 'entry:read',
);

Note that with this LDAP effective rights will be used and kolab_auth_group/kolab_auth_role_value will be ignored. You can also change 'entry:delete' to 'attrib:kolabDelegate:write' (or use some other attribute).

Shared folders are handled differently. We've been there. See find_folder_resource() in line 192.

Created a patch. This is untested and it's not my decision if it is proper aproach.

As discussed with Jeroen REJECT does not make much sense for resources. So, I don't see anything in the code that would need to be fixed now. Consider updating documentation to be more precise.

Returning to the original question. No, it is not possible to prevent this with configuration. So, you have to investigate why a mailbox exists for alias attribute in the first place.

Ehh. So, different value for immediate? What values?

Confirmed. I tried SASL proxy authentication here, but didn't work for me. @vanmeeuwen is additional "service user" (i.e. new config options for DN and password) the only solution?

As I understand setting kolabinvitationpolisy: ALL_REJECT for resources does not work as for users, i.e. does not respond with Declined status.

In rPd71e26c1a we added 10 second timeout (OPT_TIMEOUT option). I'm curious if we shouldn't use OPT_NETWORK_TIMEOUT and/or greater OPT_TIMEOUT value. Jeroen, what was your intention?

sync-mailhost-attr uses auth.find_folder_resource() and auth.find_recipient() methods which indeed use attributes defined in mail_attributes. Sync command uses hardcoded 'mail' attribute, so I suppose we should use 'mail' only here too.

Automatic merge failed for me, so I applied the change manually in cd60b2b37730.

Yes, ACT_MANUAL is an alias for ALL_MANUAL in invitationpolicy module, but as I've said resources module supports only three policies. We should probably add support for ALL_* aliases, but adding support for all policies supported by invitationpolicy module would not be just a simple fix. That's why I'd like Architecture & Design to take a look at this.

Fixed allDay event availability finding

As for the resources, in the code I see this module support only three policies: ACT_MANUAL, ACT_ACCEPT and ACT_ACCEPT_AND_NOTIFY

Works for me on KE14 (pykolab 0.7.28). What policy do you have in kolab.conf?

It was also backported to release-1.1 as 7a73635214d on Feb 22.

Kolab-way of storing resource properties is to use kolabDescAttribute in LDAP. This field is supposed to contain JSON object with resource properties. We could add there e.g. "physical_location: true" there and use it in Calendar. The calendar plugin already supports that.

I was able to fix the issue on moving/resizing the event, but I wasn't able to reproduce the issue on event delete. I'm closing the ticket now. Please, reopen if the issue still exist after aplying my change.

Ok, more testing. I see now where the problem is. I think I misunderstood the problem description as there was no word "delegation" ;)

Could you try if dropping policy_result table in kolab database fixes the issue. The table will be re-created automatically.

I'm not able to reproduce the notification issue. I.e. when I delete or move or edit such an event iTip notifications are not being send. Which would mean that the only problem really is misleading wording of the warning text.

Fixed display issue.