Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Table of contents


The Basics

What is Red Hat Bugzilla Stage?

Red Hat Bugzilla Stage is a customized version of the Open Source Bugzilla software, a mature and widely-used bug-tracking system. The first version of Red Hat Bugzilla Stage was deployed on 1 November 1998 and since then has become an integral part of Red Hat's development and release processes, with the majority of Red Hat's products relying on Bugzilla, alongside several large community projects, including the Fedora Project. Red Hat Bugzilla is one of the world's largest Bugzilla installations, housing over two million bugs reports.

There is an internal FAQ available for Red Hat users

Who maintains Red Hat Bugzilla Stage?

Red Hat Bugzilla Stage is maintained by the Portfolio Life Cycle Management team.

What are the major differences between the vanilla upstream Bugzilla and Red Hat Bugzilla Stage

Red Hat Bugzilla Stage has a very long list of customizations to support various Red Hat-specific and/or Fedora-specific workflows. Red Hat Bugzilla Stage provides a number of additional fields that are not provided by the upstream Bugzilla, has different behavior for certain fields, and uses a different set of bug life cycle states. Red Hat Bugzilla Stage also provides a number of Red Hat-specific extensions, such as the ability to assign a bug to sub-components, and the Red Hat Bugzilla Stage Rules Engine, which can be used to automate parts of the bug life cycle.

Where is the source code?

Red Hat Bugzilla Stage is developed internally and the source code for changes is not publicly available until the release is deployed to the production site. After deployment the source code is pushed to Fedora Pagure.

Getting started

How do I get an account on Red Hat Bugzilla Stage?

If you have an account with one of the SAML providers supported by Red Hat Bugzilla Stage then you can simply login and if an account is not found to match your login then a basic account will be automatically created for you.

You can sign-up for an account by visiting the New Account page and following the instructions provided there. You will need to provide a valid email address to complete the sign-up process. Your new account will have basic privileges -- you will be able to view and comment on public bugs and to file new bugs against public products.

If you are employed by a Red Hat partner company, your employer may grant you membership of their confidential group. Talk to you Partner Manager if you require more details about this.

If you are employed by Red Hat, you may require additional privileges depending on your role within the company. See the section on Access Control below for more detail. Once you have completed the sign-up process using your Red Hat email address, you must go to the Group Membership Request form and apply for the groups you require.

Getting Help

How do I contact Red Hat about Bugzilla?

See the Contact page

Where can I submit feature requests and bug reports?

Bug reports and feature requests for Red Hat Bugzilla Stage can be submitted to itself.

Where can I submit administrative requests?

Users can submit an administrative request by sending an email to the maintainers.

Where can I ask for help with Red Hat Bugzilla Stage?

Internal users can ask questions about Red Hat Bugzilla Stage in #bugzilla on the internal IRC or email bugzilla-list@redhat.com.

External users can ask questions about Red Hat Bugzilla Stage in #bugzilla on irc.libera.chat or email the maintainers. Please note that this is the IRC channel for upstream Bugzilla, not just for Red Hat Bugzilla Stage.

How do I report spam?

Red Hat has no tolerance for spammers and our admins have tools to quickly deal with spam accounts.

If an account is spamming please submit an administrative request by sending an email to the maintainers. Please include the bug and comment numbers.

Alternatively if you are logged in to your Red Hat Bugzilla Stage account you can click the report spam icon in the header bar of each comment, this will display a form that can be filled in to report SPAM. Reporting SPAM this way will also tag the comment as SPAM, this will cause the comment to be collapsed by default when you reload the bug.

Is there anything I can do about spam?

Red Hat Bugzilla has an Anti-Spam extension enabled that allows users to tag comments as 'spam'. If enough comments are tagged this way an account will be automatically suspended. There are limits on this system. You must be a member of the community group for your tag to count, and members of the community group are immune to having their account suspended this way. If a member of the community is spamming you will need to report them as per the question above.

This system also supports tagging comments as 'abuse' or 'abusive', there are the same constraints and exceptions as noted above.

