Bug 406211 - 3.11: XMLRPC method needed to disable sending of email to accounts that have been disabled.
3.11: XMLRPC method needed to disable sending of email to accounts that have ...
Status: CLOSED DUPLICATE of bug 427912
Product: Bugzilla
Classification: Community
Component: Bugzilla General (Show other bugs)
All Linux
high Severity medium (vote)
: ---
: ---
Assigned To: Noura El hawary
4 hours for selenium testing
: Reopened
Depends On:
Blocks: RHBZ30UpgradeTracker 427051
  Show dependency treegraph
Reported: 2007-11-30 11:58 EST by David Lawrence
Modified: 2013-06-24 00:19 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-18 23:51:41 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch to disable sending emails to account that has been disbaled (9.58 KB, text/plain)
2007-12-20 01:25 EST, Noura El hawary
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Mozilla Foundation 416137 None None None Never

  None (edit)
Description David Lawrence 2007-11-30 11:58:14 EST
Red Hat has altered the Bugzilla code to suppress any email from being sent to accounts that are disabled.

Function Requirements:
Comment 1 Noura El hawary 2007-12-20 01:25:54 EST
Created attachment 290126 [details]
patch to disable sending emails to account that has been disbaled
Comment 2 Noura El hawary 2007-12-20 01:51:10 EST
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 &&

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 
Comment 3 Noura El hawary 2008-01-12 02:38:45 EST
started discussion about it with the upstream:

Comment 4 Noura El hawary 2008-02-05 08:00:55 EST
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.


Comment 5 David Lawrence 2008-02-05 10:47:52 EST
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.

Comment 6 Noura El hawary 2008-02-07 10:43:33 EST
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.
Comment 7 Noura El hawary 2008-02-18 23:51:41 EST

*** This bug has been marked as a duplicate of 427912 ***

Note You need to log in before you can comment on or make changes to this bug.