Bug 454796

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.

(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

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

(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. 

(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

Noura, is this bug still an issue?

(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

Tony is looking at this.

Noura

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

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.

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.

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.

(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

(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."