Bugzilla

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

(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

(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