Re: Security problem - Mozilla
This is a discussion on Re: Security problem - Mozilla ; Bill,
You have mentioned that you had changed your Bugzilla installation to
restrict permissions and verify/close permission was granted only to the QA
team members. Can you please give me the detailed steps to achieve this.
It would be very ...
-
Re: Security problem
Bill,
You have mentioned that you had changed your Bugzilla installation to
restrict permissions and verify/close permission was granted only to the QA
team members. Can you please give me the detailed steps to achieve this.
It would be very helpful.
Regards,
Partha sarathi Mukherjee
Testing department
Descon Ltd.
Plot No.- X- 1, 2 & 3, Block- EP, Sector- V
Salt Lake City
Kolkata- 700091
India
Phone: +91 (033) 23574308/09/10 EXTN. 115
Mobile: 9831019078
Fax: +91 (033) 23573758
Visit us at www.desconsoft.com
Bill Davis
Sent by: To: support-bugzilla@lists.mozilla.org
support-bugzilla-bounces@lists.m cc:
ozilla.org Subject: Re: Security problem
12-10-2007 11:44
Marc Schumann wrote:
> In my very personal opinion, you have quite another problem if
> your people are working irresponsibly. Getting them to work honestly
> is better than restricting them from cheating.
My 2 cents: I had the same concern ... not because I thought anyone
would intentionally try to circumvent QA, but because in its default
setup it is possible for anyone with editbugs permissions to mistakenly
(through ignorance of local workflow or otherwise) designate a bug as
"VERIFIED" OR "CLOSED" before QA was complete and therefore take it off
of QA's radar. Using the docs (and with almost no Perl knowledge) I
changed my bugzilla install so that only those in a "quality assurance"
group can select "VERIFIED" or "CLOSED". If I recall, it wasn't difficult.
_______________________________________________
support-bugzilla mailing list
support-bugzilla@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-bugzilla
PLEASE put support-bugzilla@lists.mozilla.org in the To: field when you
reply.
-
Re: Security problem
Partho.Mukherjee@desconsoft.com wrote:
> Bill,
>
> You have mentioned that you had changed your Bugzilla installation to
> restrict permissions and verify/close permission was granted only to
> the QA team members. Can you please give me the detailed steps to
> achieve this. It would be very helpful.
Well, keeping in mind it has been awhile & I'm using Bugzilla 3.0 (while
I wait for Testopia to catch up with the current release), but as I
recall it simply entailed modifying the "check_can_change_field"
function in Bugzilla/Bug.pm ... inserting the code shown below between
the "WJD edit" comments at that location (also note that this newsreader
has wrapped some lines below that are on a single line in the actual code):
# Ignore the assigned_to field if the bug is not being reassigned
if ($field eq 'assigned_to'
&& $data->{'knob'} ne 'reassignbycomponent'
&& $data->{'knob'} ne 'reassign')
{
return 1;
}
# If the user isn't allowed to change a field, we must tell him who can.
# We store the required permission set into the $PrivilegesRequired
# variable which gets passed to the error template.
#
# $PrivilegesRequired = 0 : no privileges required;
# $PrivilegesRequired = 1 : the reporter, assignee or an empowered user;
# $PrivilegesRequired = 2 : the assignee or an empowered user;
# $PrivilegesRequired = 3 : an empowered user.
# WJD edit - restrict QA priv ("VERIFIED" or "CLOSED" status)
if ($field eq 'bug_status' && ($newvalue eq 'VERIFIED' || $newvalue
eq 'CLOSED')){
$$PrivilegesRequired = 3;
return $user->in_group('quality_assurance', $self->{'product_id'});
}
# end WJD edit
# Allow anyone with (product-specific) "editbugs" privs to change
anything.
if ($user->in_group('editbugs', $self->{'product_id'})) {
return 1;
}
Then just add the "quality_assurance" group to bugzilla & add whoever
you wish to that group.
Hope this helps you out ...
Bill Davis