Bug 454796 - closed bugzilla accounts don't get replaced in components' default assignees
closed bugzilla accounts don't get replaced in components' default assignees
Status: CLOSED NOTABUG
Product: Bugzilla
Classification: Community
Component: Bugzilla General (Show other bugs)
3.2
All Linux
low Severity low (vote)
: ---
: ---
Assigned To: Tony Fu
:
Depends On:
Blocks: 474288
  Show dependency treegraph
 
Reported: 2008-07-09 23:08 EDT by Noura El hawary
Modified: 2013-06-24 00:03 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-04 00:37:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


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

  None (edit)
Description Noura El hawary 2008-07-09 23:08:34 EDT
In our current bugzilla account closure script there no functionality to change
the disabled owner or qa contact of a component to their manager's account or
someone else's , this leave a big chance that new bugs will still be created and
assigned to disabled accounts, i believe we didn't implement this because there
was no easy way in out current xmlrpc interface to find out the components by
the owner or by the qacontact, unless we loop through all the components in
bugzilla and filter the ones we want which is not really a good idea. 

best solution to solve this problem in 3.2 i guess will be to have xmlrpc
function   to get compnents of specific user , but i don think that we will find
supporting code for that in the core/base Component.pm object in the code base
of 3.2 so we will have to implement it using sql queries!!

any thoughts?

Noura
Comment 1 Kevin Baker 2008-07-14 10:02:14 EDT
so you are talking about two steps

1) querying bugzilla for components by {owner,qa_contact}
2) changing the found component.{owner,qa_contact} to 
{new_owner,new_qa_contact}

There is no way to do either of those two steps with the current bugzilla?

*IF* this is new functionality it should be developed in the upstream (of 
course:) It should be put in the core library.
Comment 2 Noura El hawary 2008-07-16 20:55:06 EDT
(In reply to comment #1)
> so you are talking about two steps
> 
> 1) querying bugzilla for components by {owner,qa_contact}
> 2) changing the found component.{owner,qa_contact} to 
> {new_owner,new_qa_contact}
> 
> There is no way to do either of those two steps with the current bugzilla?
> 

Actually I was wrong ,, there is functionality to do that in upstream bugzilla
3.2 ,, basically in the web interface looking at editusers.cgi for any user
account at the bottom of the page there is a section that is called 
"Product responsibilities"  that has list of all product components that this
user is either initialowner for or qacontact for ,, and it gets this info from
the base module Bugzilla/User.pm through a function called
$user->product_responsibilities so we can user this to get list of all
components that the user is a member of, then the editing part should be easily
done through out contributed xmlrpc function Component.update.

Noura
Comment 3 Noura El hawary 2008-07-16 20:58:52 EDT
I guess we can update the current contirbuted xmlrpc function User.get to also
return the products/components that the user is responsible for, so 2 steps:

1- extend current xmlrpc User.get code to return product/components of the user
and contribute that to upstream.

2- use current contributed xmlrpc function Component.update to edit the
components to the new owner .

Noura
Comment 4 Kevin Baker 2008-07-17 10:23:15 EDT
(In reply to comment #3)
> I guess we can update the current contirbuted xmlrpc function User.get to 
also
> return the products/components that the user is responsible for, so 2 steps:

Seems reasonable, but I would discuss it first with Max et al to see if it 
should be part of User.get. 
Comment 5 Noura El hawary 2008-07-18 00:09:52 EDT
(In reply to comment #4)
> (In reply to comment #3)
> > I guess we can update the current contirbuted xmlrpc function User.get to 
> also
> > return the products/components that the user is responsible for, so 2 steps:
> 
> Seems reasonable, but I would discuss it first with Max et al to see if it 
> should be part of User.get. 
> 

OK create a bug upstream to get their opinions about that.

Noura
Comment 6 David Lawrence 2008-11-24 16:00:29 EST
Noura, is this bug still an issue?
Comment 7 Tony Fu 2008-12-15 19:35:40 EST
(In reply to comment #6)
> Noura, is this bug still an issue?

Talked to Dennis Gregorovic a few days ago about the way of package owner information in Brew overwriting the component owner in Bugzilla.  

Basically, if we change the component owner in bugzilla without changing the corresponding package owner in Brew, the component owner in bugzilla is likely to be changed back by Brew.  So we need to change the component owner in bugzilla as well as the corresponding package owner in Brew.

Brew cli has the utilities to search a list of package owned by a specific user and change these packages' owner to other users (may need Brew admin permission).  These tools are Python programs, and we can translate them into Perl and use them in our account closure script to change package owner in Brew.


Tony
Comment 8 Noura El hawary 2009-02-03 22:35:10 EST
Tony is looking at this.

Noura
Comment 9 Tony Fu 2009-02-04 00:37:26 EST
Due to permission issue on Brew, we currently can't implement the function of changing package's owner in Brew.  So we will open a releasing engineer ticket to ask Brew admin to change these package's owner and push these information back to the Bugzilla.  (Brew team has existing tools to do these tasks).

Please refer to https://engineering.redhat.com/trac/eng-ops/wiki/BugzillaProcedureAccountClosure for the details of closing a user account.


Tony
Comment 10 Kevin Baker 2009-02-11 17:18:15 EST
Hi Tony,

seems like the ./eng-ops-close-account-bz3.pl should do step 6 automatically and email release-engineering. This will save another manual step for our overworked engineers.
Comment 11 Tony Fu 2009-02-16 01:48:35 EST
Added function of sending a release- engineering automatically into eng-ops-close-account-bz3.pl script and updated wiki page (https://engineering.redhat.com/trac/eng-ops/wiki/BugzillaProcedureAccountClosure
)as well.

Close this ticket.
Comment 12 Kevin Baker 2009-02-16 16:23:52 EST
Tony,

a couple of questions around the '--create-brew-ticket' option I read in the updated documentation.

Wouldn't it be better if the script didn't require the user to add this flag? In other words the script default behaviour should be to act like '--create-brew-ticket' was set.

If there is an error during the sending of the email then the script should print out the email it was trying to send so the user can send it manually.

So, I don't think we need an option called '--create-brew-ticket'. We just need the script to behave sanely when it can't send an email and prompt the user when there has been a problem.
Comment 13 Tony Fu 2009-02-18 01:47:33 EST
(In reply to comment #12)
> Tony,
> 
> a couple of questions around the '--create-brew-ticket' option I read in the
> updated documentation.
> 
> Wouldn't it be better if the script didn't require the user to add this flag?
> In other words the script default behaviour should be to act like
> '--create-brew-ticket' was set.
> 
> If there is an error during the sending of the email then the script should
> print out the email it was trying to send so the user can send it manually.
> 
> So, I don't think we need an option called '--create-brew-ticket'. We just need
> the script to behave sanely when it can't send an email and prompt the user
> when there has been a problem.

Kevin,

Creating brew ticket as default behaviour could be a good, the only question is that the sendmail or other mail server need to be set properly on the host where the script run from  to make it work.  It could be the problem for some user's machines.  


Tony
Comment 14 Kevin Baker 2009-02-18 10:58:18 EST
(In reply to comment #13)
> Creating brew ticket as default behaviour could be a good, the only question is
> that the sendmail or other mail server need to be set properly on the host
> where the script run from  to make it work.  It could be the problem for some
> user's machines.  

Have you looked at Email::Sender?

http://search.cpan.org/~rjbs/Email-Sender-0.002/lib/Email/Sender.pm

From the man page

  "If a local sendmail program is unavailable, Email::Sender::Transport::SMTP 
   will allow you to send mail through your relay host."

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