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.

So, potentially this is to be fixed in both roundcube plugins and pykolab. Such change need to be thinked on carefuly, as it may have more implications.

This is problematic with Kolab delegation concept.

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?

2. What if User B is the organizer and User A is invited? Now, if User B would try to handle UserA's invitation he will encounter a problem, because if we search for the event in shared folders it will be detected as existing, while for User B it may not be visible at all (and should be added to the personal calendar).

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?

Making sure your delegate has access to folders in which they are supposed to manage appointments seems an acceptable requirement.

The error message when trying to accept an event / enter an update for an event that a user has no access/visibility on may need some thinking, though. In any case, the application should know this was User B acting as a delegate (because user B is not among participants, User A was) so probably this needs a specific check and error message, perhaps?

2. What if User B is the organizer and User A is invited? Now, if User B would try to handle UserA's invitation he will encounter a problem, because if we search for the event in shared folders it will be detected as existing, while for User B it may not be visible at all (and should be added to the personal calendar).

Whether User B wants to get this event from the shared calendar, or add it to their personal calendar, as well, is indeed a valid question. There is probably no universal answer for this.

Perhaps this actually needs a user interaction.

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.

More I work on this more issues I see. E.g. "Show me as" field in the event. To whom it should apply if that's a shared event with many attendees? Of course users can (in Winterfell only) copy the event to their calendar and change that. But such issues give questions about use-cases for shared calendars and if we should prevent users from using them, or limit somehow.

For example, when user receives an invitation request for a shared event, if we "enable" shared folders, he will not have a direct possibility to store the event in his personal calendar because it has been found in shared folder. Maybe we should not search in shared folders on requests?

Now, consider itip reply/cancel (the initial issue of this ticket). If we "enable" shared folders user will be able to handle the itip (update resource status), if we disable he can do nothing with the itip.

In other words maybe we should "disable" shared folders on itip requests, but "enable" for any other itip messages (reply, cancel, etc.). Which would force user to create an event copy on invitation request. I think that wouldn't be a bad idea if we had event de-duplication in calendar. Currently user will see two similar/identical events as he has access to shared folder (I actually did not test this).

In T1523#24982, @machniak wrote:

Privileges to shared folders are managed by admins.

Yes. Although they may give these users admin privileges, which is a common case.

Users have no way to make sure delegatee has access to a shared folder. User probably should not care much about this.

Unless the user is also the one managing the shared folder. Either way, if a user is supposed to administrate that folder, and does not have access, that's a configuration mistake. Like many other configuration mistakes that are possible, it would make things hard for the user. But it would be fixable by the admins.

All the application should do is say: "Event not found. Please have your administration check access control to shared folders." or some such.

That tells the user enough, including a path to resolution.

More I work on this more issues I see. E.g. "Show me as" field in the event. To whom it should apply if that's a shared event with many attendees?

If one person is the delegatee to two other people, the "me" in this can be one of three people, true. If a person acts as a delegatee, and there is more than one of their identities as participants in the mail, perhaps there should be multiple such lines, allowing to set

"Show X as"
"Show Y as"
"Show Z as"

or some such.

In other words maybe we should "disable" shared folders on itip requests, but "enable" for any other itip messages (reply, cancel, etc.). Which would force user to create an event copy on invitation request. I think that wouldn't be a bad idea if we had event de-duplication in calendar. Currently user will see two similar/identical events as he has access to shared folder (I actually did not test this).

Maybe, but not all devices de-duplicate.

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.

For updates / responses to events, the default behaviour could be to update all instances of the event if it is found anywhere (private, other user, shared) and if it is found in a shared folder context, to also offer to "save into personal calendar" or some such.

Thoughts?

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.

For updates / responses to events, the default behaviour could be to update all instances of the event if it is found anywhere (private, other user, shared)

Yeah, but that might be a lot of work. Current code works only with one instance (first found) of the event. Note also that details of each event instance may be different, so updating all might be tricky.

and if it is found in a shared folder context, to also offer to "save into personal calendar" or some such.

Well, if it is an update and we can't find the event, we can assume it's not to us or not exists anymore. So, having an option to save it here does not make much sense.

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.

For delegate scenarios, the invitation will be for an identity that is not the user's and we should search the folders shared by other then, no?

Also, generally it would make sense to always search all shared folders for a full shared folder support scenario.

If we do not find the event, we know that

(a) the user does not have access to the shared folder

or

(b) the user is now invited for the first time to this event

So we probably just want to let the user save it into a folder they DO have access to (including shared folders).

For updates / responses to events, the default behaviour could be to update all instances of the event if it is found anywhere (private, other user, shared)

Yeah, but that might be a lot of work. Current code works only with one instance (first found) of the event. Note also that details of each event instance may be different, so updating all might be tricky.

Agreed.

But the response is typically to an email address, no, given it is an email? If that is one of the delegators, that is the calendar to work in, if it is yours, your own (if present there), otherwise shared.

and if it is found in a shared folder context, to also offer to "save into personal calendar" or some such.

Well, if it is an update and we can't find the event, we can assume it's not to us or not exists anymore.

I am not sure that is a safe assumption, it could be that it is in a folder we do not see, or that we got an update forwarded.

So ideally we'd let the user know: "This is an update to an event was not found in your personal or accessible shared calendars." and offer him the option to treat it as a "new" invite, essentially.