Fixes #5403
Details
Diff Detail
- Repository
- rP pykolab
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
wallace/module_invitationpolicy.py | ||
---|---|---|
464–467 | How is the sender the organizer, and not the user responding? | |
467 | 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? | |
591 | Here, the sender is a sender_attendee? | |
657 | Same comments/questions as before on 464-467. | |
1130 | 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. | |
1139–1141 | 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()? | |
1168 | I do not understand how this clause validates. |
wallace/module_invitationpolicy.py | ||
---|---|---|
464–467 | 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. | |
467 | It's because there's a case when we don't use itip_event['xml'] as an argument for send_update_notification(). | |
591 | Yes, because this is iTip REPLY. | |
657 | Same answers as above. This is iTip CANCEL and we use this only to add "<Sender> commented..." to the notification message. | |
1130 | This is just a sanity check. We add comment to the notification if we know the sender and there's a comment. | |
1168 | 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. |