Tagging a comment as sam is part of the in-page SPAM reporting detailed in How do I report spam? above.

Using Red Hat Bugzilla Stage

What makes a good bug report?

This topic is covered in detail in the Bug Writing Guidelines.

What makes a good feature request?

Describe what you want the proposed feature to achieve, rather than proposing a particular implementation (implementation choices should be left to the Red Hat Bugzilla Stage developers). Explain the expected benefits of the proposed feature, as this helps with prioritization.

Why doesn't Red Hat Bugzilla Stage allow bugs to be unassigned?

By requiring that every bug has an assignee, Red Hat Bugzilla Stage is making the responsibility for triaging and prioritizing the bug clear. If bugs were allowed to be unassigned, that responsibility would not be clear and it is likely that some high-priority bugs would not receive attention as quickly as they should.

Why does a bug have to have a component?

Bugzilla uses the component (or the sub-component, if set) to determine who to assign a bug to and who to notify of the bug's creation. Without an assignee and notifications, a new bug would be less likely to be noticed, triaged and fixed as the responsibility for doing so would not be clear.

Are there any test instances of Red Hat Bugzilla Stage where I can experiment safely?

Yes. There is a public-facing staging server.This system is completely separate from the production system and contain out-of-date snapshots of the production database, which are refreshed once or twice per year. You can use these systems to experiment with Red Hat Bugzilla Stage and to test RPC scripts, though you should be aware that any changes you make in the public-facing staging server may still be visible to people outside Red Hat. Note also that these machines do not send bug mail, so any changes you make will not cause users to receive notification emails. You sign up for a new account using the normal process.

Can I send email to Red Hat Bugzilla Stage?

Yes. To open bugs and to respond to bug mail you will require a PGP key set in your user preferences.

Once your PGP key is set in your user preferences you simply email the appropriate address using the documented format. For bug mail you can simply reply to the email. When replying to bug mail please ensure you remove any text that is not required in your reply. Doing so helps ensure that comments remain readable.

The email address for the production instance is bugzilla@redhat.com and the email address for the stage instance is bugzilla+stage@redhat.com.

Authenticating with Bugzilla

@redhat.com accounts cannot change their email address used in Bugzilla. These accounts will need to email the maintainers to have their Bugzilla login changed if necessary to meet any of the requirements noted below.

password

@redhat.com accounts cannot use password authentication.

Red Hat Bugzilla Stage is using zxcvbn, a realistic password strength estimator, to estimate password strength. As you enter your password the strength meter will update to indicate the strength of your password. The strength needs to be 'Strong' to be accepted.

The client and server have slightly different implementations of this feature. It is possible that some passwords that are rated strong in the client are rated good on the server. In such cases you will need to make your password slightly more complex for it to be accepted on the server.

pin+token

Only @redhat.com accounts can use this method.

Bugzilla is integrated with info-sec's PrivacyIDEA service. PrivacyIDEA is a modern replacement for RADIUS.

This service uses your pin+token in the password field in the login form. You do not need to do anything special for this service to be used, just login using pin+token as your password and PrivacyIDEA will be used.

This service requires your Bugzilla email address to match your keberos uid.

e.g. jfearn@redhat.com

It supports + based addresses, as long as the start of the address is your keberos uid.

e.g. jfearn+testaccount@redhat.com

The Red Hat Internal (Associate) SSO

Only @redhat.com accounts can use this method.

If your Bugzilla account is mapped to your LDAP account then the mail addresses are not checked. You will simply be logged in.

Mapping is when the Bugzilla account's external_id field is set to your rhatUUID from LDAP.

Mapping happens automatically when you first successfully login using the Internal SSO.

When you attempt to login using this service and your account isn't mapped Bugzilla compares the Bugzilla account's email address to 3 LDAP fields. If it finds a match it will log you in and map the account.

The 3 LDAP fields checked are: rhatPreferredAlias, then rhatPrimaryMail, then mail.

rhatPreferredAlias can be set in rover.

