Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 454796 - closed bugzilla accounts don't get replaced in components' default assignees
Summary: closed bugzilla accounts don't get replaced in components' default assignees
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Bugzilla
Classification: Community
Component: Bugzilla General
Version: 3.2
Hardware: All
OS: Linux
low
low vote
Target Milestone: ---
Assignee: Tony Fu
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 474288
TreeView+ depends on / blocked
 
Reported: 2008-07-10 03:08 UTC by Noura El hawary
Modified: 2013-06-24 04:03 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-02-04 05:37:55 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Mozilla Foundation 445928 None None None Never

Description Noura El hawary 2008-07-10 03:08:34 UTC
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 14:02:14 UTC
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-17 00:55:06 UTC
(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-17 00:58:52 UTC
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 14:23:15 UTC
(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 04:09:52 UTC
(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 21:00:29 UTC
Noura, is this bug still an issue?

Comment 7 Tony Fu 2008-12-16 00:35:40 UTC
(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-04 03:35:10 UTC
Tony is looking at this.

Noura

Comment 9 Tony Fu 2009-02-04 05:37:26 UTC
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 22:18:15 UTC
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 06:48:35 UTC
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 21:23:52 UTC
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 06:47:33 UTC
(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 15:58:18 UTC
(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.