Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @

RT Technical Details

From EGIWiki
Jump to navigation Jump to search
Alert.png This article is Deprecated and should no longer be used, but is still available for reasons of reference.



Requirement metadata









Status definitions

Requirements queue status values definitions:

  • New = just arrived, no action taken yet (ticket must be Opened)
  • Open = to be discussed (Ticket is allocated to a person/group. This person/group should attach a deadline to the ticket - e.g. when it will be discussed)
  • Stalled = discussion/implementation is on hold for some reason
  • Resolved = solved (validation may or may not have happened. There will be no "validated" status at the moment. If we need, we can add it later)
  • Rejected = EGI discussed then rejected the request (reason of rejection must be attached to the ticket)
  • Accepted = to be implemented (Requested feature/action will be implemented. The owner of the ticket is responsible for the implementation)

ops-tools-roadmap and user-tools-roadmap queues status values definitions:

  • New = Feature that is not necessarily linked to any requirement yet. Feature that is not necessarily allocated to any release yet. (This status can be used for features that need to be discussed, finalised to meet a requirement/request)
  • Open = Feature to be included in the next release (the feature is currently under development). The ticket must depend on at least one requirements ticket from the requirements queue
  • Stalled = Feature to be included in some future release (not in the next release). The ticket must depend on at least one requirements ticket from the requirements queue
  • Developed = The feature has been developed (responsibilities have to be defined to validate) is it pre-release or production release ?
  • Resolved = Implemented (developed feature was validated and can be understood as solved issue)
  • Rejected = EGI discussed then rejected the feature (because no related user requirement exists)

Status life cycle

RT status values.png

Priority & Impact

  • Impact of Requirement

The requestor/proposer of a new Requirement needs to assess the likely impact that the modification will have to users both within the immediate user community and EGI community at large. In turn, this will enable the work to satisfy the new Requirement to be correctly prioritised. The majority of new Requirements should normally be considered to be “Important with a significant benefit to this user community”.

  • Impact categories:
    • 4. - Essential to the effectiveness of this user community/the wider user community
    • 3. - Important with a measurable benefit to this user community
    • 2. - Useful – will be of some benefit to this user community
    • 1. - Nice to have - slight improvement
    • 0. - Don’t know
  • Priority

The User Community Support Team will consider the new Requirement and prioritise any work effort as necessary in relation to other proposals.


Requirements queue access rights

New Requirement

RT Web

Please refer to the New Requirement Manual.


Web Form

Requirement dependencies

Ticket in the Requirements queue can have the dependencies or be depended on by another ticket.

RT WEB UI Links section must be used for that.

i.e. for the existing ticket #111 which is Requirement we put the dependency for another ticket #222 which is Feature request in the user-tools-roadmap queue. The ticket #111 cant be Resolved untill ticket #222 will be Resolved or Rejected or Deleted.

All Tickets in Requirements queue RT at a Glance interface will have additional mark "(pending 1 other ticket)" if they have at least one dependency which is not Resolved or Rejected or Deleted.

Ticket Watchers

Watcher is superset term for Requestors, Ccs and AdminCcs.

More details:

Watcher is a user who gets a copy of correspondence on the ticket.

Watcher (type CC) gets the same things as a Requestor.

Watcher (type AdminCC) gets the same things as CC + comments those are not sent to requestors.

Only Admins of the Queue can set up and remove the Watchers.

Ticket AdminCC & CC

An *AdminCC* is like a joint Owner of a Ticket. A ticket's AdminCCs are Users, typically Staff, who receive both Comments and Correspondence. A CC, who might be outside the company, only gets Correspondence.

This role could be used for a manager who is not directly responsible for a Ticket but wants to follow its progress and be able to comment on it or Reply to the Requestor.

A ticket's AdminCCs will have Rights to the ticket by virtue of being AdminCCs.

Firefox & ticket search

Create New Bookmark using these instructions:

1) go to firefox menu bar "Bookmarks"

2) choose "organize bookmarks"

3) choose "bookmarks menu"

4) right click on "bookmarks menu" -> "New Folder..." and fill the details below:

Location: %3D 'requirements' AND ( Subject LIKE '%s' OR Content LIKE '%s' )

Keyword: rt

Now you can search rt by typing 'rt [some keywords]' in the address bar of firefox.

  • list all ticket those have any custom tags set: %3D 'requirements' AND 'CF.{Custom Tag}' is not NULL


  • For Firefox use "Live Bookmark"



Useful Links about RT