Mapping can be set manually by a Bugzilla admin, email the maintainers if you are having issues logging in with this service and require assistance. Ensure you include you kerberos uid and your Bugzilla account login.

The Red Hat External (Customer) SSO

To use this method you must have a Red Hat account.

Accounts in the admin, security and qe_staff groups can only use this service if they have linked their account to the Associate SSO.

The mail address used in the External SSO account must match the mail address used in Bugzilla.

If this is not the case then you will not be able to authenticate using the External SSO.

The Fedora SSO

@redhat.com accounts cannot use the Fedora SSO.

The mail address used in the Fedora SSO account needs to match the mail address used in Bugzilla.

If this is not the case then you will not be able to authenticate using the Fedora SSO.

Access control

Are all bugs public?

No. The majority of bugs in Red Hat Bugzilla Stage are public, but some bugs are private to specific groups of users. These are typically:

What determines whether a bug is public?

Each bug has zero or more groups assigned when a bug is created. Usually the groups are assigned by the reporter of the bug, but in a few cases are assigned automatically (e.g. all RHEL kernel bugs go in the 'redhat' group if the user assigns no groups).

If a bug belongs to no groups, it is public. If a bug belongs to one or more groups, it is not public.

How does Bugzilla decide which bugs I can view?

All users can view public bugs, even when not logged in. To view a non-public bug, you must be logged into Bugzilla and you must either belong to one or more of the bug's groups or you must have a direct association with the bug by being it's Reporter, Assignee, QA Contact, Docs Contact or a member of its CC-list. You are considered to be a member of a group if you have been placed directly in that group or if you inherit the group via another of your groups. For example, all members of the 'redhat' group inherit membership of the 'private_comments' group.

How does Bugzilla decide which bugs I can edit?

To comment on a bug, you must be logged in and you must be able to view the bug.

To edit most other fields of a bug, you must be a member of a group that has 'editbugs' on the bug's product.

How does Bugzilla decide which fields I can view/edit?

Red Hat Bugzilla carries an extension that allows custom fields to have view, edit, and admin rights. If there is a fields you think you should be able to access that you can't then you may be missing a group membership.

Comments may be marked as Private. Private comments are only visible to members of the 'redhat' group and the members of any "extra private groups" if there are any set on the comment.

How do I get privileges to see Security Restricted bugs?

Access to Security Restricted bugs is granted on a need-to-know basis. If the Product Security Team decides that you need to know about a specific Security Restricted bug, they will grant you access to thatbug.

Which bugs are indexed by search engines?

Only public bugs are indexed by search engines, and only the public fields of those bugs are visible to search engines.

Can I have more than one Red Hat Bugzilla Stage account?

Yes. The two accounts must have valid and distinct email addresses.

Can my account be deleted if I don't want to use it anymore?

Please read the 'Delete Account' section on the Privacy tab in your preferences to know the state of your account.

How do I make a GDPR request?

Please read the 'GDPR Process' section on the Privacy tab to find out these details.

Can I change the email address associated with my Bugzilla account?

External users (i.e. non-@redhat.com) can do this for themselves via the User Preferences page. The user will have to confirm that the new address is valid.

Due to information security requirements, users with @redhat.com addresses cannot change their account's email address for themselves. You need to request this change by filing a ticket via the maintainers. The new email address will still have to be an @redhat.com address.

Can I keep using my @redhat.com Bugzilla account when I leave Red Hat?

No. Your account potentially has access to confidential bug information that you will no longer be permitted to view. When you leave Red Hat, your Bugzilla account will be disabled. If you wish to keep using Red Hat Bugzilla Stage after you leave Red Hat, you must create a new account using a non-redhat.com email address.

Can my old Bugzilla account be reactivated if I leave the company and later rejoin?

Yes. Red Hat Bugzilla Stage accounts are disabled when an employee leaves the company, but are not deleted. If an employee rejoins the company their Red Hat Bugzilla Stage account can be re-activated and they can resume using it. Note however that any groups the user previously had will have been revoked when the account was disabled and the user must request access to the groups that are relevant to their new job description.

Flags

