We are also affected.
Jul 5 2019
Confirmed with current version.
Confirmed with current git-master. On export event recurrence is not resolved to match the date filter.
Jun 11 2019
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
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.
Jun 10 2019
The issue persist for me:
Jun 7 2019
May 31 2019
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.
May 30 2019
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.
Scan all downloaded apps & Files and remove malicious content, Remove All virus from the Document Application. You can visit the all Social Sites in keep and cool in mind because you have the paid Antivirus. You are Secure from the Virus. You save all type of the data personal information. Antivirus Scan website for harmful threats. If a suspicious URL IS DETECTED if you are facing the issue in your paid Avg Antivirus take the help from [[ https://www.glstechserve.com/avg-technical-support/
|Avg Helpline Number ]]-1877-269-4999|
May 29 2019
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.
May 27 2019
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?
May 22 2019
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.
May 21 2019
Hi, thanks for the update.
Bugs logged there are not considered here, they need to be logged here.
May 20 2019
Apr 13 2019
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.
Apr 12 2019
$config['fileapi_sources'] = array( 'Seafile' => array( 'driver' => 'seafile', 'host' => 'seacloud.cc', // when username is set to '%u' current user name and password // will be used to authenticate to this storage source 'username' => '%u', ) ); // You can also add $config['fileapi_backend_storage_disabled'] = true;
Okay I’ll take a look on it later. I guess it’s this part:
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?