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.

Fixed in d05e11f145cf.

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.

Fixed in 1ddbb2bcaa1b2.

Fixed in b3b695b66d6d15.

Fixed in 58d9ed122718c.

Fixed in ad33b48521d7.

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

We are also affected.

Confirmed with current version.

Confirmed with current git-master. On export event recurrence is not resolved to match the date filter.

In T5414#79973, @machniak wrote:

This version does not work with Roundcube 1.3.

This version does not work with Roundcube 1.3.

with this version, i got error 500 to open calendar UI:

with the repo
git clone https://git.kolab.org/diffusion/RPK/roundcubemail-plugins-kolab.git

Indeed, using today's master from roundcube is working fine
Calendar:

You're using the outdated fork repo. The official one is here https://git.kolab.org/diffusion/RPK/repository/master/

these versions may require Roundcube from git-master.

The issue persist for me:

Fixed.

I'm reopening this as there are more related issues. E.g. the Check Calendar button points to the wrong date.

This was hard to track, but fixed.

This is working out of the box, but requires long-press. After a long press you can move the event. After a long press event also a handle to resize the event appears, so you can also resize the event.

I don't think we can control that with current design. For me scrolling in the dialog is consistent. Problems start when a virtual keyboard appears.

exactly, this bug only occur in "all day" events.

The date and time format under Settings in Roundcube can be identical between user that have this problem and user that don't. At least at this level that does not seem to make a difference.

What is the user date and time format? You could also check what are the input arguments to parseDate() in line 169 of libcalendaring.js file. Just add console.log(this.datepicker_settings.dateFormat, date, this.datepicker_settings) a line before.

I think I saw this before, but never had time to work on this. Probably the date is handled as date-time and converted to user timezone, but should not for all-day events.

I don't see it on current beta.kolabnow.com withiPone SE iOS 12.1.4. Could you re-test and provide screenshot if it's still an issue?

The package was created by Thomas, but it looks he's not interested in working on this currently (or just have no time). Problem is that current calendar plugin version will probably not work with Roundcube 1.3. It also requires some manual packaging work for Elastic skin support. Also there are some known issues in the database driver noone have time to work on. From Kolab perspective we could spend that time better on other things. Maybe after the final 1.4.0 release I'll do something about the situation, but I can't promise anything.

They are not maintained and they were never supported by Kolab.

It is a "fork" that we do not manage.