What are Bugzilla flags?

Flags are used extensively in Red Hat Bugzilla Stage. Flags are mostly associated with bugs, but a few flags can also be associated with attachments. The set of flags that may appear on a bug are determined by the configuration of the Product that the bug has been filed against. Some flags apply to virtually all products (e.g. needinfo) while others apply to groups of products (e.g. the blocker flag used by RHEL), and still other flags apply to just one product (e.g. release flags such as bugzilla-5.0). Most flags have four possible states: unset (in which case the flag is not shown), requested (shown as ?), approved (shown as +) and denied (shown as -). Most flags can only be set once per bug, but a few can be set multiple times (e.g. needinfo and docs_scoped). A few flags can be requested of a specific user (e.g. needinfo and review).

How do flag permissions work?

Each flag has three associated groups, which define who can view the flag, who can request the flag (i.e. set its state to ?) and who can grant or deny the flag (i.e. set its state to + or -). Most flags are restricted to a subset of Bugzilla users, but for some flags one or more of those groups may be set to include all users.

Why is needinfo a flag rather than a state?

Needing information is orthogonal to the life cycle state of a bug. It is perfectly valid to ask for extra information about any bug, even after the bug has been closed.

Searching

Can I save a query for later use?

Yes. When you are viewing the results of a search, you can save the search criteria with a meaningful name by using the "Remember search as" box at the bottom of the page.

Can I share my saved searches with other users?

Yes, there are two ways to do this. Firstly, you can share a saved search with a Bugzilla group. This will make the search show up in the Bugzilla page footer for all members of that group (to the right of the My Bugs link), so you should carefully consider whether the members of the group will find the search useful. Secondly, you can copy the search URL and embed it in emails or documents.

Are search URL's persistent? Can I paste them into a wiki?

Yes. Search URLs include the search criteria and can be shared. Be aware however that opening a search URL will run the search again and may therefore produce different results if the data in Bugzilla has changed.

Why do two users running the same search receive different results?

Bugzilla searches will only return bugs that you have permission to view. If two users with different group permissions run the same search, they may therefore see different sets of matches.

My search takes too long, How can I make it faster?

Red Hat Bugzilla Stage contains more than two million bugs, so searching can take a long time, particularly if you are searching against the bug title or comments. You can speed up searches quite significantly by narrowing the search criteria to a subset of the available classifications, products, components or bug states.

What is 'whining'?

Whining is a feature of Bugzilla that lets you schedule a saved search to be run at intervals of between fifteen minutes and one month and have the results emailed to you.

If you are a member of the 'bz_canusewhines' group, you can schedule one or more whines by clicking the Administration link in the page header or footer, then clicking the Whining link in the following page. Additionally, if you are a member of the 'bz_canusewhineatothers' group, you can also send the results to other users. Members of the 'redhat' groups automatically inherit both bz_canusewhines and bz_canusewhineatothers.

The Bugzilla Rules Engine

What is the Bugzilla Rules Engine?

The Bugzilla Rules Engine is a replacement for the old Bugbot service. Each product can specify which BRE Group it belongs to and edit rights for BRE groups are controlled by group membership.

For a detailed description of the Rules Engine, see the Rules Engine Documentation.

How do I get permission to use the Bugzilla Rules Engine?

To use the Rules Engine, you need to be a member of a Bugzilla group that has edit rights to the BRE Group the product belongs to. See Who to contact to have a product or component updated to ask the team for membership.

Why isn't my rule running?

If your rule is not modifying bugs as you expect it to, you should check the following items:

What are the restrictions on writing rules?

A rule must progress the bug state. That is, a rule is considered invalid if it does not change each bug in such a way that the rule doesn't immediately match the bug again. That means that a rule cannot merely add a comment or send an email notification without making any changes to the bug. It also means that a rule's criteria should check that the rules action has not already been done. For example, if you want a rule to set the 'devel_ack' flag, the rule should first check that the 'devel_ack' flag is not already set.

Using the Bugzilla API

What APIs are available?

