183868 - Changing a request from - to + sends me two mails

Status: RESOLVED FIXED

(Bugzilla :: Attachments & Requests, defect)

Description

[Gervase Markham [:gerv]]

If I - a review request, and subsequently change that to a +, I get two mails,
both saying "Gervase Markham has granted Gervase Markham's request for
review..." This is wrong; bbaetz requested the original review which was -ed,
and I appear to have wrested control of it.

Relevant attachment is attachment 107844 [details] [diff] [review] of bug 158499.

Gerv

Comment 1

[[e-mail]]

Is this similar? aaronl re-requested (on the same patch) after I had denied
review and I received the following message:

Aaron Leventhal <[e-mail]> has denied [e-mail]'s request
for review:

Bug 189775: First keypress cancels any playing sound
http://bugzilla.mozilla.org/show_bug.cgi?id=189775

Attachment 112309 [details] [diff]: Should work, haven't tested with xul mines. Only lets sound
get initialized once.
http://bugzilla.mozilla.org/attachment.cgi?id=112309&action=edit

------- Additional Comments from Aaron Leventhal <[e-mail]>
That class already uses BOOL, presumably because it's in widget/src/windows.
I'm just remaining consistant with the rest of that class.

Comment 2

[[e-mail]]

Not again! I changed a review- to a review+, and received (despite the fact that
I don't want _any_ mail from bugs I change...) the following:

 <[e-mail]> has granted [e-mail]'s request for review:

Bug 193835: Missing focus when selected the related checkbox or radiobox in
Preference window.
http://bugzilla.mozilla.org/show_bug.cgi?id=193835

Attachment 115609 [details] [diff]: patch for comment18
http://bugzilla.mozilla.org/attachment.cgi?id=115609&action=edit

------- Additional Comments from  <[e-mail]>
OK, so this follows the precedent in pref-masterpass.js; nice fix in
pref-offline.xul :-)

Comment 3

[Karsten Düsterloh]

I still get confusing mails like the one mentioned in comment #1 here.
("Huh? I didn't request anything there? WTF?!")

I don't know the code in question, but it probably should check the flag's
actual state also...

Comment 4

[Frédéric Buclin]

I fixed this bug as part of bug 266147.