Page MenuHomekolab.org

Use COMMENT in invitation policy notifications (#5403)
ClosedPublic

Authored by machniak on May 20 2016, 9:03 AM.

Diff Detail

Repository
rP pykolab
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

machniak updated this revision to Diff 357.May 20 2016, 9:03 AM
machniak retitled this revision from to Use COMMENT in invitation policy notifications (#5403).
machniak updated this object.
machniak edited the test plan for this revision. (Show Details)
machniak added a reviewer: PyKolab Developers.
vanmeeuwen requested changes to this revision.May 23 2016, 2:51 PM
vanmeeuwen added a reviewer: vanmeeuwen.
vanmeeuwen added a subscriber: vanmeeuwen.
vanmeeuwen added inline comments.
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.

This revision now requires changes to proceed.May 23 2016, 2:51 PM
machniak requested a review of this revision.May 30 2016, 12:39 PM
machniak edited edge metadata.
machniak added inline comments.
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.

vanmeeuwen accepted this revision.Jul 1 2016, 9:55 AM
vanmeeuwen edited edge metadata.
This revision is now accepted and ready to land.Jul 1 2016, 9:55 AM
This revision was automatically updated to reflect the committed changes.