Are there any news concerning this ticket? Is there a solution for full folder support with Android? Thanks.

As nobody can reproduce this (also not ESG) we close this task

Version:

We have a separate ticket for this issue now - T1607.

Centos 7.2/64 on a fresh system install shows same stack but different exception message, i.e. that /usr/bin/freshclam is not present in the system.
The kolab package should probably have a dependency on clamav-update?

To make sure everything started from scratch I just reinstall CentOS again and during kolab-setup it crashes at the same point . Did check setup_mta.py file before setup-kolab and it's patched .

D238 fixes this.

Hi, same Problem here with a fresh installation of CentOS Linux release 7.2.1511 (Core)...

BTW, the libcalendaring package is not the same as libcalendaring plugin.

In T1523#25021, @machniak wrote:

In T1523#25018, @greve wrote:

Hasn't the choice which calendar to store something into upon acceptance been a feature request recently? So then the user could always choose where to store a new event, and that would default to their private calendar.

User has this possibility if the event wasn't found, but we check only personal folders. Otherwise "Save in..." is not displayed.

Noted!

Due to already created online trainings needed to withdraw the better fitting translations of "on date" and "on dates" back to an earlier translation version with "genau am" for both.

Noted!

In T1523#25018, @greve wrote:

Hasn't the choice which calendar to store something into upon acceptance been a feature request recently? So then the user could always choose where to store a new event, and that would default to their private calendar.

In T1523#24982, @machniak wrote:

Privileges to shared folders are managed by admins.

Privileges to shared folders are managed by admins. Users have no way to make sure delegatee has access to a shared folder. User probably should not care much about this.

We made some more tests today and find the following on folders for android:

Since I have currently no chance to retest this (security guys closed public access, so mobile devices have no access at the moment), here all I have on cyrus log of the date-time where the folder creation problem happend:

We are still unable to reproduce this.

In T1523#24832, @machniak wrote:

1. Consider a situation in which User A delegated his calendar to User B. Now, if User B will try to handle such itip reply in the name of User A, he will encounter a problem. User B has no information about which shared folders User B has access to. So, this may work if both have access to this shared folder, but what if not?

This is problematic with Kolab delegation concept.

I meant to say resolved, because this part is indeed just that. I'm working on the SSH URIs right now.

This has escalated to our internal ticket tracking system as Ticket 1583 at priority high. I'm working on it.

I found another issue in invitation acceptation related to the fact that there's more than one delegation involved here. It causes that if Carol accepts invitation in the name of Bob it is not saved to Bob's calendar, but Alice's copy of the event is updated.

I confirm this partially. "Remove from my calendar" button indeed removes the event from Carol's folder not from Bob's. So, step 8. is confirmed. However, I do not confirm missing CANCEL notification to Carol. The mail is being sent for me.

Installed Packages
pykolab.noarch
0.7.28-1.1.el6.kolab_14

Anyway, I see this label is indeed not translated in de.po and de_DE.po localization files.

This label comes from pykolab. What version of pykolab are you using?

I agree, looks like a cyrus ACL problem.
The first MOVE "<f78gclud>" results in a "COPYUID" but needs to be rejected as the second one "<04c9c116>" is/was.

Still not translated with the latest package:
roundcubemail 1.1.5.21-1.1.el6.kolab_14

Ok, a lot of information, but I think the only relevant part is:

[2016-Sep-22 10:29:13 +0200]: <f78gclud> [FD9C] C: A0005 UID MOVE 1 Trash
[2016-Sep-22 10:29:13 +0200]: <f78gclud> [FD9C] S: A0005 OK [COPYUID 1474531118 1] Completed

and

[2016-Sep-22 10:35:56 +0200]: <o4c9cll6> [78D8] C: A0005 UID MOVE 3 Trash
[2016-Sep-22 10:35:56 +0200]: <o4c9cll6> [78D8] S: A0005 NO Permission denied

It's hard to say which one is for which user, but as you can see once it says permission denied and once it looks like a success. I don't see a log for the case when users have read&delete permissions.

OTRS: 1100112

I just changed the layout to more "code" blocks because else the format of 1-10 lists was scrambled.
I'll provide additional info some later today.

So, we have an iTip reply, and we want to update the resource status from it (manually). Right? That would be true, as in such cases we look into personal folders only.
The same issue will be in automatic itip handling in wallace. It also looks only into personal folders. Actually you can find "# TODO: list shared folders the user has write privileges ?" comment in wallace code.

Could you make sure User2 and User3 both use the same settings in Preferences > Server Settings. Provide what settings do you have there. Also, get the imap_debug log to see exactly what IMAP commands are used on delete.

Fixed in 008f310f3a62 and Transifex. (de_CH was correct)

OK, it was wrong that 3a. was wrong. The relevant time was just not in focus.

Adding the "kolab_auth_admin_rights" enables everybody to use/login/enter roundcube as an other user and disables any other restriction made before.
So the mentioned configuration will just open the functuionality to everyone and not restrict anything. If thsi is as you say a config issue, than please tell me where I can find the documentation of any of those helpdesk things to be configured with all the opetions and coincidents they have.

I will close this for now - Please feel free to reopen if there are still issues related to this.

This is definitely fixed in git https://github.com/roundcube/roundcubemail/commit/8e2fdee671dfba04cb5b36c30327724244663dbb. So, it's a packaging issue?

Folder subtype annotation is stored in private namespace, you do not have access to it. Also, Archive has no folder annotation in Kolab. So, we can't use folder annotations.

Still not translated with the latest package:
roundcubemail 1.1.5.21-1.1.el6.kolab_14

No I didn't think about recognizing it by name but thought about getting the annotations.
If you say that's impossible to find out if a folder of another user is by anotation his drafts folder and should be mapped to "Entwürfe" in my german RoundCube Interface because that's what's configured in Settings->Settings->Special folders.
This is relevant especially for languages which are not so popular as english is.
I would have a real problem to find out which of the french terms means "Entwürfe" but it would be possible to map that via the annotation becaus those are lang independent.

In T1427#23090, @machniak wrote:

It is not possible at the moment. Note that in IMAP it is possible to have many shared and other users namespaces. So, it might be problematic in such environments. However, maybe we could assume we have only one of each in Kolab. Still, replacing the namespace name with localized label in all places, may be not a simple task.

On FolderCreate issue. It looks like folder creation (or setting folder type) in IMAP failed (maybe it already existed?). Do you have IMAP log for this moment? We should probably handle better such situations, but first we should investigate the real reason of the issue to have fully-reproducible case.

In T1515#24393, @vendel.colja wrote:

Thanks, but could you please describe what "joining" in this case realy means?

Thanks, but could you please describe what "joining" in this case realy means?
Is there an android client working correctly with "custom folders"? Could you please tell me the name of one?

Most Android devices/apps do not support custom folders. That's why from the beginning we're "joining" all folders of specified type into one, i.e. Inbox, Calendar, Contacts, Tasks, Notes.