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.
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?
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.
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.
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.
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.
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.
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.
Have a good way to have (certain) global scrips not apply to all queues.
Interaction via email
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.
for another day
- Split the attachments database into an actual binary attachments, and correspondences/comments databases
- 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.
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
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.
Service interface like Canonical REST service sample. Correct status code for GET and POST commands (not only in response body).
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".
Users, queues, priorities and statuses lists.
Any interface for ticket custom fields (list predefined values for custom fields, type of custom field: select, string etc.).
"TOP N" for tickets list and history entries queries.