Page tree

This page describes how to work with the QRR Issue Reporting System, in particular, how to create and work with issues.

Accessing the Issue Reporting System

The system may be accessed visiting the following URL:

The username and password required to log in will have been provided by the QRR Support Team.

Please note that the old URL ( is no longer valid and trying to log in there will show an authentication error.

Creating Issues

After logging into the system, it is possible to create a new ticket by selecting one of the available request types:

Please select the one which best matches the type of request you are about to make:

  • Report a bug: This type is used to indicate that there is an error in the product that has to be resolved.
  • Report an installation problem: This type is used to indicate that there is problem with the installation or configuration rather than an error in the product itself.
  • Request a new feature: This type may be used to request a new feature or an improvement of an existing one.
  • General inquiry: This type may be used to request any kind of information or help for the product.

Next you will be asked for the details of the request (which may vary depending on the type of request):

The purpose of each field is as follows:

  1. Summary: A short one-line summary of the issue
  2. Description: The description of the issue giving as many details as possible. In case of an error it is important to indicate the steps followed and whether the problem can be reproduced reliably.
  3. Priority: The priority of the issue. Initially this priority indicates the importance this issue for the customer. The priority may be modified throughout the lifetime of the issue (e.g. if a work-around is found for a problem).

    BlockerDefects that could (or did) cause disastrous consequences for the system in question.Critical loss of data, critical loss of system availability, critical loss of security, critical loss of safety, etc.
    CriticalDefects that could (or did) cause very serious consequences for the system in questionA function is severely broken, cannot be used and there is no workaround.
    MajorDefects that could (or did) cause significant consequences for the system in question, i.e. a defect that needs to be fixed but there is a workaround.Function is badly broken, but a workaround exists.
    MinorDefects that could (or did) cause small or negligible consequences for the system in question. Easy to recover or workaround.

    Misleading error messages.
    Displaying output in a font or format other than what the customer requires.

    TrivialTrivial defects that can cause no negative consequences for the system in question. Such defects normally produce no erroneous outputs.Simple typos in documentation.
    Bad layout or misspelling on screen.
  4. Affects Versions/s: The version of the product to which the issue is related.
  5. Components: The component(s) of the product related to the issue. If unsure, this field may be left blank and the QRR Support Team will fill it in later.
  6. Environment: Details about the environment where the error has been observed, for example the execution environment (e.g. development, QA, production) or the operating system and application server used (e.g. WebSphere 7.0 on Suse Linux 11.2).
  7. Original Reporter: Optional field that may be used to indicate which end-user reported the issue in case the issue is being created on behalf of someone else.
  8. Attachment: Additional files, such as screen shots or log files, may be attached to the issue.

Issue Workflow

The following diagram shows the workflow associated to the issues. The nodes designate the status of an issue, while the arrows denote the possible transitions between the states.

A typical workflow might be like this:

  1. The customer creates a new ticket (status Waiting for triage).
  2. The QRR Support Team asks for additional information from the customer (status Waiting for customer).
  3. The customer provides the information and the QRR Support Team starts working on the issue (status Waiting for support).
  4. The QRR Support Team resolves the issue (status Resolved).
  5. The customer checks whether the issue has been resolved successfully. If not, the customer requests to re-open the ticket (status Waiting for support) and the process returns to step 2.

Viewing All Requests

You may select the "Requests" link in the upper right corner in order to see all open and resolved requests:

Changing Your User Profile

To access your user profile page, please visit, where you will be able to edit the different properties of your user profile (notification e-mail address, password, etc.):