Tue, May 21
Mon, May 20
This should be fixed with the latest update.
Sun, May 19
Oh dear. Thanks for pinpointing the problem!
I've pushed out an urgent hotfix; updated packages should be available in a few minutes.
Sat, May 18
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:"
Fri, May 17
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.
Fri, May 10
Thu, May 9
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?
Apr 11 2019
Apr 4 2019
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:
Mar 31 2019
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
Mar 28 2019
What do you expect to happen when an invitation is created, and 'email@example.com' is invited?
Mar 27 2019
I'm sorry, this is an incomplete set of steps to reproduce on an by-now-out-dated version of pykolab/wallace.
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?