RT4ExperimentalWishList - Revision history

Admin: 12 revisions imported

2016-04-06T20:23:34Z

12 revisions imported

← Older revision		Revision as of 16:23, 6 April 2016
(No difference)

217.128.107.113: /* Nagios integration */

2012-09-14T08:41:26Z

Nagios integration

New page

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.

= Queues =

= 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.

== Have a good way to have (certain) global scrips not apply to all queues. ==

= Templates =

= Interaction via email =

= 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 [http://code.msdn.microsoft.com/cannonicalRESTEntity 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.

69.25.174.141: /* Time Field */

2011-01-04T23:28:27Z

Time Field

← Older revision		Revision as of 19:28, 4 January 2011
Line 80:		Line 80:

	On this basis the overdue tickets shall be notified ( be email or on home page)		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 =		= Priority =

155.70.141.45: /* Nagios integration */

2010-12-15T22:34:09Z

Nagios integration

New page

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.

= Queues =

= 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.

== Have a good way to have (certain) global scrips not apply to all queues. ==

= Templates =

= Interaction via email =

= 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

= 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)

= 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 [http://code.msdn.microsoft.com/cannonicalRESTEntity 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.

193.108.39.141 at 17:38, 7 December 2010

2010-12-07T17:38:59Z

← Older revision		Revision as of 13:38, 7 December 2010
Line 89:		Line 89:
	== Format ==		== 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".		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 list, queues list, priorities list.
	== Custom fields ==		== Custom fields ==
	Any interface for ticket custom fields (list predefined values for custom fields, type of custom field: select, string etc.).		Any interface for ticket custom fields (list predefined values for custom fields, type of custom field: select, string etc.).
	== Select data ==		== Select data ==
	"TOP N" for tickets list and history entries queries.		"TOP N" for tickets list and history entries queries.

193.108.39.141 at 11:51, 7 December 2010

2010-12-07T11:51:52Z

← Older revision		Revision as of 07:51, 7 December 2010
Line 59:		Line 59:
	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		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.		State drives the date only determined by Priority, if this equates you have balance.

	== Rule Engine ==		== Rule Engine ==
Line 82:		Line 82:
	= Priority =		= 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.		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 =		= REST =

193.108.39.141: /* Format */

2010-12-07T11:40:50Z

Format

New page

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.

= Queues =

= 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.

== Have a good way to have (certain) global scrips not apply to all queues. ==

= Templates =

= Interaction via email =

= 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

= 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)

= 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 [http://code.msdn.microsoft.com/cannonicalRESTEntity 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".

== 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.

69.25.174.141: /* Database Enhancements */

2010-11-24T22:13:44Z

Database Enhancements

New page

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.

= Queues =

= 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.

== Have a good way to have (certain) global scrips not apply to all queues. ==

= Templates =

= Interaction via email =

= 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

= 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)

= 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.