WishList - Revision history

Admin: 20 revisions imported

2016-04-06T20:39:45Z

20 revisions imported

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

82.144.253.242: /* Unknown state */

2014-11-17T14:01:32Z

Unknown state

← Older revision		Revision as of 10:01, 17 November 2014
Line 24:		Line 24:
	== Unknown state ==		== Unknown state ==

			* On login page protect against brute force attacks
			* Support Dashboards on SelfService interface
	* On Child Ticket creation - make the created ticked '''not inherit '''the value for TimeWorked.		* On Child Ticket creation - make the created ticked '''not inherit '''the value for TimeWorked.
	* Store the Message-ID for each message in the database to enable thread detection via In-Reply-To and References in the mail gateway instead of ticket number ID ([http://cr.yp.to/immhf/thread.html more info])		* Store the Message-ID for each message in the database to enable thread detection via In-Reply-To and References in the mail gateway instead of ticket number ID ([http://cr.yp.to/immhf/thread.html more info])

217.74.64.220: /* Unknown state */

2014-10-21T12:51:52Z

Unknown state

← Older revision		Revision as of 08:51, 21 October 2014
Line 24:		Line 24:
	== Unknown state ==		== Unknown state ==

			* On Child Ticket creation - make the created ticked '''not inherit '''the value for TimeWorked.
	* Store the Message-ID for each message in the database to enable thread detection via In-Reply-To and References in the mail gateway instead of ticket number ID ([http://cr.yp.to/immhf/thread.html more info])		* Store the Message-ID for each message in the database to enable thread detection via In-Reply-To and References in the mail gateway instead of ticket number ID ([http://cr.yp.to/immhf/thread.html more info])
	* Allow for multiple owners of a single ticket		* Allow for multiple owners of a single ticket

217.74.64.220: /* REST */

2014-10-21T12:48:51Z

REST

← Older revision		Revision as of 08:48, 21 October 2014
Line 108:		Line 108:
	=== REST ===		=== REST ===

	* Add Possibility to set CF Value for Transactions via comment / correspond REST		* '''Add Possibility to set CF Value for Transactions via comment / correspond REST'''
	* Correct status code for GET and POST commands (not only in response body).		* Correct status code for GET and POST commands (not only in response body).
	* Constant date & time format for date-time fields.		* Constant date & time format for date-time fields.

217.74.64.220: /* REST */

2014-10-21T12:47:43Z

REST

← Older revision		Revision as of 08:47, 21 October 2014
Line 108:		Line 108:
	=== REST ===		=== REST ===

	*		* Add Possibility to set CF Value for Transactions via comment / correspond REST
	* Correct status code for GET and POST commands (not only in response body).		* Correct status code for GET and POST commands (not only in response body).
	* Constant date & time format for date-time fields.		* Constant date & time format for date-time fields.

217.74.64.220: /* REST */

2014-10-21T12:45:42Z

REST

← Older revision		Revision as of 08:45, 21 October 2014
Line 108:		Line 108:
	=== REST ===		=== REST ===

			*
	* Correct status code for GET and POST commands (not only in response body).		* Correct status code for GET and POST commands (not only in response body).
	* Constant date & time format for date-time fields.		* Constant date & time format for date-time fields.

151.51.152.98: Removed spam

2014-01-08T21:06:03Z

Removed spam

← Older revision		Revision as of 17:06, 8 January 2014
Line 244:		Line 244:
	* Integrate [[FCKEditor]] for ticket comments/replies. http://www.fckeditor.net/		* Integrate [[FCKEditor]] for ticket comments/replies. http://www.fckeditor.net/
	** 3.7(.82) has this...		** 3.7(.82) has this...
	* [http://www.freepan.org FreePAN]

66.30.11.227: /* Unknown state */

2013-08-07T22:03:39Z

Unknown state

← Older revision		Revision as of 18:03, 7 August 2013
Line 28:		Line 28:
	* Add diff style display of changes for custom scrips, conditions and actions. (The unformatted old/new display can be hard to read.)		* Add diff style display of changes for custom scrips, conditions and actions. (The unformatted old/new display can be hard to read.)
	* A Term::Readline support to bin/rt for command recall and editing		* A Term::Readline support to bin/rt for command recall and editing
			** bin/rt already uses Term::Readline
	* [[Blacklist]] feature to prevent emails from being sent to no-respond addresses and receiving bounces.		* [[Blacklist]] feature to prevent emails from being sent to no-respond addresses and receiving bounces.
	* Pop-up window to open when a new ticket is opened. This helps in case the RT window is minimised. This will help us assign the tickets faster.		* Pop-up window to open when a new ticket is opened. This helps in case the RT window is minimised. This will help us assign the tickets faster.

195.68.92.104: /* Unknown state */ new wish : detect message-id

2012-09-10T10:50:37Z

Unknown state: new wish : detect message-id

← Older revision		Revision as of 06:50, 10 September 2012
Line 24:		Line 24:
	== Unknown state ==		== Unknown state ==

			* Store the Message-ID for each message in the database to enable thread detection via In-Reply-To and References in the mail gateway instead of ticket number ID ([http://cr.yp.to/immhf/thread.html more info])
	* Allow for multiple owners of a single ticket		* Allow for multiple owners of a single ticket
	* Add diff style display of changes for custom scrips, conditions and actions. (The unformatted old/new display can be hard to read.)		* Add diff style display of changes for custom scrips, conditions and actions. (The unformatted old/new display can be hard to read.)
Line 69:		Line 70:
	* Keyword feature, aka "tagging" or "Web 2.0". See del.icio.us, flickr, Slashdot's "tagging beta", metafilter, digg for examples. Useful for using resolved tickets as an self-organizing non-hierarchical knowledgebase ("This is an Jersey problem; maybe someone resolved a 'jersey' ticket similar to this?"). Faster than searching all text fields for mention of "jersey" (and someone might've spelled it "sweater" instead, or a client might put "wool shirt" in the original subject line.) Best implementation would offer autocompletion of tag words to encourage conformity (a-la the email fields in RT now; try del.icio.us for an example). --moomo		* Keyword feature, aka "tagging" or "Web 2.0". See del.icio.us, flickr, Slashdot's "tagging beta", metafilter, digg for examples. Useful for using resolved tickets as an self-organizing non-hierarchical knowledgebase ("This is an Jersey problem; maybe someone resolved a 'jersey' ticket similar to this?"). Faster than searching all text fields for mention of "jersey" (and someone might've spelled it "sweater" instead, or a client might put "wool shirt" in the original subject line.) Best implementation would offer autocompletion of tag words to encourage conformity (a-la the email fields in RT now; try del.icio.us for an example). --moomo
	* The ability to create a custom field without an input as a way to quickly customize queue specific screens (e.g. brief directions for filling out a ticket)		* The ability to create a custom field without an input as a way to quickly customize queue specific screens (e.g. brief directions for filling out a ticket)
	* the ability for several other fields to be visible once one is selected and saved. 3% of our tickets need 6 more fields but we don't want to muck the form up for all the other tickets.		* the ability for several other fields to be visible once one is selected and saved. 3% of our tickets need 6 more fields but we don't want to muck the form up for all the other tickets.
	*		*

Line 110:		Line 111:
	* Constant value for empty fields instead of localized string for "Not set".		* Constant value for empty fields instead of localized string for "Not set".
	* Definitive indication of a successful or failed login, when using REST.		* Definitive indication of a successful or failed login, when using REST.
	** Currently (RT4.0.1), session cookies are issues regardless of login success or failure, and besides parsing the body HTML content for a success or fail, the only other way is to look at the HTTP status (200 OK for a fail, and 302 Found for a success). If there is a definitive way, via HTML body inspection, what string should we be keeping an eye out for? Please update the REST wiki entry with info.		** Currently (RT4.0.1), session cookies are issues regardless of login success or failure, and besides parsing the body HTML content for a success or fail, the only other way is to look at the HTTP status (200 OK for a fail, and 302 Found for a success). If there is a definitive way, via HTML body inspection, what string should we be keeping an eye out for? Please update the REST wiki entry with info.

	=== Other ===		=== Other ===

206.76.160.61: /* Other */

2012-01-11T21:59:21Z

Other

← Older revision		Revision as of 17:59, 11 January 2012
Line 115:		Line 115:

	* Create multi-platform desktop widgets that can be used to perform simple actions on tickets via the web service URL, e.g. quickly resolve a ticket from my Mac OS X dashboard. --[[ChrisHardie]]		* Create multi-platform desktop widgets that can be used to perform simple actions on tickets via the web service URL, e.g. quickly resolve a ticket from my Mac OS X dashboard. --[[ChrisHardie]]
	* Allow users with admin rights to reassign tickets without having to steal them first.		* '''Allow users with admin rights to reassign tickets without having to steal them first.'''
	* Put a "Save Changes" buttom at the TOP as well as bottom on all Update Pages. ie. Config->Global->Group Rights & Config->Queue->Group Rights.		* Put a "Save Changes" buttom at the TOP as well as bottom on all Update Pages. ie. Config->Global->Group Rights & Config->Queue->Group Rights.
	** Allow the "Group Rights" pages the option of selecting which groups to show/not show. Similar to the list in "QuickSearch".		** Allow the "Group Rights" pages the option of selecting which groups to show/not show. Similar to the list in "QuickSearch".