The problem can be reproduced on CentoOS, and Ubuntu as well. There is no matter which distro is used and I’m sure that every current build is affected.

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.

My python is Python 2.7.13 from the debian packages:

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.

No such issue on CentOS with wallace-0.8.11-7.1.el7.kolab_16.

I've tried reading the wallace source but didn't see an easy fix. For now I use a cron job
with the following script to fix wallace up:

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.

Fixed in 668ca02c3f3d8 [roundcubemail master].

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.

Confirmed. If I then try to start wallace, I got:

2019-05-29 11:36:24,741 pykolab.wallace WARNING [10320] Could not bind to socket on port 10026 on bind address localhost
2019-05-29 11:36:24,741 pykolab.wallace WARNING [10320] Could not shut down socket
2019-05-29 11:36:25,743 pykolab.wallace WARNING [10320] Could not shut down socket
2019-05-29 11:36:26,745 pykolab.wallace WARNING [10320] Could not shut down socket
2019-05-29 11:36:27,747 pykolab.wallace WARNING [10320] Could not shut down socket
2019-05-29 11:36:28,750 pykolab.wallace WARNING [10320] Could not shut down socket
...

and

# ps ax | grep wallace
 3595 ?        S      0:00 /usr/bin/python /usr/sbin/wallaced -l warning --fork --user kolab
10320 ?        Sl     0:00 /usr/bin/python /usr/sbin/wallaced -l warning --fork --user kolab
10321 ?        S      0:00 /usr/bin/python /usr/sbin/wallaced -l warning --fork --user kolab
10322 ?        S      0:00 /usr/bin/python /usr/sbin/wallaced -l warning --fork --user kolab
10323 ?        S      0:00 /usr/bin/python /usr/sbin/wallaced -l warning --fork --user kolab
10324 ?        S      0:00 /usr/bin/python /usr/sbin/wallaced -l warning --fork --user kolab

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 didn't check that on Debian 8, but a few notes:

1. It's not an issue on Debian 9 indeed.
2. Roundcube will not fallback to any other method if it is configured to use pspell.

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 confirm. This is for the Kolab skin based on Larry. Looks like it is caused by some style in Larry. The responsive skin has no such issue.

I'm the person behind kolabops, and also @vanmeeuwen, but if you have issues/questions/comments with regards to Kolab Now, would you mind submitting an email to support@kolabnow.com?

Excuse poor assumptive assigningetiquette but could I ask @vanmeeuwen how this should be assigned?

Excuse poor etiquette but could I ask @vanmeeuwen where this should be assigned? I follow you (kolabops) on Twitter so presume you have most to do with Kolab Now

When i change the timezone in user preferences on roundcube, from "auto" to "GMT (+00:00) UTC" the invitation is displayed correct.

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?

This should be fixed with the latest update.

Oh dear. Thanks for pinpointing the problem!
I've pushed out an urgent hotfix; updated packages should be available in a few minutes.

hi,
had the same problem. It's on line 1287 in the script kolab_smtp_access_policy.py:
replace "if cache is notTrue:" with "if cache is not True:"

I can confirm this.
This was working fine. Some update changed the situation.
Most users cannot create new events in their calendar. one however still can.
This is in roundcube. Event creation via caldav is not affected.

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?

Apologies that this has taken some time to post, I found the solution earlier today but was investigating other issues too. The patch is to add, on line 133:

user_attrs['surname'] = user_attrs['surname'].replace(r"'", r"\'")

Moving priority back to needs triage, I had caused a second fault during my investigation with a stray vim command. The above code alters the message to:

Ignore this post, I am keeping it here as it was a clue to the final solution:

Updated /etc/php.ini and moved the "date.timezone = America/New_York" setting to it's correct position under MODULE settings > "Date > ; http://php.net/date.timezone".
It had been entered under MODULE settings > Date > "; http://php.net/date.sunset-zenith" erroneously.
After saving the edit, I restarted, httpd and timestamps started showing up properly.

vanmeeuwen. - Time stamp is there in source and timezone is correct: Mon, 25 Mar 2019 23:53:00 -0400

What do you expect to happen when an invitation is created, and 'group@example.org' is invited?

I'm sorry, this is an incomplete set of steps to reproduce on an by-now-out-dated version of pykolab/wallace.

Resolved in https://obs.kolabsys.com/package/rdiff/Kolab:Winterfell/roundcubemail?linkrev=base&rev=158

This ticket is both old, as well as appears to be out-dated, in the sense that further updates to guam have been made available that also, supposedly, work, and was originally reported by an employee for another one of our then-employees to address.

While OwnCloud nor NextCloud WebDAV currently establish a priority for us, WebDAV more generally would.

Inconvenient at best for the moment, but certainly a risk going forward.

Check Roundcube error log. It might be caused by invalid/missing timezone setting in php.ini.

Viewing "details" and perhaps even the mail headers, is there a Date header that you see in the sources of the email?

Yes, I did import a calendar more than a year ago but have since deleted it.

It'll resolve itself once a package is built in Winterfell.

Still having the same issue with my Debian Stretch system - but I'm using Winterfell:

Such would be a request for enhancement we're unlikely to entertain.

Many thanks vanmeeuwen and sicherha for your efforts.

Hello vanmeeuwen,

I installed Win10 (User-Agent: MSFT-WIN-3/10.0.17763) and it works for me. I see some problem when the folders limit is set, but this is not default. Check in config.inc.php if you have config['activesync_max_folders'] = 5;. If so, bump the number to 10.

That's like reading the PIN off of the ATM card.