Red Hat Bugzilla Stage has 3 API endpoints, XMLRPC, JSONRPC, and REST. Currently the JSONRPC endpoint is recommended for new tooling.

The XMLRPC endpoint has some technical limitations with regard to UTF-8 content. There is code in place to replace incompatible characters in data read on this endpoint. This means the data may not be 100% the same as the data in the database. Occasionally this results in calls to this endpoint failing. To fix this we need to track down the cause and further filter the data read from this interface.

The REST interface is a partial wrapper around the JSONRPC interface. It does not expose any of the web calls added by extensions.

When using the JSONRPC and XMLRPC endpoints it is considered best practice to use POST for all calls.

Where are the APIs documented?

See the Bugzilla WebService documentation

How should my script authenticate with Red Hat Bugzilla Stage?

Use API keys

How can I make sure that my script uses Bugzilla efficiently and does not overload the server?

The following best-practices are advised:

Converting an advanced search to a JSONRPC call

It is a simple process to convert the URL for an advanced search to a JSONRPC call. This allows you to use the advanced search UI to create complex searches and then use it in the JSONRPC API.

  1. Create a search in the advanced search UI
  2. Run the search
  3. On the results page click the Change Columns button
  4. Select the columns you want
  5. Click the Change Columns button
  6. Repeat until happy
  7. On the bug list page click the RPC as JSON button
  8. Paste the JSON to replace $TEXT in the call below

curl -H "Content-Type: application/json;charset=UTF-8" \
-H "Authorization: Bearer $APIKEY" \
-X POST \
-d '{"method": "Bug.search", "params": [ $TEXT ], "id": 1}' \
https://bugzilla.redhat.com/jsonrpc.cgi

Running Saved Searches

It is possible to run saved searches, including shared saved searches, in the APIs.

  1. Create a search
  2. Change the columns to suit your need
  3. Save the search with a meaningful name
  4. Make an API call to run the search

curl -H "Content-Type: application/json;charset=UTF-8" \
-H "Authorization: Bearer $APIKEY" \
-X POST \
-d '{"method": "Bug.search", "params": [{"savedsearch": "MySavedSearch"}], "id": 1}' \
https://bugzilla.redhat.com/jsonrpc.cgi

If you are attempting to run a saved search that was shared with you, then you need to know the ID of the sharer and include that as a parameter. You can find out the sharer's ID by looking at the URL to the saved search in the menu or in the footer of the Bugzilla UI.


curl -H "Content-Type: application/json;charset=UTF-8" \
-H "Authorization: Bearer $APIKEY" \
-X POST \
-d '{"method": "Bug.search", "params": [{"savedsearch": "MySavedSearch", "sharer_id": 112233}], "id": 1}' \
https://bugzilla.redhat.com/jsonrpc.cgi

Running Reports

It is possible to run reports, including shared reports, in the JSONRPC API.

  1. Create a report
  2. Change the columns to suit your need
  3. Save the report with a meaningful name
  4. Make an API call to run the search

curl -H "Content-Type: application/json;charset=UTF-8" \
-H "Authorization: Bearer $APIKEY" \
-X POST \
-d '{"method": "RedHat.run_report", "params": [{"name": "MyImportantReporth"}], "id": 1}' \
https://bugzilla.redhat.com/jsonrpc.cgi

Bot & List Account Policy

Internal Bots

internal bots are an alternative to having an @redhat.com account for automation usage. These accounts are owned by an Agile Team.

Bot accounts have restricted access to the service, they:

Instead of logging in, bot owners create API_KEYs for the bot and use those to access the API.

Bot accounts can be created by users in the redhat group on any Bugzilla server by logging in and going to the My Links -> Workflows -> Create Bot Account menu.

External Accounts

