[Kolab-devel] Multiple identities and event handling

[David Faure]

On Monday 08 November 2004 15:11, Till Adam wrote:
> Imagine a secretary called Dave and his boss, Vanessa. Dave has Vanessa's 
> identity set up, since he needs to send mail on her behalf. He's also 
> authorized to schedule meetings for here, even ones where she is the 
> organizer.
> 
> Scenario one: 
> 
> Dave sets up a meeting with Vanessa as the organizer, and some attendees. He 
> stores the event in her calendar folder, to which he has write access. No 
> mail is sent out, since the organizer is one of the current user's 
> identities. All is well. Now he changes the event, which prompts a warning, 
> since he is not the organizer, which is the issue described in 511. Ok, no 
> problem, let's change it so that this warning is only shown when the 
> organizer is not one of our identities.
> 
> With that change done, let's look at
> 
> Scenario two:
> 
> Dave gets invited by Vanessa to his yearly review meeting, she is the 
> organizer, he is an attendee. He moves the event in his calendar. No warning 
> is issued, since the organizer is one of our identities, after the change 
> above, mail is sent to Dave himself, since he is an attendee, and no mail is 
> sent to Vanessa, since the organizer never gets notified, she should be the 
> only one capable of changing the event, after all. This is clearly wrong.

It seems to me that the only solution is to support the <creator> field (that Joon
requested for Outlook), and to check the <creator> field instead of the <organizer> field.

In both cases Vanessa is the "organizer" of the event, but in scenario one, 
the creator is Dave, whereas in scenario two the creator is Vanessa.

So we would look only at the creator when checking whether to show 
"you are not the [creator] of this event....", and compare that to the primary
identity of the user. It will match in scenario one, and not in scenario two,
as expected.

The consequences of this are that:
1) organizer becomes a purely informational field, like location and all the rest,
without any logic attached to it
2) creator becomes the field that triggers the logic. It must always be set
(to the primary identity of the person creating the event in the first place),
and it must be supported by all implementations (kontact doesn't support it
at the moment).

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).