In my case: the kolab was used as backend, the backend storage was disabled and an additional pre-defined source to a seafile server was configured. In the kolab_files folder list the Imap Files Folder always showed up, but couldn't be selected because the backend storage was disabled. This was confusing. When deleted it always got recreated, ether through the autocreate_folders section or kolab_folders plugin.

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.

• fix error message by showing which template file was not found
• Move find_template function to utils as there is a plan to use it elsewhere.
• Changes to setup-kolab mta utility to support AD. Postfix LDAP lookup tables are now created using Jinja2 templates.
• Log clamav updates to /var/log/freshclam.log file. Don't want to create a dir.
• Jinja2 templates for Postfix and Amavisd configuration.

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?

That's a bug introduced by e544905221b and the fix makes sense.

@bohlender, would you make a summary in English for me, or should I just ignore all comments?

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:

• Don't need this log.
• Fail immediatly if connection to LDAP server could not be made
• Get supported ldap controls and match with what is supported by pykolab

• Use python UUID to convert binary objectGUID to string. It doesn't look like value of uniqueid returned by from cache is used anywhere (needs to double check), so only forward conversion is needed.

• Use python UUID to convert binary objectGUID to string. It doesn't look like value of uniqueid returned by from cache is used anywhere (needs to double check), so only forward conversion is needed.
• Also do not strip anything from bytestring attributes (objectGUID) because after stripping conversion to UUID string is not possible.

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

Kind of finished version of Pykolab way of Active Directory setup:

• For AD LDAP modification I decided to use Jinja2 templates, which are in templates folder. Several reasons for that:
  • Long texts of changes to be performed in python code does not look nice, especially when AD Kolab schema needs to be added.
  • Ansible uses Jinja2 for templates, so templates used by setup_ldap.py can be reused with Ansible.
  • It becomes easier to load additional data to LDAP (like data to for testing purposes) or setup OpenLDAP for use with Kolab.

Using Jinja2 creates python-jinja2 package dependency
TODO - Need to decide where Jinja2 templates should be installed. Currently /etc/kolab/templates/, /usr/share/kolab/templates/ and os.path.join(__file__, '..', '..', '..', 'share', 'templates' paths are used to find templates.

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