[Kolab-devel] Multiple identities and event handling

[Bo Thorsen]

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).

This is still a bit short of completely fixing the problem.

In the above, Dave has two identities: "myself" and "boss".

How will you figure out which of your identities is "you" - I mean, how 
will you see if Dave should set <creator> to "myself" or "boss"? I see 
three possible solutions here:

- Use the first identity (since you are likely to always add yourself 
first)

- Use the default identity

- Use an explicitly set field - i.e. choose the "me" identity in 
KOrganizer setup

All of these three carry other problems with them. The not so interesting 
problem is what happens if you change your current "me" identity - I 
would suggest not to worry too much about this, since we want to at least 
worry more about the common case, which is that this doesn't change. 
Using the default identity sounds good initially, but I think many 
secretaries would be tempted to just set it as the default identity, if 
they were switching all the time.

Bo.
-------------- 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/20041109/a235dfc8/attachment.sig>