Bugzilla : Reporting Bugs
Koha Bugzilla
How to report bugs
This information is based on the Mozilla and Bugzilla project's guidelines and documentation.
What is a bug?
- A bug can be quickly identified as a problem with Koha. However, it is much more complicated than that. It can be a behavioural problem, or a component that does not work at all. It even applies to documentation that is incorrect.
What is Bugzilla?
- Bugzilla is a database of bugs and feature requests developed by the [Mozilla] project. It helps developers keep track of what's broken and who's fixing it. Users can help by making bug reports clear and specific. The better your bug report, the easier it is to identify the cause, and fix the bug.
- It is very important for Koha to have bugs listed on bugzilla. That is the list that the developers work from. If a bug is just mentioned in a posting to a mailling list, or just mentioned on IRC (chat) it can very easily slip through the cracks.
Entering A Bug Report
- The Bugzilla Bug Writing Guidelines can be found here:
- http://bugs.koha.org/bugwritinghelp.html
- Step 1. Create an account and log in.
- Create a Bugzilla account if you do not already have one by going to "Open a new Bugzilla account" (http://bugs.koha.org/cgi-bin/bugzilla/createaccount.cgi). After you receive your Bugzilla password, go ahead and LOG IN if you have not already done so.
- Step 2. Search for your bug.
- The first thing that needs to be done is to see if your bug has already been reported. If there is a bug report that is similar to yours, you may be able to add additional information, and/or add yourself to the CC list of the bug so you will get notified of any changes to the bug, including when it is fixed.
- To search for your bug goto "Query existing bug reports" (http://bugs.koha.org/cgi-bin/bugzilla/query.cgi)
- The Bugzilla Query Form can look complex, but you can safely ignore most of the form. The way the search works, any part of the form that is left blank does not limit the search at all, and each part that is filled in cuts the list of bugs down to only those that match the criteria you set.
- In the first row, everything would normally be left as it is. The first field, Status, is set by default to find NEW, ASSIGNED, and REOPENED bugs - those are the ones that are still unfixed. But if you're using a release build, you should add RESOLVED and maybe VERIFIED (use Ctrl-click to select multiple choices), especially if the release is a few weeks old, since many bugs may have been fixed since the release.
- From there, scroll down until you can see the choices for Program, Version, and Component. If you are unsure of the version of Koha you are using, either on the Intranet interface, select the "About" page, or else view the contents of your koha.conf file. Select the component that relates to the area that your bug is located in. This will help focus the search.
- Enter a word or short phrase that identifies the problem you saw as uniquely as possible in the Summary field. If you enter more than one word and they are not a phrase, change the type of matching for the Summary field from "case-insensitive substring" to "all words" or "any words", as appropriate (just to the right of the text-entry field).
- When you have done all that, click on the [Submit Query] button. A new page will load, and on it you should see a list of bugs that match your query. Note: A response of "Zarro Boogs found." mean there are no results for your search.
- If you find a report with a bug or feature request that matches what you have discovered, click on the number in the first column, labelled "ID". Read the text that has been entered (make sure that you scroll to the bottom of the page where you can see all additional commnets), then add your comments into the "Additional Comments" text box and once you are finished press [Commit]
- If you cannot find a pre-existing report, then you will need to create a new report, to do this, scroll to the bottom of the page, where you will find a "yellow box", within this box you will need to click on the word [New].
- This will take you to tbe "Enter New Bug Report" screen, and we can move onto Step 3.
- Step 3. Select the version of Koha.
- Choose the proper version of Koha. If you are unsure of the version of Koha you are using you can find the version in either the Intranet interface by selecting the "About" page, or else view the contents of your koha.conf file.
- Step 4. Select the Component.
- Select a component to enter a bug against. (If they all look meaningless, click on the Component link, http://bugs.koha.org/cgi-bin/bugzilla/describecomponents.cgi?product=Koha, which links to descriptions of each component, to help you make the best choice.)
- Step 5. Select the Platform.
- Step 6. Select the OS.
- Which operating system are you running Koha on?
- Step 7. Select the Resolution Priority.
- This field describes the importance and order in which a bug
should be fixed. This field is used by developers and release
coordinators to prioritise work that still needs to be done. The
available priorities are:
- P1 - This bug blocks development or testing work and should be fixed ASAP;
- P2 - This bug blocks usability of a large portion of Koha, and really should be fixed before the next planned release;
- P3 - Seriously broken, but not high impact. Should be fixed before next major release. Can include cosmetic bugs of particularly high visibility, and more minor bugs that are frequently reported;
- P4 - Either a fairly straightforward workaround exists or the functionality is not very important and/or not frequently used; and
- P5 - Not that important, just fix when time permits.
- This field describes the importance and order in which a bug
should be fixed. This field is used by developers and release
coordinators to prioritise work that still needs to be done. The
available priorities are:
- Step 8. Select the Severity.
- How bad do you think this bug is? This field describes the
impact of a bug on a user. If a bug occurs with great frequency, it can
be moved up in severity even if it doesn't meet the other criteria in
that category.
- Blocker - Needs to be fixed and an update released immediately.
- Critical - Koha or component crashes and/or there is a potential loss of data
- Major - A major part of the component is nonfunctional.
- Normal - A minor part of the component is nonfunctional.
- Minor - The component mostly works, but causes some irritation to users.
- Trivial - The component works with 100% functionality, but has visible typos or other cosmetic problems; and
- Enhancement - Generally a feature request for functionality that does not currently exist. These can be useful as guides for future product improvements.
- How bad do you think this bug is? This field describes the
impact of a bug on a user. If a bug occurs with great frequency, it can
be moved up in severity even if it doesn't meet the other criteria in
that category.
- Step 9. Enter a URL.
- This can be useful for posting logs, screenshots, or any other items that might be useful to someone trying to find and fix the problem, but which might not be appropriate to attach to the bug because of number or size.
- Step 10. Enter a Summary.
- Describe your bug in a short sentence. Be as descriptive as possible- 'it is broken' is not very useful, while 'the text entry form won't let me enter text' is much more informative.