For external accounts mail is filtered based on the list/bot account credentials, because of this external accounts are subject to auditing to prevent unprivileged users having access to mail containing data they should not be permitted to access.

  1. All @redhat.com accounts must have a valid MX entry. @redhat.com accounts that do not have a valid MX entry will be terminated. There are two ways to get a new MX entry.

    1. Request IT to create a mailman list for you.
    2. Request IT create an email alias for you.

    There is no differentiation in the use of email alias or mailing list accounts. Both can be used for automation or just receiving mail. If you have an existing list account with a disabled login and you wish to use it for automation please contact the Bugzilla administration team at the maintainers to have it enabled and a new password set.

    Google groups are not considered acceptable and will fail the audit as they cannot be audited.

  2. All members must belong to all the non-public groups the list or alias account is in.

  3. Accounts that have default roles (assigned, qa, cc, etc) on Red Hat products will be considered to be members of the redhat group and will be expected to enforce internal group policies. This is because these roles grant access to private bugs.

  4. On-site partner engineers are not permitted access to internal groups, they are only permitted access to:

    • the redhat_partner_engineer_staff group
    • their own partner group
    • public groups

    If your bot or list has such users then your account should be limited to the same permissions as the partner users.

  5. Mailman list accounts have these extra requirements:

    1. To qualify for membership of internal or partner groups lists must have the following settings.
      1. List membership must be open so that membership can be audited.
      2. List subscription must be set to require approval and you will not add people who are not in all the groups the list can see.
      3. List archives must be private.
    2. Lists that don't qualify for 5.1 may only be in public groups
    3. Lists that have bug mail disabled are not subject to auditing. To have bug mail disabled for an account mail the maintainers

Accounts found to be in breach of these policies will be referred to the Information Security Team for auditing and may be disabled until the audit is completed and any remedial actions required are performed.

Policies on Partner Engineer accounts

  1. Partner Engineers are only permitted membership in public and their own Partner's groups.

Partner Engineer accounts found to be in breach of these policies will be referred to the Information Security Team for auditing and may be disabled until the audit is completed and any remedial actions required are performed.

Policies on Email address changes

Red Hat Bugzilla Stage enforces the following policies on email address usage

  1. For the following reasons an account cannot have its email address changed to or from an @redhat.com address

    Security
    Red Hat users have elevated access to certain confidentialbugs and information, auditing accounts is costly in administrators time and is not fool proof.
    Attribution
    Comments made by Red Hatters should always be attributed to Red Hat, likewise comments not attributable to Red Hat should not suddenly appear to be from Red Hat.
  2. For the following reasons an account cannot have its email address changed to or from any partner address

    Security
    Partner users have elevated access to certain confidentialbugs and information, auditing accounts is costly in administrators time and is not fool proof.
    Attribution
    Comments made by Red Hat Partners should always be attributed to that Partner, likewise comments not attributable to Red Hat Partners should not suddenly appear to be from a Red Hat Partner.

Miscellaneous

What is python-bugzilla?

Python-bugzilla provides a Python library and a command-line utility for accessing a number of Bugzilla servers, including Red Hat Bugzilla Stage. The python-bugzilla package is part of Fedora and is not maintained by the Bugzilla Development Team. For more information on python-bugzilla, see python-bugzilla on GitHub.

Why does Bugzilla nag me with emails about "Your Outstanding Requests"?

Bugzilla will send you a daily reminder email if you have one or more needinfo or review flags that has been requested of you for more than three days without a response. The easiest way to stop the emails is by opening each bug listed in the message and responding to the request for information.

How To use an Agile team as a mailing list

There is a straightforward process to using a team as an alternative to a mailing list.

The only requirement to complete this is the user doing so must be in the redhat group in Red Hat Bugzilla.

  1. You need a team for administrating the bot and the list team. If you don't have existing team suitable for the admin team see How To Create an Agile Team.
  2. If you would like the admin team to be self managing grant the team edit rights to itself.
  3. You will need an internal bot account. If you don't have an existing internal bot account suitable for this see How To Create an internal bot account.
  4. The admin team must have management rights to the internal bot.
  5. You need a team to act as the list. If you don't have existing team suitable for this see How To Create an Agile Team.
  6. Grant the admin team edit rights the the list team.
  7. Add the internal bot to the list team.
  8. Modify [sub]component assignees/qa/docs/cc/etc to use the internal bot.

