Ranking Fields

Ranking fields allow the end user to order a logical collection of issues.  The collection of issues is defined by a filter on the ranking field and can therefore contain any subset of issues within your database.  For example, you might have a ranking that contains all the issues in a product release within a product, within a specific business area.  An end user may then order the issues within the collection, using the ranking field to depict the ranking of an individual issue.  Rank fields have the following attributes:

  • A rank field is defined in the data dictionary as a field with a display type of number
  • You set an attribute on the field to define its use as a rank field.  This ensures the field will behave with its special characteristics
  • Rank fields can be updated within an add or edit screen or within a column report.  However the ability to manipulate the ranking of issues on a column report is recommended within a workspace, where the user can drag-and-drop an issue to change its position in the rank.  Outside a workspace, an end user can use Quickedit to update the ranking of any field, but the underlying report will need to be manually refreshed to see the updated rankings
  • Any one issue may belong to different rankings, and have a different position in the ranked order for each of these different ranks.  Each of these different rankings is specified with a different ranking field
  • Each of the ranking fields that pertain to an issue should, at minimum, be placed on the edit layout of the issue.  You may hide the field(s) from users
  • Although rank fields may be placed on add and edit layouts, they are not placed within the audit trail (history) of the issues.  The principal reason is that when a user is using a report to rank their issues, they may perform many, many re-rankings within a short space of time.  These interim rankings have little value within the audit trail, and if, for example, a user places a top-ranked issue at the bottom of 1,000 issues within the ranking report, 1,000 updates to history would need to be made.  This would lead to a very unresponsive and slow user interface.

Creating a Ranking Field

  1. Within the data dictionary, create a field with these attributes:
    1. A valid Business Area, or * Global Area *
    2. A valid Project or the * Master Project *
    3. Field Belongs to must be Issue records
    4. Any valid Fixed name
    5. Any valid Title
    6. A Display type of number
    7. Set Use as a Rank Field to Yes
    8. Set Allow selection on reports to Yes
    9. Set Filter criteria to Yes
    10. Set Is Sortable to Yes
    11. Add the field
  2. The new field you created has a List button, as shown in this screenshot.  This button accesses the screen where you create and maintain specific ranking definitions for the ranking field


     

  3. Click the List button and then click the Add button to add a new definition for the ranking field.  The entries on this screen are used to define filters to select the scope of the ranking.  Only issues that fall within the collection of issues defined by this scope can be ranked with this filter.  Only fields with display types that are enumerated lists can be used to define the scope of the ranking.  For example, list, multi-valued lists, radio button, user and tab fields may be used as filters for the definitions, but you cannot use numeric type fields


    Note that you will be creating one or more reports that use this ranking definition, and these reports may have filters that display a subset of the issues within the scope of the ranking

  4. Add the ranking definition to the database
  5. You may create many ranking definitions for one ranking field.

Using Ranking Fields

Ranking fields can be placed on add, edit layouts and reports.  The use of a ranking field within an add or edit layout is somewhat limited in that you only have a view of that issue, and not the complete collection of issues within the ranking.  Consideration should be made to making the ranking field read-only, through the use of the read only if layout cell attribute.  You may also hide the field on the layout if you do not wish users to modify its value within issues.

Their primary use is within workspaces, where the user might want to rank a large number of issues at one time.  This is documented on the page Ranking Reports.