this is the problem. It's not reproducable at all. Nearly all of our users can do all the stuff. Only very few encounter these problems. So maybe it's a caching issue - and the settings are not repsponsible but special settings together with some special circumstances in caching.

I'm unable to reproduce any of these issues.

Here are the preferences which cause the error. I have shortened the folder list for privacy reasons. But I think it doesn't cause the error.

Could you provide the faulty preferences?

In the meantime I got another issue - not with calendar but wit task plugin.

In rPNL9992f6627cc24793f033c48564bd9b2583c80617#506292, @machniak wrote:

This might be a big BC break.

In T1141#17069, @machniak wrote:

This scenario is not possible at the moment and because SeaFile has it's own WebDAV service I'm not sure there's a need to use iRony for that. You can configure iRony to provide CalDAV and CardDAV only if needed.

This might be a big BC break.

Duplicate of T1141.

• Fix typo

• No need to pass in the type id

• Further changes after feedback from @machniak

• Adjust some of the ACLs for hosted domains

• Enable either standard or hosted but not both

Taking over for the exactification of the ACLs

In my case it was sufficiant to switch from German to English date format and back. Then it's possible to save events but the pop up window doen't close. It remains but without content.

For those useres affected, we could fix the problem by setting the roundcube standard date format from the German to the Englisch version. Then the save button works again. Nevertheless, those users, who did not have this problem, continue to use the German date format setting without a problem. All this on the same server and same domain.

This is supposed to be fixed with https://git.kolab.org/rPNLd6718d6d1de66ed799e8140ab1eca9cdeee4e399.

There's already "More" label in Roundcube core. So, you can just use 'more' instead of 'calendar.tabmore' in the template.

We are also affected.

• Clear as many of the lint issues as we can

I first needed to understand that the mozldap ldapsearch is only necessary for getting the effective rights. Reading and modifying the objects is done by php. While the php ldap libs use the system wide certificate storage the mozldap doesn't. So modifying wouldn't be the problem but kolab webadmin isn't able to get the aci rights for the ldap objects.

We'll discuss the removal of this field in Bern