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