Now wrong again :(

I removed from kolab.conf:
domain_base_dn = cn=kolab,cn=config

Webadmin log:
[14-Jul-2019 21:58:27 +0200](l7pijj1tobu030onu4m4qm5j86): [ERROR] (api) Command /usr/lib64/mozldap/ldapsearch returned error code: 32
[14-Jul-2019 21:58:27 +0200](l7pijj1tobu030onu4m4qm5j86): [ERROR] (api) Command /usr/lib64/mozldap/ldapsearch returned error code: 32
[14-Jul-2019 21:58:27 +0200](l7pijj1tobu030onu4m4qm5j86): [ERROR] (api) Command /usr/lib64/mozldap/ldapsearch returned error code: 32
[14-Jul-2019 21:58:27 +0200](l7pijj1tobu030onu4m4qm5j86): [ERROR] (api) Command /usr/lib64/mozldap/ldapsearch returned error code: 32
[14-Jul-2019 21:58:27 +0200](l7pijj1tobu030onu4m4qm5j86): [ERROR] (api) Command /usr/lib64/mozldap/ldapsearch returned error code: 32
[14-Jul-2019 21:58:27 +0200](l7pijj1tobu030onu4m4qm5j86): [ERROR] (api) Command /usr/lib64/mozldap/ldapsearch returned error code: 32

Running the linked sql script by hand fixed the problem. There is nothing in the logs to indicate why this change didn't take during the upgrade.

There was a significant change in the way kolab data is cached by Roundcube kolab plugins (roundcubemail-plugins-kolab package). There was supposed to be a DB structure update. Please, verify if this sql commands have been executed https://git.kolab.org/diffusion/RPK/browse/master/plugins/libkolab/SQL/mysql/2018122700.sql. Any errors in log?

Given the fact that 3 years passed prior to this change, that the KDE community had to create a fork of libkolab, and that openSUSE dropped the package due to lack of upstream maintenance, there is no point in keeping this task open.

I am up to date with the Ubuntu 18.04 repo. For what its worth it looks like this has actually been fixed. I no longer have trouble with calendar invites.

Confirmed with current version.

This can be configured in kolab.conf. For KolabNow create tickets there.

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

Strange. There's a new line after import re, so the error does not make sense. And no one complained about this, so looks like an issue with your system only. It's old, anyway.

This has been fixed in Roundcube 1.3.4/1.4-beta.

Not enough info. This is old.

If I understand this correctly toki.space is a domain space, FQDN should include hostname.

I see Obsoletes: php-Net-LDAP3 in the spec file, so I guess it's already fixed.

Not a problem in Kolab 16.

I guess this has been fixed as the proposed line already exists.

This depends on Cyrus configuration. The way how Kolab uses Cyrus IMAP does not allow for subfolders under INBOX.

No feedback.

I think this is about a known iOS/Safari bug where cursor is still visible even if the textarea/input is out of screen (page scrolled). I don't know if there are workarounds. Need investigation.

What version of roundcubemail-plugins-kolab? These lines with timezone info are irrelevant. Problem is with parsing some objects in calendar folder(s). You'll have to find the faulty object-message in the spool, or delete folder content. Without the faulty object data we'll not be able to help.

Fixed in 91e57e1f7367.

That information is a bit out-dated, please use https://copr.fedorainfracloud.org/coprs/kanarip/phabricator/

The documentation is outdated. You can find the repo at https://copr.fedorainfracloud.org/coprs/kanarip/phabricator/

Submitting patch for review blocked due to https://git.kolab.org/T5462

... not mentioning the fact that we still need PHP 5.4 support. So, it's complicated.

All other components (iRony, kolab plugins for Roundcube) depend on that version. So, we can't just switch to a new one.

Sorry but I wasn't at home . Your patch work for me too. In chwala composer.json has: "sabre/dav" : "~2.1.11" I'm not specially attached with this version :)

I pushed the the change I proposed above. I consider it fixed. Let me know if I'm wrong.

Could you confirm that this code works for you? I think it should work with SabreDAV 2.1 as well as any newer version.

$is_dir = !empty($props['{DAV:}resourcetype']) && count($props['{DAV:}resourcetype']->getValue()) > 0;

I'm trying to tell you that your patch is not acceptable because it does not work with Kolab's WebDAV server (and maybe others). From the debug you provided I see that it might be a Sabre compat. issue. For me it is different:

Sabre\DAV\Property\ResourceType::__set_state(array(
   'resourceType' => array (
      0 => '{DAV:}collection',
    ),
))

What version of SabreDAV do you have installed?

Since there is only one server active using owncloud i keep the patch as it is and it works.
I changed the line as follows, you can see what I log :
// $is_dir = in_array('{DAV:}collection', $props['{DAV:}resourcetype']->ResourceType);

$is_dir = isset( $props['{DAV:}resourcetype']);

However, I don't get it. Does that mean that OwnCloud returns set-but-empty DAV:resourcetype for folders? Could you provide sample owncloud response? Or, is commit d1342141be6 working for you?

Proposed solution does not work with Kolab's WebDAV implementation (iRony). However, indeed standard says that files have no contenttype, so I'm going to fix it anyway.

Yes, I can confirm that 0.8.13-0~kolab2 solves the problem. I suggest to close this issue.

On my system wallace has been updated to 0.8.13-0~kolab2 and restarts seem to work now. I'l have an eye on it. If other people can confirm the fix we can close the ticket.

Fixed in be2e3f21541 [roundcubemail master].