You are done. Users in the list team will now get bug mail for bugs the bot account has a role on.

How To Create an Agile Team

To create an agile team you need to be in the community group. Almost all users in any other group in Red Hat Bugzilla are in the community group.

To create a team you can use the Agile->My Teams menu and then click the Create a new Team link, or you can create a new team now.

When you create the team the user doing so will be granted the Scrum Manager role. This role allows the user to edit the group. If you remove this role without granting other users or groups edit access you will lose edit access!

If you lose edit access you will need to email the maintainers and ask for help to regain edit access.

How To Create an internal bot account

To create an internal bot account you:

  1. Need to be in the redhat group
  2. Need to have an Agile team to manage the bot account

The management team should be small, but more than one person, and consist of users you can trust to responsibly manage the bot.

If you don't have an existing team suitable for administrating the bot account then see How To Create an Agile Team.

If you want the bot to be added to groups other than redhat at the time of creation then the user creating the bot account needs to be in those groups.

To create an internal bot account you can use the My Links->Workflows->Create Bot Account menu, or you can create a new internal bot now.

How To Change Content Of a Bug Template

'Bug templates' are the text that appears by default in the initial description field. Each component can use a different template. Changing the component on a bug being created will change the the description text if required.

To change the content of bug template, or have new ones created, submit a support ticket along with text required to the maintainers.

Applying the change to the component to use a new template is a change the component owners will need to make.

Who to contact to have a product or component updated

In Red Hat Bugzilla Stage teams manage their own products and components. To find out who can edit a product you can use the component management UI.

Enter the product you require changed in the product drop down on this form, then click the address book icon () to the right of it. This will display a list of users who have edit rights for this product. You need to contact them directly to have the product modified.

Who to contact to have a Fedora product or component updated

Fedora products are managed by the Fedora Infrastructure Team, to have any changes made to these products you need to contact them directly.

Who to contact to get edit access for products and components

To edit a product you need membership in the product's admin group. See Who to contact to have a product or component updated to identify who to ask for membership.

Admins of a product can grant component owners the rights to edit their components, they can do so by creating an Agile team and assigning this team as a sub-team on the component[s]. Then members of the sub-team can then edit these components in the component management UI. See Who to contact to have a product or component updated to identify who to ask to make these changes.

Data Reuse Policy

This policy is to inform users of their responsibilities when exporting data from Red Hat Bugzilla.

Data Types

Broadly Red Hat Bugzilla has 3 types of data.
Public
Data that can be shared without restriction.

In Red Hat Bugzilla this is bugs and data that can be accessed by users who are not in any Red Hat Bugzilla groups.

e.g. Bugs that have no groups, comments on public bugs not flagged as private, custom fields on public bugs with no view group set, etc.

Confidential

Data that must protected by authorization, with access limited to the specific individuals and groups as in Red Hat Bugzilla itself.

i.e. An individual who does not have access to this data within Red Hat Bugzilla is not authorized to access the data in any other system, process, or method.

This covers every Data Category except Public.

Personally Identifiable Information (PII)

Email addresses and full names are PII. If a user files a GDPR request to have their data removed from Red Hat Bugzilla then it is the responsibility of re-users to update their systems with the redacted information.

Data Categories

Public
Data that has no groups set on it.
Confidential
Data protected by groups in the Public or Agile categories.
Red Hat
Data protected by groups in the Red Hat category. This data is generally restricted to Red Hat employees on a need to know basis.
Partner
Data protected by groups in the Partner category. This data is generally restricted to Red Hat employees and selected partners on a need to know basis.
Red Hat Engineering
Data protected by engineering groups in the Red Hat category. This data is generally restricted to Red Hat Engineering employees and selected partners on a need to know basis.
Security Restricted
Data protected by the security group. This data is generally restricted to Red Hat Product Security employees and with others on a need to know basis.
Embargoed
Data that is subject to the Red Hat Security Embargo Policy. This data is generally restricted to Red Hat Product Security employees and with others on a need to know basis.