BMO/Requesting Changes

This page details the information you need to provide in order to get speedy resolution to requests to change the configuration of bugzilla.mozilla.org. The BMO administration team aims to turn around all correctly-specified requests in 1 business day, however some changes made take longer (due to development effort required).

In general, the more significant a change you want to make, the more likely it is that you will need to provide evidence of discussion and consensus around the change.

Additions

File a bug, providing:

Products

• (required) The name of the product
• (required) The classification (group) you would like the product in
• (required) A longer description, usually including a web link for more info on the product
• (required) The initial list of components, with their info (see below)
• (required) The security group(s) bugs should be classified under when a user checks the security flag (if you don't know, we can help figure this out for you)
• (optional) A template (in markdown) for bugs in the new product (this can be overriden at the component level)
• (optional) The initial list of versions, with their info (see below)
• (optional) The initial list of target milestones, with their info (see below)
• (optional) The number of votes needed to confirm a bug (UNCO --> NEW) (disabled by default)
• (optional) If you want review requests to require a reviewer (false by default)
• (optional) The list of suggested reviewers for the review flag (empty by default)
• (optional) The number of days until a review/needinfo/feedback is considered "overdue" and will trigger a reminder email (default 7 days)
• (optional) Any flags you want visible on the product (this can be per-component, or product-wide).

Components

• (required) The name of the component
• (required) The product it should go in
• (required) A longer description
• (required) A triage lead, responsible for making decisions on NEW bugs in the component (optional if not a Firefox component, but recommended)
• (optional) A template (in markdown) for new bugs in the component. If this is specified, it will override the template for the parent product if one exists
• (optional) It's highly recommended that the default assignee for new bugs is 'nobody@mozilla.org', however this can be changed if required
• (optional) Normally the "QA Contact" is empty, but you can optionally set it to a specific individual
• (optional) Any flags (bug and/or attachment) that will need to be visible for bugs against the new component

Triage lead, QA contact, and recommended viewers should all be bugmail addresses, so check against Mozillians, Phonebook, or ask to make sure you have the right email.

Bug Templates

You can specify, at the product and component level, a template for new bugs. The template should be in Markdown and should ask for information and steps specific to the product or component.

If a product has a bug template, all new bugs in the product will display the template, unless the template is overridden at the component level.

If a component has a bug template, all new bugs in the component will display that template, overriding any product level components template.

Versions

• (required) The name of the version
• (required) The product it should go in

Target Milestones

• (required) The name of the target milestone
• (required) The product it should go in

Custom Fields

Adding new custom fields is not something we can do easily, so we try to be careful about adding them. They add more complexity to the UI, and carry an overhead for all bugs on the system, regardless of their visibility. You'll need to make your case before a custom field can be added. Generally, if a custom field is very specific to one niche area and do not concern the Project as a whole, we encourage the use of status whiteboard markers or other existing fields.

• (required) The name of the field
• (required) A longer description
• (required) The type (Bug ID, Large Text Box, Free Text, Multiple Selection Box, Single Selection Box or Date/Time)
• (required) The initial set of values, if Multiple or Single Selection Box
• (required) The product(s) it should show up in
• (required) Whether it can be set on bug creation

Keywords

Keywords are a faster and typo-free alternative to using whiteboard tags. In order to create one we'll need:

• (required) The name of the keyword
• (required) The description to use

Additional Field Values

This could be Hardware or OS.

• (required) The value to be added
• (required) The field it should be added to

Flags

• (required) The name of the flag
• (required) A longer description
• (required) Which products/components the flag should appear in
• (required) Whether the flag applies to bugs or attachments
• (required) Whether the flag is requestable (i.e. users can ask for flags of this type to be set)
• (required) Whether the flag should be requested from a specific person
• (required) Whether the flag can be set multiple times
• (optional) If flags of this type are requestable, the group allowed to request them, if any
• (optional) The group allowed to grant/deny flags of this type, if any
• (optional) CC list for request notifications, if any (not recommended, use component watching)

Users

Users can sign up for accounts themselves.

Statuses and Resolutions

Changing the Bugzilla workflow is a big deal, and is very unlikely to happen without serious discussion. If you don't know whether you are authorised to make this sort of change, you aren't.

Security Groups

• Security groups are rarely granted explicitly into. Normally the groups membership is determined by inheritance from other groups.
• Most security groups have a related "-team" group that is used for actually granting people into. For example, no one is in the 'client-services-security' group directly. There is a 'client-services-security-team' group which is a member of the 'client-services-security' group. The individual users are placed directly into the 'client-services-security-team' group when needed. Therefore they get access to the other group as well through inheritance. Only the 'client-services-security' group should be actually visible on the bug report.

Information Needed

• Name for the new group.
• Which products need to have the new group enabled.
• Whether a specific account or mailing list should be automatically cc'ed when a bug is placed in the new group (optional).
• List of users to be placed in the new team group initially.
• Who should be the admin for the new group (bless rights) that will be able place others in the team group (optional).

Changes

Triage Owner

To change a component's triage owner file a bug with the details of the product, component, and new owner. Note a triage owner must be an individual (not a group), and they won't automatically have access to security bugs filed in components.

Changing Product, Component, Version or Milestone Name

Bugzilla uses integer mappings internally for mapping IDs to human readable names such as Product, Component, etc. But when creating store queries in the form of a URL or when specifying a product to file a bug against, it doesn't use the ID, it uses the name. When a textual name is changed in BMO using the admin UI to something else, Bugzilla continues to work properly as it still uses the same ID everywhere internally and in the database. But if a stored query or a URL has been passed around to others via a wiki page, mailing list, etc. then the URL will no longer be valid. Users will need to update their queries and revise and relevant documentation to reflect the name change. Bugzilla, and BMO for that matter, does not support aliasing of the new name to any old names so that the old queries will continue to work. BMO admins will try harder to remind requesters that these issues may arise when making these types of name changes.

Note that this also affects BzAPI or the newer native REST API in that you will need to update the search parameters for bug searches to reflect the name changes as well.

=

Suggested Reviewers

A curated list of users can be suggested when the review flag is set for a patch, to aid new contributors in picking a reviewer. These suggested reviewers can be set globally for a product, or on a per-component basis. For the current list of users, see the suggested reviewers report.

Usernames and Passwords

Users can change their own username (email address) or password in the preferences. Changing your own email address is greatly preferred to creating a new account and then asking for a merge. If you have already created a new account but have not yet used it, then change its username to something bogus (i.e. abandon it), and change the username on your old account to the new one.

If you do need two accounts merged, and both have activity you don't want to lose, you will need to file a bug (see above).

Retiring Products and Components

Products and components aren't deleted from Bugzilla, since the records of their bugs or the work done on them may be useful. Instead, usually they are changed to disable the creation of new bugs in their category. They can also be moved to a "Graveyard" area.

Here's how to retire components and products.

User Permissions

For common user permissions, i.e. canconfirm and editbugs, please see the [instructions on BMO itself https://bugzilla.mozilla.org/page.cgi?id=get_permissions.html]. For other permissions, e.g. security groups, please file a confidential bug or contact the BMO team.

Disablings

Users

Email bugzilla-admin@mozilla.org giving sufficient evidence of violation of Mozilla policies or community norms.

Target Milestones

Old target milestones are normally disabled by the team at some point after the release has happened. This means that they can't be selected on bugs (although they will continue to show up if that's the current value) and you have to use the Boolean Charts to search for them.

Deletions

Things in Bugzilla rarely get deleted. Many things can be disabled (see above) instead. You should not expect deletions to happen fast. It's probably best to file a bug explaining what you need deleted and why, and expect questions.

Attachments

If you add an attachment and then realise it contains confidential or personal information, file a bug and it can be manually annulled. (The attachment links and name will remain, but the data will be removed.)

Users

We don't delete accounts because that would be messing with the historical record. However, users can disable all their bug mail in their preferences if they would like to stop hearing from Bugzilla, and they may change their email address to an inactive or throwaway one if they wish.