Fixed in https://git.kolab.org/rRPKed50d5fc5855dae0c32c1109fbabb0554310f05e.

I would agree, probably not the right patch (Just provided it as it's what we do to make it work, just carrying the patch internally)

Fixed.

Packaged and released in 1.5.4.11

Duplicate of T6688.

Works for me.

Thanks for the reply! By looking further into the problem the issue seems to depend on the roundcube version, we will get back here if we still need help or close this task...

Which readme? used repository? OS version, installed package version?
Some more information to help accordingly is appreciated.
So help could only be in general, with some information and more manuals to read.

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.

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.

In D2143#24421, @machniak wrote:

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

I don't like it for performance reasons, because if we know the folder has no type then why would you bother with a METADATA request? This would create many redundant requests when listing mail folders. And I'm not sure it would solve your issue.

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

In D2143#24409, @machniak wrote:

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

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

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.

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 ?

Did attached screen help you repeat the error?

I think that the screen from the application will explain the problem better :)

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.

https://github.com/sabre-io/vobject/pull/476 fixes the issue for me.