QA/Bugzilla/Administration

This page provides some information about the Administration of Bugzilla.

Introduction
If you have additional information, please document the steps carefully here.

Administrators
Need account help? Want to be added to the 'contributors' group so you can prioritize bugs? Please contact one of the primary admins via email or IRC:

(Admins Only: The complete list of Bugzilla Administrators is available here)

Deleting Attachments
In some very rare instances, we may need to delete attachments from Bugzilla.

We don't have a formal policy in place yet, but given that we provide users with multiple warnings about the license terms and public nature of attachments, we're only going to remove attachments if absolutely required.

Before deleting an attachment, please check the following:
 * 1) The request is coming from the same user who uploaded the document, or the clear rights-holder
 * 2) The attachment is not being referenced in other bug reports
 * 3) * This is important because we don't want to 'pull the rug out' from under other bugs and QA activity in Bugzilla

Gardening
Like thatching a lawn or pruning an orchard, it's important to do some periodic maintenance on our Bugzilla install lest it become overgrown, tangled, and unusable by QA or developers:
 * QA/Bugzilla/Gardening

Deleting Bugs
Bugs for deletion need to have the component 'deletionrequest'.

Actually deleting them

 * 1) Go through the list linked above and confirm that everything really needs to be deleted.
 * 2) * Often random bugs will show up with this component, and my general rule is that only bugs *clearly created for testing purposes* should be deleted.
 * 3) ** If a bug is invalid and bad, we can just leave it in that state for now.
 * 4) ** (If we end up with thousands and thousands of invalid bugs, we can have a discussion about if/when to delete them at a later date)
 * 5) Turn on bug deletion
 * 6) * Go here
 * 7) * Switch allowbugdeletion to 'On'
 * 8) Go to the deletionrequest component and click on 'Delete this component' at the bottom of the page
 * 9) You'll get a red Confirmation prompt along the lines of "There are 66 bugs entered for this component! When you delete this component, ALL stored bugs and their history will be deleted too."
 * 10) As long as everything looks kosher, click 'Yes, delete'.
 * 11) Now IMMEDIATELY turn OFF bug deletion (before you forget!)
 * 12) * Go here
 * 13) * Switch allowbugdeletion to 'OFF'
 * 14) You'll now need to recreate the deletionrequest component.
 * 15) * click here to add one
 * 16) * will give you the values for the fields.
 * 17) After component creation, double-check to make sure everything looks correct.

Deletionrequest default params
To recreate the component, you'll need these values:


 * Component: deletionrequest
 * Component Description: Select this Component for bugs what have been created only for testing Bugzilla or Bug Submission Assistant. Bugs with this component will be deleted from time to time. Details see here!
 * Default Assignee: libreoffice-bugs@lists.freedesktop.org
 * Default QA contact:
 * Default CC List:

Deleting User Accounts
Generally speaking, we avoid completely deleting user accounts and all the bugs, comments, and attachments provided, as those are often an important part of our QA process and are items on which we worked in good faith. What we can easily do (after account ownership verification) is to go in as an administrator and change a user's settings to something like: Login Name: removed_0001@example.net Real Name : -- removed -- Bugmail Disabled: [check the box]           # This will prevent most email from being sent Disable text: removed account               # This will prevent people from logging-in to the account

Default Assignees
It can be helpful to keep track of the default assignees by component:

Members of a group
Getting a list of all users of a particular group is pretty easy
 * Go to the Edit Users page
 * Restrict the search to the particular group in which you're interested

Sometimes you may want to further-restrict the search. So here's the basic search as you would run it as SQL:

(Note that even though one might not have the can-grant-privs flag set, if they are a Bugzilla admin, they'll have enough power to grant privs)

Events in chronological order
The web-based search tools are woefully inadequate for telling us information such as when did we first use the tag "needAdvice"?.

As a practical example, let's figure out who performed the 1000th bibisection (and labeled it as such in Bugzilla):


 * NOTE: bibisect information originally lived in the Whiteboard, but has now (mostly) migrated to Keywords.

Of course, these types of queries can only provide the basic data. For something like a bug with Keyword needAdvice, it's rather straight forward about the first time we used it (chronologically speaking), but for our bibisect query, one needs to look a bit further at the results and confirm that yes, bugs marked as bibisected are in fact actually bibisected, and so forth.

User Statistics
Who doesn't like stats? Here are some handy queries so I don't have to remember anything:

Bugzilla users who migrated with us from FDO
We've migrated to our own Bugzilla in January 2015, which will give us complete control over all aspects of the bug from FreeDesktop.org.

Based on some digging (bugzilla=# select distinct on (userid) userid, profiles_when from profiles_activity WHERE profiles_when < '2015-01-24' AND userid > 52705 limit 10;), it looks like user 52710 is the last user to sign up on FDO before the migration. So we can use that info to simplify our querying. ), so make that userid 52724
 * Further digging indicates that some people signed up on the 24th ( select * from profiles where cryptpassword = '!' and userid > 52710;

Here's a list of all users who signed-up on FDO, and have logged-in (i.e. reset their password) since the Jan 24th migration:

For 2014
Top 5 were:
 * 632
 * 127
 * 67
 * 66
 * 57

With names:

Grab out some comment information
Notes:
 * comment_id appears to be a unique value for each row in the longdescs table
 * Use same mechanism for counting bugs filed

Access Control
We try to keep as much of Bugzilla as open as possible.

We have made a few restrictions to various parts of Bugzilla, including adding access control onto the so-called "Importance" fields (Severity & Priority) to help us more effectively use those fields and have other teams (e.g. Development) put greater trust in the values present. For more information, see the links to each of the fields.

Severity
Using the 'blocker' level of Severity is off-limits for all. Technically speaking, admins have access, but as we don't actually use this level in our projects, admins should limit use to maintenance and testing only.

Priority
Access to the Priority field is restricted to admins and users in the 'Contributors' group. We consider this limitation a small "speed bump" to changing the value, ensuring that users have at least a modicum of information about QA before they try to triage the bug. See the Priority wiki page for more details.