Jun 22 2021
I'd say it's the carddav plugin issue. Maybe it does not "inject" its addressbook sources on task=calendar requests or sth like that.
Feb 1 2021
Jan 28 2021
Jan 26 2021
Jan 22 2021
Removed the in-memory cache instead.
If you think that this internal cache is not really needed then go this way and remove use of self::$typedata. In rare cases when we list folders for all folder types separately in a single request, we'll end up with several requests to the Roundcube imap cache, instead of one. I'm afraid that we might call folder_typedata() or folder_type() methods quite a lot, but I didn't check that, so I'm not sure.
Jan 21 2021
How about we call self::folders_typedata($prefix); to populate the cache, but then user folder_type() anyways to fetch missing entries (it still uses the cache if available)?
With this change METADATA for every folder will be asked separately. This definitely will have performance implications. Maybe a better approach would be to add a method to reset kolab_storage::$typedata (and other cache-like data if needed). And call that method from syncroton's kolab_sync::sleep() or kolab_sync_backend_folder::hasHierarchyChanges().
Aug 25 2020
May 20 2020
This driver is not a high prio for us. Patches welcome.
Currently, the calendar uses the database backend:
The new_event method starts in database_driver and it starts _update_recurring. In this _update_recurring there is a calendar_recurrence object that creates Horde_Date_Recurrence on initialization where the problem is. :)
Yes, it using plugins/calendar/drivers/database/database_driver.php.
May 19 2020
Ok, I was testing a different case. However, this case also works with Kolab backend. I assume that you're using the database driver. Is it right?
Any info? :) Is there anything I can help you to resolve this bug ?
May 12 2020
Did attached screen help you repeat the error?
May 8 2020
I think that the screen from the application will explain the problem better :)
May 7 2020
It works for me with Kolab backend, although the event info dialog displays "Repeat: Every 1 month(s), forever ". When I edit the event Recurrence form looks correct and the event is displayed properly on the 3rd Thursday as defined. So, I see only a problem with the "Repeat" text not being complete.
Feb 10 2020
Jan 28 2020
Nov 13 2019
https://github.com/sabre-io/vobject/pull/476 fixes the issue for me.
Oct 4 2019
Fixed in d05e11f145cf.
Oct 1 2019
Sep 29 2019
Fixed in 3841f63fbd42 [roundcubemail master] and eee719e6d2f87 [roundcubemail-plugins-kolab master].
This issue is a bug in Roundcube sql cache, so is reproducible with $config['imap_cache'] = 'db' and of course only when using MySQL engine. No issue if it's set to memcache, redis or disabled.
I'm unable to reproduce on current git-master.
Sep 27 2019
Fixed in 1ddbb2bcaa1b2.
Fixed in b3b695b66d6d15.
Fixed in 58d9ed122718c.
Sep 25 2019
Fixed in ad33b48521d7.
Sep 12 2019
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.
Sep 11 2019
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.
Sep 10 2019
Could you provide the faulty preferences?
Sep 9 2019
In the meantime I got another issue - not with calendar but wit task plugin.
Aug 29 2019
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.