- Summary:
-
Rename review_request_draft_save() to review_request_draft_publish()SoC branch
- Description:
-
+ I'll track my Summer of Code branch on this review request, keeping a changelog in the description field.
+ + Diff 1:
+ Rename review_request_draft_save() to review_request_draft_publish()
Saving is actually already done with review_request_draft_set(). What
this method really does is publishing, so the new name suits it better. Question though: what is our deprecation policy? How long do we have to keep the old stuff around? Is there any particular marker in the code using for depracating stuff and notifying users when they use old stuff?
Send signals instead of emails. Listen to signals to send emails.
Review Request #910 — Created July 2, 2009 and submitted
This is the email refactoring part based on sending and listening to signals. All (core) code related to listening to signals and sending notifications (for now, only by email) will be kept under /notifications. This will pave the way for the introduction of webhooks. Diff 1 is described here; subsequent diffs will be described in the change description. ## Diff 1: Rename review_request_draft_save() to review_request_draft_publish() Saving is actually already done with review_request_draft_set(). What this method really does is publishing, so the new name suits it better. Question though: what is our deprecation policy? How long do we have to keep the old stuff around? Is there any particular marker in the code using for depracating stuff and notifying users when they use old stuff?
All tests run.
HE
HE
- Change Summary:
-
Test if mail is sent from the reviewrequests/draft/publish API. Also, extract assertValidRecipients out of reviews/tests.py to make it reusable by webapi/tests.py
HE
- Description:
-
~ I'll track my Summer of Code branch on this review request, keeping a changelog in the description field.
~ I'll track my Summer of Code branch on this review request. Diff 1 is described here; subsequent diffs will be described in the change description.
Diff 1:
Rename review_request_draft_save() to review_request_draft_publish()
Saving is actually already done with review_request_draft_set(). What
this method really does is publishing, so the new name suits it better. Question though: what is our deprecation policy? How long do we have to keep the old stuff around? Is there any particular marker in the code using for depracating stuff and notifying users when they use old stuff?
HE
- Change Summary:
-
Test that reviewrequests/publish API sends email. This is the last test added to the existing code before changing it, so that we ensure it behaves the same afterwards.
HE
- Change Summary:
-
Send signals instead of emails. Listen to signals to send emails. Formatting changes according to review.
- Diff:
-
Revision 5 (+148 -37)
-
Some changes, mostly stylistic. As for keeping all your changes in one review request, I'd actually rather prefer smaller diffs, each with their own review request. This helps us to keep track of each change, and the status of the change, and allows us to have more granualar commits.
-
-
-
Should be more like: def review_request_published_cb(sender, user, review_request, changedesc, **kwargs): ... mail_review_request(user, review_request, changedesc) Same with the other callbacks. -
Should derive from 'object'. Also, this should be part of the test suite, instead of here. It's okay to reference classes in one test suite from another, in the case of webapi.
-
Can you put these after send(, breaking across lines and aligning with the first parameter when necessary?
-
-
-
-
-
-
-
-
-
Store the id in one line, and then call apiPost in another. It'll make it easier to debug if the lookup fails.
HE
- Change Summary:
-
This review request is now only related to the refactoring part and will not track the whole of my GSoC (won't include the webhooks part). This is self-contained and can be committed sepparetely.
- Summary:
-
SoC branchSend signals instead of emails. Listen to signals to send emails.
- Description:
-
~ I'll track my Summer of Code branch on this review request. Diff 1 is described here; subsequent diffs will be described in the change description.
~ This is the email refactoring part based on sending and listening to signals. All (core) code related to listening to signals and sending notifications (for now, only by email) will be kept under /notifications. This will pave the way for the introduction of webhooks.
+ + Diff 1 is described here; subsequent diffs will be described in the change description.
Diff 1:
Rename review_request_draft_save() to review_request_draft_publish()
Saving is actually already done with review_request_draft_set(). What
this method really does is publishing, so the new name suits it better. Question though: what is our deprecation policy? How long do we have to keep the old stuff around? Is there any particular marker in the code using for depracating stuff and notifying users when they use old stuff?
HE
- Change Summary:
-
Moved email-sending code and tests to /notifications, except for full-stack email tests which stayed in webapi/tests.py. Added docstrings to email-sending signal handlers. Formatting fixes.
- Diff:
-
Revision 7 (+469 -337)
HE
- Change Summary:
-
Previous diff had a stupid syntax error (rogue "p" at line ending in "()p"). Fixed now.
- Diff:
-
Revision 8 (+469 -337)
HE
- Change Summary:
-
Formatting fixes.
- Diff:
-
Revision 9 (+467 -337)