RT4ExperimentalWishList

RT4 going to break backwards compatibility, however we want to make core more modern to make it easier to write new extensions and make it easier to implement features each modern web application should have, for example AJAX.

On this page you can list your wishes. Try not to bloat this page and keep it slim and descriptive. We're going to delete crap, not parsable and other content that is not well described.

Web interface

Customization

Make the web interface more easily themeable. In RT3, to change anything that is not crude CSS one need to hack into perl and mason code, which can be very confusing. The ideal scenario would be something close to Wordpress, in which the administrator can create completely custom HTML templates, only calling simple functions with intuitive names and parameters to render elements and widgets.

> How about using a framework such as Catalyst, providing a clean MVC separation to keep the templates and the code isolated?

Tickets

A hierarchy of tickets. Using the existing parent/child structure allow the option of displaying tickets in a tree view. This would make it much easier to determine what task needs to be done next when working on a large project.

Users

Have hooks on create-user so you can setup stuff for users that is repetitive. Eg: Add $newuser to several groups if privileged, give $newuser a default dashboard based on group membership, etc.

Groups

Completely external AAA providers for on-the-fly group membership decisions. We'd like to lean on something like AD, or grouper->openLDAP; integrating RT into our current setup involves some painful import processes.

RTFM

The possibility to create one article in more than one class

New ways for formatting text like boxes, tables, italic, fonts tyoes and perhaps some index inside the article.

Watchers (Owner, Requestor, Cc and AdminCc)

Note that we already made first steps towards making list of watchers customizable.

Reporting

How about some PPM reports? Capacity/Resource planning (do we have enough available time to do a project), Time worked per month over a year on a project (parent/child tickets), Projects over budget/time, snapshot reports on all/a project. This is just a few.

Scrips

Note that Scrips are going to be replaced with Lorzy engine and you should list things that you can't do with Scrips, but want to.

iTIL

State Engine

Priority = (Urgency * Impact)

State = (Priority / Severity) Date - Time Left

Priority is equal to the Maximal urgency the business will require resolution and multiplies the impact by services, users and or identified service level impact

State drives the date only determined by Priority, if this equates you have balance.

Rule Engine

for another day

Database Enhancements

• Split the attachments database into an actual binary attachments, and correspondences/comments databases

Nagios integration

• Smart ways to detect nagios problems and enter tickets
• Smart ways to detect xymon alerts and enter tickets
• Smart way to configure nagios, icinga, shinken, ... to be sure all éléments in the CMDB are supervised and not others.

Ticket Creation

Time Field

Time estimation, Time worked shall have "days" in the drop down too. And the time left shall be automatically calculated ( Time estimated - Time worked)

On this basis the overdue tickets shall be notified ( be email or on home page)

Give the option to require the time worked field before making a comment, replying or resolving the ticket

Priority

Manual entry of the priority shall be avoided as human error can occur, instead selection drop down list to be made available with the predefined priorities.

REST

Service interface like Canonical REST service sample. Correct status code for GET and POST commands (not only in response body).

Format

XML format for REST interface (or JSON). Base64 for binary data. Constant date & time format for date-time fields. Constant value for empty fields instead of localized string for "Not set".

Data

Users, queues, priorities and statuses lists.

Custom fields

Any interface for ticket custom fields (list predefined values for custom fields, type of custom field: select, string etc.).

Select data

"TOP N" for tickets list and history entries queries.