1707997 - Proposal: persist the identity an invitation was accepted with so it can be retrieved and used later.

Status: RESOLVED FIXED

(Calendar :: E-mail based Scheduling (iTIP/iMIP), enhancement)

Description

[Lasana Murray]

Bug 1702782 will allow users to accept an invitation and reply with an identity other than the one configured for the target calendar. That means that later operations on the event which call getInvitedAttendee() may not get the desired identity because that method reads from the calendar only.

To allow the correct identity to be used, for sending out cancellations on delete for example, I propose adding the identity key directly to the event item. This will make the correct identity always available.

To ensure that information survives restarts, that property would have to persisted to the local database.

Comment 1

[Lasana Murray]

I figured it best to seek advice on this first.

Comment 2

[Magnus Melin [:mkmelin]]

But, it only applies when you're not an invitee, right? And once you rsvp'd you will be on the list (at least locally, servers may choose not to accept it). So for processing at that time, you will always find yourself in the attendees list and things will work. Or?

Comment 3

[Lasana Murray]

(In reply to Magnus Melin [:mkmelin] from comment #2)

But, it only applies when you're not an invitee, right? And once you rsvp'd you will be on the list (at least locally, servers may choose not to accept it). So for processing at that time, you will always find yourself in the attendees list and things will work. Or?

Currently we always assume the invited attendee is the identity on the calendar. The attendees list is more or less consulted to ensure that identity is also listed there, if not, we either assume no invited attendee or in some areas use the default. Things sort of work like this but I'm sure there are subtle bugs. For example; I noticed that when I accept an event to a calendar, change the calendar's identity, then delete the event, I don't get the "Send email" prompt and the cancellation does not go out.

I think it's a good idea in general to keep track of how an invitation was received on the item instead of computing it every time.

Comment 4

[Magnus Melin [:mkmelin]]

Well you're always the organizer or an attendee, right? So it seems it would be redundant information. Also in your example it should have worked out if we make sure to check you're one of the persons on the event: and it would have sent from the right address even if you moved it to another calendar.

Comment 5

[Lasana Murray]

(In reply to Magnus Melin [:mkmelin] from comment #4)

Well you're always the organizer or an attendee, right?

Perhaps, but I do wonder what happens when an invitation is received and none of the configured identities are on the attendee list.

So it seems it would be redundant information.

When we have accepted an invitation to a calendar, how will code determine which attendee was the one invited?
You can:

1. Use whatever attendee's email matches the identity for the calendar.
2. Iterate the list of attendees and select whichever one we have a matching identity for.

Currently 1 is done but as I mentioned before, this won't do if we allow users to accept the event using an identity different to the calendar's identity. A subsequent deletion for example, might send the cancellation from the wrong identity (it would use the calendar's identity not the identity that accepted the invitation). From my testing however, this may not even happen if the calendar's identity is not on the invited attendees list. Instead the logic stops short because getInvitedAttendee() will return null and it assumes there is nothing else to do.

There are a number of things wrong with 2 but most obvious might be what if you have identities configured for other attendees to the event?

Also in your example it should have worked out if we make sure to check you're one of the persons on the event: and it would have sent from the right address even if you moved it to another calendar.

This is what is done, however as I hinted before "check you're one of the persons on the event" means "check the calendar's identity is one of the persons on the event".

Note: I did not move the event to another calendar, I just changed the identity.
Note2: An alternative to storing the identity key might be to store the invited attendee. This feels slightly more relevant but storing the identity gives a clear line to who actually accepted the invitation

Comment 6

[Magnus Melin [:mkmelin]]

(In reply to Lasana Murray from comment #5)

(In reply to Magnus Melin [:mkmelin] from comment #4)

Well you're always the organizer or an attendee, right?

Perhaps, but I do wonder what happens when an invitation is received and none of the configured identities are on the attendee list.

But the code needs to add the specified party crasher as an attendee, no? Otherwise the receiver can't do anything with what it gets.

There are a number of things wrong with 2 but most obvious might be what if you have identities configured for other attendees to the event?

If we have multiple potential matches we should ask.

Note2: An alternative to storing the identity key might be to store the invited attendee. This feels slightly more relevant but storing the identity gives a clear line to who actually accepted the invitation

Yes, you need to add the party crasher as attenedee in the invite. The receiver will process the invite data, not who emailed it.

Comment 7

[Lasana Murray]

If we have multiple potential matches we should ask.
More dialogs?

I think you may have misunderstand the scenario I'm describing here, to be clear:
The invited attendee is added to the event, however it is added to the list of attendees, which means there is no way to distinguish for sure which of those attendees was the one invited aside from the two ways I mentioned earlier.

Using the calendar's configured itip.identity property simply won't work for the "party crasher" scenario because that identity is not on the attendee list. Trying to detect the attendee by looking up installed identities is likely to be error prone and I would even add plain wrong.

We have the information already about the invited attendee at the point the invitation comes in, we just don't store it anywhere. What I am proposing here is we hold on to that information for future use. I proposed the identity key because it removes all assumptions about how we got the invitation but a dedicated property for the invited attendee could work too.

Comment 8

[Magnus Melin [:mkmelin]]

(In reply to Lasana Murray from comment #7)

I think you may have misunderstand the scenario I'm describing here, to be clear:

That's quite possible...

The invited attendee is added to the event, however it is added to the list of attendees, which means there is no way to distinguish for sure which of those attendees was the one invited aside from the two ways I mentioned earlier.

But why aren't those good enough?

Using the calendar's configured itip.identity property simply won't work for the "party crasher" scenario because that identity is not on the attendee list. Trying to detect the attendee by looking up installed identities is likely to be error prone and I would even add plain wrong.

Storing the identity key is not really a solution though: if you have the calendar on multiple machines (say at work, home), the ids can be different. It's a can of worm... so I still think just checking the invitees against the identity list will be the best solution.

Comment 9

[Lasana Murray]

The invited attendee is added to the event, however it is added to the list of attendees, which means there is no way to distinguish for sure which of those attendees was the one invited aside from the two ways I mentioned earlier.

But why aren't those good enough?

Because:

Bug 1702782 will allow users to accept an invitation and reply with an identity other than the one configured for the target calendar. That means that later operations on the event which call getInvitedAttendee() may not get the desired identity because that method reads from the calendar only.

Comment 10

[Magnus Melin [:mkmelin]]

Ok, I guess storing the me-address could be acceptable then.

Comment 11

[Lasana Murray]

So... as far as I can tell the only way I can implement this is by adding an X-MOZ- property to the item. That should ensure the property is saved with local calendars and at least submitted to remote ones. I do wonder about the potential for mischief however, if that property is set externally.

Comment 12

[Magnus Melin [:mkmelin]]

There's the SENT-BY parameter in the spec. https://tools.ietf.org/html/rfc5545#section-3.2.18

Comment 13

[Lasana Murray]

(In reply to Magnus Melin [:mkmelin] from comment #12)

There's the SENT-BY parameter in the spec. https://tools.ietf.org/html/rfc5545#section-3.2.18

I think that's for a slightly different purpose? I see it can be used as an attendee property but that won't get around knowing which of the attendees accepted the event. It should probably still be set however to avoid confusing the event organizer.

Comment 14

[Geoff Lankow (:darktrojan)]

Having read the discussion, I don't have a lot to add.

Magnus is right that you'd want to store the address, not the identity. Also you'd have to decide what to do if no identity matching the address is available (e.g. the identity is removed or you're on a different machine) though I guess you just do what already happens.

If I'm reading this right we clone the local copy of an item and modify it before sending it to others. If you add a property make sure to remove it here too.

Comment 15

[Lasana Murray]

Attachment: Bug 1707997 - Make getInvitedAttendee() check for the X-MOZ-INVITED-ATTENDEE property. r?darktrojan

Comment 16

[Magnus Melin [:mkmelin]]

Nothing to land here yet.

Comment 17

[Lasana Murray]

(In reply to Magnus Melin [:mkmelin] from comment #16)

Nothing to land here yet.

Wrong bug. Sorry!

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/814e5f286c6f
Make getInvitedAttendee() check for the X-MOZ-INVITED-ATTENDEE property. r=darktrojan