aboutsummaryrefslogtreecommitdiffstats
path: root/.be/bugs/27bb8bc2-05c2-417a-9d09-928471380d7a/values
diff options
context:
space:
mode:
authorW. Trevor King <wking@drexel.edu>2009-09-26 13:02:18 -0400
committerW. Trevor King <wking@drexel.edu>2009-09-26 13:02:18 -0400
commit3fc33c5c19236e605f75566543ee2f315b2d2b07 (patch)
tree902d9cf987d62640cc27c8b97fc493afc5c1a529 /.be/bugs/27bb8bc2-05c2-417a-9d09-928471380d7a/values
parentf6be0960f00fba5265bc21d7e24f85cce22ae8a3 (diff)
downloadbugseverywhere-3fc33c5c19236e605f75566543ee2f315b2d2b07.tar.gz
Added "Confirm" and "Subscribe" pseudoheaders to be-handle-mail.
Allowed values for both are "yes" or "no", case insensitive. Setting Confirm:no disables the confirmation email letting you know your new bug was successfully submitted. Setting Subscribe:yes automatically subscribes you to the new bug you're submitting immediately, without reqiring an extra control email. In the case where both Confirm:yes and Subscribe:yes, the submitter will only recieve the subscription email (which shows the "be show" view of the new bug) and not the submission email (which shows the output of all the executed submission commands). Both of these pseudoheaders were in response to a Would you like a direct response concerning your comments? checkbox on the web frontend that generates emails for a BE repo. When the checkbox is set, we set Confirm:yes Subscribe:yes, and the submitter gets a nice pretty confirmation email and will be automatically notified of any future action on their bug. When the checkbox is not set, they get no response or submission emails. Also fixed up some bugs in in the subscriber_emails() parsing. We now use ordered_subscriptions to ensure that we parse the "DIR" subscription first, since we don't want to include the same information twice, and the user might be subscribed to DIR:all and a particular bug (which would be wierd, but is easily avoidable). This also ensures that the more central DIR level changes appear first in the email. We also check that there is an entry for a particular bug in bug_index before attempting to grab it, which could raise KeyErrors otherwise. Finally, we check to make sure we don't double-include bugs for which the user is subscribed to both that bug's new and DIR:new. A final minor correction is the capitalization of the first word of our log entries. The logs are pretty cluttered, and the capitalization helps the lines I care about stand out. A better solution would be to come up with a cleaner idea of what to write to the logs...
Diffstat (limited to '.be/bugs/27bb8bc2-05c2-417a-9d09-928471380d7a/values')
0 files changed, 0 insertions, 0 deletions