Currently fixed, but the ticket will be open until we unify document_editor_api.

I didn't test yet, but then I think the described behaviour is not exactly as expected. I.e. if UserB is not the organizer I do not expect attendees (nor organizer) to be informed. We should not send cancellation emails with UserB's as a sender. Or maybe we should? That's problematic.

@machniak I am not using identities or delegation, it just a simple shared folder.

@Robert_Selk are you using delegation feature or simple ACL modification? Or in other words, does UserB have identities with UserA's addresses? I'm asking just to be sure I test the same scenario.

Tested it with Rouundcube Plugins 3.2.15-4.1.el6.kolab_14.

Just adding the problem for the record:

Oops, sorry...
Version: roundcubemail-plugins-kolab-3.3-1.10.el7.kolab_16.noarch

pykolab version is irrelevant. This is roundcubemail-plugins-kolab issue.

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

We are still unable to reproduce this.

Excellent (indeed it is..).

It is implemented also in KE14 for a long time. I didn't close this task, because converting to plain text is not the same as supporting HTML.

@machniak - Can this me backported to KE14 - please.

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.

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.

Closing this as a config issue.

Thanks Alek, that hint is useful.
I might try to create a new dialog using the ideas from the mail compose screen.

The field has autocompletion feature implemented. So, should give you search results while typing. I know some people prefer addressbook widget, that's why we have it in mail compose screen.

To disable Settings section of the UI I propose to set:

$config['kolab_auth_admin_rights'] = array(
    'settings' => 'entry:delete',
    '*' => 'entry:read',
);

Note that with this LDAP effective rights will be used and kolab_auth_group/kolab_auth_role_value will be ignored. You can also change 'entry:delete' to 'attrib:kolabDelegate:write' (or use some other attribute).

Just because I was asked for " ​what is in your: $config['kolab_auth_admin_rights'] = array()" here the kolab_auth.inc.php we use

I may would have agreed, but after roundcube provides a "helpdesk-login" function and independently of that provides delegation or password plugins performing such LDAP "edit" tasks, someone using the heldesk-login feature should either

• get a warning that those plugin functions are just readonly and not an adminstration frontend replacement

or

• find any edit functionality involved by those plugins disabled

or

• have just no access to those plugins (Could you please give me a hint how to disable delegate from settings?)

or

• enable edit/admin/helpdesk tasks for "helpdesk-login" usage by what ever possible action/task

Neither delegation nor password resets for a user should go through Roundcube. Roundcube, after all, is not an LDAP administration interface.

Confirmed. I tried SASL proxy authentication here, but didn't work for me. @vanmeeuwen is additional "service user" (i.e. new config options for DN and password) the only solution?

I was able to fix the issue on moving/resizing the event, but I wasn't able to reproduce the issue on event delete. I'm closing the ticket now. Please, reopen if the issue still exist after aplying my change.

Ok, more testing. I see now where the problem is. I think I misunderstood the problem description as there was no word "delegation" ;)

I'm not able to reproduce the notification issue. I.e. when I delete or move or edit such an event iTip notifications are not being send. Which would mean that the only problem really is misleading wording of the warning text.

Some of the behavior that seems to be requested (albeit not explicitly) leans toward workflow management more so than it is squarly within the realm of simple task management.

Please note that, IIRC, the freebusy service renders Free/Busy information with a certain timeslot as well -- if any event overlaps either of the lower or upper boundaries the entire slot is considered busy.

I would suggest to consider sending out the notifications of the changes as user2, in that this is rendered quite dysfunctional practically, should no notifications be sent out at all.

So, we have two issues here:

Tested and it seems to be working.

Tested and it seems to be working.

Probably the number of slots in an hour here should depend on Preferences > Calendar > Time slots per hour.

Fixed Bug#1, Bug#2, Bug#3 described in my previous comment.

Ok, there's a couple of issues here described, but first... Let's agree that (while we do not support counter proposals) when an attendee changes a task's status the iTip REPLY is send to the organizer. When the REPLY is "merged" only an attendee status should be updated, NOT the completion status. Think about a task with two attendees (assignees).

Confirmed. I see this message is used sometimes when moving/resizing/deleting an event. However, I'm not really convinced about usefulness of such a message. I don't see a code that would "copy" the event to personal calendar, so it does not make sense at all.

It is just a shared Folder.

Yes, this is definitely a duplicate of T1301. However, the solution suggested there is only a partial fix, i.e. the case insensitive email comparison is fixed, but the regex used to match email addresses is still broken.