Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
New to Bugzilla; Making private bugs
662 views
Skip to first unread message
Digimer
Sep 7, 2013, 12:41:18 AM9/7/13
to support-...@lists.mozilla.org
Hi all,
First off; Thanks to the community for creating Bugzilla and for
having good install docs! I've got it installed and working well thanks
to the docs. :)
I have a small company that also sponsors an set of open source
projects. I want to use bugzilla to track issues coming from the
community and from out (paying) customers. The latter means that we need
to be careful about exposing private data, so we need the ability to
flag certain bugs as private.
We chose bugzilla because of how well we've seen this work for Red
Hat. I've been poking around and have looked into the docs, but I can't
see how to do this. Do I need an extension or something to enable
support for marking bugs as private? Specifically, I want to be able to
flag certain users as "staff" and then make a private bug visible to
staff, the submitter and users we specifically grant access to that bug.
Is this even possible?
Cheers!
--
Digimer
Papers and Projects: https://alteeve.ca/w/
What if the cure for cancer is trapped in the mind of a person without
access to education?
First off; Thanks to the community for creating Bugzilla and for
having good install docs! I've got it installed and working well thanks
to the docs. :)
I have a small company that also sponsors an set of open source
projects. I want to use bugzilla to track issues coming from the
community and from out (paying) customers. The latter means that we need
to be careful about exposing private data, so we need the ability to
flag certain bugs as private.
We chose bugzilla because of how well we've seen this work for Red
Hat. I've been poking around and have looked into the docs, but I can't
see how to do this. Do I need an extension or something to enable
support for marking bugs as private? Specifically, I want to be able to
flag certain users as "staff" and then make a private bug visible to
staff, the submitter and users we specifically grant access to that bug.
Is this even possible?
Cheers!
--
Digimer
Papers and Projects: https://alteeve.ca/w/
What if the cure for cancer is trapped in the mind of a person without
access to education?
Digimer
Sep 7, 2013, 1:22:43 AM9/7/13
to support-...@lists.mozilla.org
On 07/09/13 00:41, Digimer wrote:
> Hi all,
>
> First off; Thanks to the community for creating Bugzilla and for
> having good install docs! I've got it installed and working well thanks
> to the docs. :)
>
> I have a small company that also sponsors an set of open source
> projects. I want to use bugzilla to track issues coming from the
> community and from out (paying) customers. The latter means that we need
> to be careful about exposing private data, so we need the ability to
> flag certain bugs as private.
>
> We chose bugzilla because of how well we've seen this work for Red
> Hat. I've been poking around and have looked into the docs, but I can't
> see how to do this. Do I need an extension or something to enable
> support for marking bugs as private? Specifically, I want to be able to
> flag certain users as "staff" and then make a private bug visible to
> staff, the submitter and users we specifically grant access to that bug.
> Is this even possible?
>
> Cheers!
Woops, I should have mentioned;
> Hi all,
>
> First off; Thanks to the community for creating Bugzilla and for
> having good install docs! I've got it installed and working well thanks
> to the docs. :)
>
> I have a small company that also sponsors an set of open source
> projects. I want to use bugzilla to track issues coming from the
> community and from out (paying) customers. The latter means that we need
> to be careful about exposing private data, so we need the ability to
> flag certain bugs as private.
>
> We chose bugzilla because of how well we've seen this work for Red
> Hat. I've been poking around and have looked into the docs, but I can't
> see how to do this. Do I need an extension or something to enable
> support for marking bugs as private? Specifically, I want to be able to
> flag certain users as "staff" and then make a private bug visible to
> staff, the submitter and users we specifically grant access to that bug.
> Is this even possible?
>
> Cheers!
4.4 on CentOS 6.4. All modules installed;
===============
* This is Bugzilla 4.4 on perl 5.10.1
* Running on Linux 2.6.32-358.18.1.el6.x86_64 #1 SMP Wed Aug 28 17:19:38
UTC 2013
Checking perl modules...
Checking for CGI.pm (v3.51) ok: found v3.63
Checking for Digest-SHA (any) ok: found v5.47
Checking for TimeDate (v2.23) ok: found v2.24
Checking for DateTime (v0.28) ok: found v1.03
Checking for DateTime-TimeZone (v0.71) ok: found v1.60
Checking for DBI (v1.54) ok: found v1.609
Checking for Template-Toolkit (v2.22) ok: found v2.25
Checking for Email-Send (v2.04) ok: found v2.199
Checking for Email-MIME (v1.904) ok: found v1.924
Checking for URI (v1.37) ok: found v1.60
Checking for List-MoreUtils (v0.32) ok: found v0.33
Checking for Math-Random-ISAAC (v1.0.1) ok: found v1.004
Checking available perl DBD modules...
Checking for DBD-Pg (v2.7.0) ok: found v2.15.1
Checking for DBD-mysql (v4.001) not found
Checking for DBD-SQLite (v1.29) not found
Checking for DBD-Oracle (v1.19) not found
The following Perl modules are optional:
Checking for GD (v1.20) ok: found v2.44
Checking for Chart (v2.1) ok: found v2.4.6
Checking for Template-GD (any) ok: found v1.56
Checking for GDTextUtil (any) ok: found v0.86
Checking for GDGraph (any) ok: found v1.48
Checking for MIME-tools (v5.406) ok: found v5.504
Checking for libwww-perl (any) ok: found v6.05
Checking for XML-Twig (any) ok: found v3.34
Checking for PatchReader (v0.9.6) ok: found v0.9.6
Checking for perl-ldap (any) ok: found v0.40
Checking for Authen-SASL (any) ok: found v2.13
Checking for Net-SMTP-SSL (v1.01) ok: found v1.01
Checking for RadiusPerl (any) ok: found v0.23
Checking for SOAP-Lite (v0.712) ok: found v1.06
Checking for JSON-RPC (any) ok: found v1.03
Checking for JSON-XS (v2.0) ok: found v2.34
Checking for Test-Taint (any) ok: found v1.06
Checking for HTML-Parser (v3.40) ok: found v3.64
Checking for HTML-Scrubber (any) ok: found v0.09
Checking for Encode (v2.21) ok: found v2.35
Checking for Encode-Detect (any) ok: found v1.01
Checking for Email-Reply (any) ok: found v1.203
Checking for HTML-FormatText-WithLinks (v0.13) ok: found v0.14
Checking for TheSchwartz (any) ok: found v1.10
Use of uninitialized value $ENV{"FLOCK_FORKING_USE"} in string eq at
/usr/local/share/perl5/File/Flock/Forking.pm line 13, <DATA> line 522.
Checking for Daemon-Generic (any) ok: found v0.83
Checking for mod_perl (v1.999022) ok: found v2.000004
Checking for Apache-SizeLimit (v0.96) ok: found v0.96
Checking for File-MimeInfo (any) ok: found v0.18
Checking for IO-stringy (any) ok: found v2.110
Checking for mod_headers (any) ok
Checking for mod_expires (any) ok
Checking for mod_env (any) ok
Reading ./localconfig...
Checking for DBD-Pg (v2.7.0) ok: found v2.15.1
Checking for PostgreSQL (v8.03.0000) ok: found v08.04.1300
===============
Dave Miller
Sep 7, 2013, 1:24:50 AM9/7/13
to support-...@lists.mozilla.org
Digimer wrote:
> We chose bugzilla because of how well we've seen this work for Red
> Hat. I've been poking around and have looked into the docs, but I
> can't see how to do this. Do I need an extension or something to
> enable support for marking bugs as private? Specifically, I want to
> be able to flag certain users as "staff" and then make a private bug
> visible to staff, the submitter and users we specifically grant
> access to that bug. Is this even possible?
Yep. In the admin section there's a page for Groups. Create a group
> We chose bugzilla because of how well we've seen this work for Red
> Hat. I've been poking around and have looked into the docs, but I
> can't see how to do this. Do I need an extension or something to
> enable support for marking bugs as private? Specifically, I want to
> be able to flag certain users as "staff" and then make a private bug
> visible to staff, the submitter and users we specifically grant
> access to that bug. Is this even possible?
for private bugs. Make sure "Use for bugs" is checked.
Then in the Product editor, for each product you want to use it in, you
need to go into "Group Controls" and enable that group on the product.
There's a variety of ways to set it, depending on what you want. The
docs for it are right there on that page when you're editing it.
In the user editor, you can give users access to the group.
On bugzilla.mozilla.org we had to hook the enter_bug form with an
extension to let people who weren't in the group file bugs into it. I'm
not sure if that's still required, someone who's played with that more
recently than me can hopefully pipe up and let us know. :)
--
Dave Miller http://www.justdave.net/
IT Infrastructure Engineer, Mozilla http://www.mozilla.org/
Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/
Digimer
Sep 7, 2013, 1:58:04 AM9/7/13
to Dave Miller, support-...@lists.mozilla.org
On 07/09/13 01:24, Dave Miller wrote:
> Digimer wrote:
>> We chose bugzilla because of how well we've seen this work for Red
>> Hat. I've been poking around and have looked into the docs, but I
>> can't see how to do this. Do I need an extension or something to
>> enable support for marking bugs as private? Specifically, I want to
>> be able to flag certain users as "staff" and then make a private bug
>> visible to staff, the submitter and users we specifically grant
>> access to that bug. Is this even possible?
>
> Yep. In the admin section there's a page for Groups. Create a group
> for private bugs. Make sure "Use for bugs" is checked.
>
> Then in the Product editor, for each product you want to use it in, you
> need to go into "Group Controls" and enable that group on the product.
> There's a variety of ways to set it, depending on what you want. The
> docs for it are right there on that page when you're editing it.
>
> In the user editor, you can give users access to the group.
>
> On bugzilla.mozilla.org we had to hook the enter_bug form with an
> extension to let people who weren't in the group file bugs into it. I'm
> not sure if that's still required, someone who's played with that more
> recently than me can hopefully pipe up and let us know. :)
Excellent! A test bug is now not visible to a user who isn't logged in.
> Digimer wrote:
>> We chose bugzilla because of how well we've seen this work for Red
>> Hat. I've been poking around and have looked into the docs, but I
>> can't see how to do this. Do I need an extension or something to
>> enable support for marking bugs as private? Specifically, I want to
>> be able to flag certain users as "staff" and then make a private bug
>> visible to staff, the submitter and users we specifically grant
>> access to that bug. Is this even possible?
>
> Yep. In the admin section there's a page for Groups. Create a group
> for private bugs. Make sure "Use for bugs" is checked.
>
> Then in the Product editor, for each product you want to use it in, you
> need to go into "Group Controls" and enable that group on the product.
> There's a variety of ways to set it, depending on what you want. The
> docs for it are right there on that page when you're editing it.
>
> In the user editor, you can give users access to the group.
>
> On bugzilla.mozilla.org we had to hook the enter_bug form with an
> extension to let people who weren't in the group file bugs into it. I'm
> not sure if that's still required, someone who's played with that more
> recently than me can hopefully pipe up and let us know. :)
So I suppose then that I will need to create a group for each client and
add the accounts associated with that client part of the group. Then use
the client-specific private function? Or is there a way to selectively
add a given user to a bug that is otherwise private?
Thanks for such a quick reply!
Dave Miller
Sep 7, 2013, 3:40:02 AM9/7/13
to support-...@lists.mozilla.org
Digimer wrote:
> So I suppose then that I will need to create a group for each client
> and add the accounts associated with that client part of the group.
> Then use the client-specific private function? Or is there a way to
> selectively add a given user to a bug that is otherwise private?
By default if you add a user to the CC list on a bug, they'll be able to
> So I suppose then that I will need to create a group for each client
> and add the accounts associated with that client part of the group.
> Then use the client-specific private function? Or is there a way to
> selectively add a given user to a bug that is otherwise private?
see it. The reporter can always see bugs they report, and the assignee
can always see bugs they're assigned to, regardless of group settings on
the bug.
If you plan to make groups for more than one classification of person,
what I recommend doing is have no members at all in the groups that you
use to restrict bugs, and create additional separate groups that
classify groups of people, such as one for your staff, one for each
client, etc. On those groups, you leave the "use for bugs" option
unchecked. Then you create separate groups with "use for bugs" enabled,
that you use to actually restrict the bugs, and use the group
inheritance feature to make your people groups be members of the
appropriate bug groups.
That way you can have a bug group for "Client A's custom project" for
example, and both Client A's staff and your own staff can see the bugs
because the Client A Staff group and your Our Staff group are both
members of it.
Digimer
Sep 7, 2013, 9:37:18 AM9/7/13
to Dave Miller, support-...@lists.mozilla.org
On 07/09/13 03:40, Dave Miller wrote:
> Digimer wrote:
>> So I suppose then that I will need to create a group for each client
>> and add the accounts associated with that client part of the group.
>> Then use the client-specific private function? Or is there a way to
>> selectively add a given user to a bug that is otherwise private?
>
> By default if you add a user to the CC list on a bug, they'll be able to
> see it. The reporter can always see bugs they report, and the assignee
> can always see bugs they're assigned to, regardless of group settings on
> the bug.
>
> If you plan to make groups for more than one classification of person,
> what I recommend doing is have no members at all in the groups that you
> use to restrict bugs, and create additional separate groups that
> classify groups of people, such as one for your staff, one for each
> client, etc. On those groups, you leave the "use for bugs" option
> unchecked. Then you create separate groups with "use for bugs" enabled,
> that you use to actually restrict the bugs, and use the group
> inheritance feature to make your people groups be members of the
> appropriate bug groups.
>
> That way you can have a bug group for "Client A's custom project" for
> example, and both Client A's staff and your own staff can see the bugs
> because the Client A Staff group and your Our Staff group are both
> members of it.
Awesome! Thank you very much, specially for such quick replies on a weekend!
> Digimer wrote:
>> So I suppose then that I will need to create a group for each client
>> and add the accounts associated with that client part of the group.
>> Then use the client-specific private function? Or is there a way to
>> selectively add a given user to a bug that is otherwise private?
>
> By default if you add a user to the CC list on a bug, they'll be able to
> see it. The reporter can always see bugs they report, and the assignee
> can always see bugs they're assigned to, regardless of group settings on
> the bug.
>
> If you plan to make groups for more than one classification of person,
> what I recommend doing is have no members at all in the groups that you
> use to restrict bugs, and create additional separate groups that
> classify groups of people, such as one for your staff, one for each
> client, etc. On those groups, you leave the "use for bugs" option
> unchecked. Then you create separate groups with "use for bugs" enabled,
> that you use to actually restrict the bugs, and use the group
> inheritance feature to make your people groups be members of the
> appropriate bug groups.
>
> That way you can have a bug group for "Client A's custom project" for
> example, and both Client A's staff and your own staff can see the bugs
> because the Client A Staff group and your Our Staff group are both
> members of it.
I am certain I'll have more questions later, but for now I think I'm
good to go. :)
0 new messages