How is the sender the organizer, and not the user responding?
Why would we bounce the sender and comment about like this, noted that send_update_notification is already supplied with the itip_event['xml'] that contains both the organizer and the comment?
Here, the sender is a sender_attendee?
Same comments/questions as before on 464-467.
What is the 'sender' here is the initiator of a request or reply -- for requests, 'old is None', and for replies, I reckon 'old is not None', for a reply is supposed to be a mutation of an orignal.
I thought we had agreed to determine whether the attendee (whom this reply concerns) is an attendee for which the policy would dictate an automated reply be issued using is_auto_reply()?
I do not understand how this clause validates.
Because only organizer sends REQUEST messages. And we use this only to add "<Sender> commented..." in the notification. So, I think it's reasonably safe assumption. Getting sender from mail headers would be more complicated.
It's because there's a case when we don't use itip_event['xml'] as an argument for send_update_notification().
Yes, because this is iTip REPLY.
Same answers as above. This is iTip CANCEL and we use this only to add "<Sender> commented..." to the notification message.
This is just a sanity check. We add comment to the notification if we know the sender and there's a comment.
This is a loop over all attendees. So, if sender is defined and sender email equals currently processed attendee's email and this is auto-reply we unset the manual reply. I think this way we'll have less false-positives.