Description: Red Hat has altered the Bugzilla code to suppress any email from being sent to accounts that are disabled. Function Requirements: Bugzilla/BugMail.pm
Created attachment 290126 [details] patch to disable sending emails to account that has been disbaled
I think that this functionality already exist in Bugzilla 3.2 ,, looking at the code in Bugzilla/BugMail.pm they have the following: # Make sure the user isn't in the nomail list, and the insider and # dep checks passed. if ($user->email_enabled && $insider_ok && $dep_ok) { and in in Bugzilla/User.pm they have subroutines to return if the user is disbaled or not: sub email_enabled { !($_[0]->{disable_mail}); } so basically this function $user->email_enabled currently is called in 3.2 in 2 places in Bugzilla/Flag.pm and in Bugzilla/BugMail.pm ,, what we will have to do is ensure that all the code that sends emails to users ,, if it doesn't use Bugzilla/BugMail.pm to send the mail ,, then it calls $user->email_enabled to check if the user is allowed to receive emails or not. basically it will be 5 LOC for the check ,, and we would be looking at whine.pl , Bugzilla/FlagType.pm , Bugzilla/Token.pm, and also at Bugzilla/Mailer.pm so basically I would expect few lines of code spreaded in those modules for checking $user->email_enabled ,, so my assumption would be : 60 LOC Unit test: selenium testing will be required here ,, one test to disbale user account , then one test to check that the disbaled user doesn't get sent emails. so 2 tests , a test takes 2 hours to write so 4 hours
started discussion about it with the upstream: https://bugzilla.mozilla.org/show_bug.cgi?id=412053
Basically this bug is resolved in upstream bugzilla 3 , they have in the user object a parameter called "disable_mail" that is a boolean value if it is set to 1 the bug-related mail will not be sent to this user and if it is set to 0, mail will be sent depending on the user's email preferences. This parameter can be turned on and off by admins using checkbox called "Bugmail Disabled" in editusers.cgi So this bug is resolved. CLOSING. Noura
Reopening. We should use this bug to make sure that we add in functionality to the webservices infrastructure to allow disabling of accounts via XMLRPC. In 2.18 we have bugzilla.disableAccount() that allows us to set the disabledtext value which locks out the account. In 3.0 we will either need to port disableAccount() to the webservices infrastructure as a separate method, or create User.update() from scratch which gives the ability to update the disable_mail value. Dave
created a bug for it upstream to see what they think about what Dave said in comment #5 , either to have User.disable() method or a User.update method.
*** This bug has been marked as a duplicate of 427912 ***