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.

Hi, thanks for the update.

Bugs logged there are not considered here, they need to be logged here.

I think we'd need a change around https://git.kolab.org/diffusion/C/browse/master/lib/api/common.php$237, but I didn't think about it yet.

I did some debugging in the seafile_file_storage class.

Okay I’ll take a look on it later. I guess it’s this part:
https://git.kolab.org/diffusion/C/browse/master/lib/drivers/seafile/seafile_file_storage.php$918

That scenario is not supported because you can't store config and you can't use cache without kolab backend. You could probably live without these in some setups, so yes in theory it should work. There must be a bug somewhere.

Hmmm But in theory it could work. I get the list of repositories. Chwala works correctly and lists all folders. Just kolab_files doesn’t get over it and doesn’t request the subfolders of each repo which is presented. BTW the files on the roots of each repo are shown as well.

... and we should throw an error when fileapi_backend != 'kolab'.

I think we should finally remove that section from documentation. It is not supported scenario, I think it is not even supposed to work. There's a comment in sample config:

// Main files source, backend driver which handles
// authentication and configuration of Chwala
// Note: Currently only 'kolab' is supported
$config['fileapi_backend'] = 'kolab';

Basically exactly like described in the howto: https://docs.kolab.org/howtos/use-seafile-with-chwala.html?highlight=seafile#using-seafile-as-an-exclusive-storage-mechanism

Yes, kolab_files uses now different (semi-recurrent) logic to fetch folders hierarchy. How exactly did you configure chwala with seafile?

Please do consider taking this to whatever the appropriate priority actually is, or however else you keep it off my radar until such time there's some meaningful involvement on my part ;-)

Correcting the priority from 60/40 to Normal

This ticket is no longer relevant.

This seems like low-priority aesthetics to me more so than an actual problem.

We do not actively support the database backend driver, so please bear in mind this has a very low priority for us.

Fixed in cbd1c1ae47b9.

The issue is fixed in dev/fullcalendar-upgrade branch. It will be merged soon.

In T4776#68850, @machniak wrote:

Unfortunately an update is not trivial.