[Kolab-devel] Multiple identities and event handling

[Till Adam]

On Monday 08 November 2004 15:38, David Faure wrote:
> 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).

Ok, should I implement this, with the default identity being used for the 
creator field, or are these musings for future improvements, at this point? 
If so I think we need to talk to the KOrganizer people about how much of this 
makes sense in the general KOrganizer case. Reinhold?

Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20041118/adf99955/attachment.sig>