2

I've been researching this problem for an hour now and it's getting kind of frustrating. I have a project in Bugzilla that I need to give read only access to some users (our BRM team). When I go to groups, I only see two checkboxes: "Can add to this group" and "member of this group". When I'm googling this, though, other people manage to have three checkboxes: "Can add to this group" "Is a private member (write access)" and "Is a public member (read access)". The post I saw with that info was from 2005, and we're on version 4.4.2 now.

Now maybe I'm using the wrong approach altogether. My current line of attack is to use the group memberships to make them simply a read only member of the group. But I'm open to any other possible way to accomplish this, including custom scripting.

  • I am not sure this is the right board for the question.. maybe worth moving? – ECiurleo Nov 27 '15 at 20:06
  • 1
    You know I'm the guy who determines whether or not they're on the right board, right? ;-) Kidding aside, Bugzilla is a bug tracking tool, and I'm trying to control access to the bugs. The tools we use for SQA purposes are well within the domain of this site. – corsiKa Nov 27 '15 at 20:21
  • @corsiKa what Bugzilla version? – user246 Nov 27 '15 at 22:02
  • Bugzilla version 4.4.2. – corsiKa Nov 27 '15 at 22:18
  • 2
    I fail to see how bug tracking tools are unreleated to testing. – corsiKa Jan 8 '16 at 15:51
1

This suggestion (and this seems to confirm this worked for someone else as well) to go into each product (in Administration) and uncheck 'Open for bug entry' to prevent entering new bugs, then (using the Edit Group Access Controls on that page) for each product set 'canedit' on for some group with no one in it (the explanation on that page says that there will be a limitation only if at least one of the checkboxes is set, which is slightly confusing).

I still have to confirm that this works myself though, particularly since I can't find anything that confirms this also blocks commenting.

0

Bugzilla is a rather old Perl project. Not that many people can hack Perl anymore. Last time I hacked some changes to heavily customize our Bugzilla, but I would prefer not to touch that code anymore.

When we needed similar functionality, instead of hacking Perl I used the FOSwiki bugzilla plugin and DB query plugin. It allowed me to define queries, displaying relevant data from Bugzilla in a series of wiki tables, and create a link to the full bugzilla page for updates (which required login).

We considered migrating from Bugzilla to Trac (which is in Python, our preferred language, and has tight integration to wiki for tech docs), but it is lot of hassle (because we heavily customized Bugzilla to fit our process, with more than dozen custom fields, and would need to redo the customization). And one of these days we will do it - but not yet. When we do, customizing it would be much more fun.

But it's amazing (for me) how these old Perl projects (Bugzilla, FOSwiki) continue to deliver value a decade later.

  • Another edit by Anand, again making post WORSE - this time removing the lint to Trac in wikipedia. Kate rejected that, I would do too. From edit review, from 9 edits of Anand, 8 were rejected. How we can stop such vandalism? – Peter M. - stands for Monica May 16 '16 at 14:30
0

You need to look at the Bugzilla site.

Group permissions are specified in the their documentation, section 3.10.4. Common Applications of Group Controls.

  • I've been through the docs on groups, but it's all about adding more permissions. I want to remove permissions. I can't seem to make it go "You can read what bugs are in it, but you can't make new ones". – corsiKa Nov 28 '15 at 0:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.