Current planned 2.2 feature list. subject to change.


Core

Should	Make "Owner" a watcher type, rather than a special ticket attribute,
	under the hood.  This wins for ACL and code consistency reasons.

Web UI

Should	New "Tools" top level menu
Should		"This week in RT" at a glance.
Nice		"RT Stats" overview.
Nice	recent and favorite items


per-user configuration

Must		Saveable user preferences.

		The ideal implementation would be "saveable user metadata",
		including things like "Alternate Email Addresses".  To 
		do this right, not all user metadata would be directly
		editable by the user who has "ModifySelf"  it may be that
		this is a "system" datastore that gets accessed by various
		functions, some of which the user has access to modify and
		some of which only the system does.
		
		API:	Set field "FOO" to value "BAR" for user BAZ
			What values does field "FOO" have for user BAZ?
			Clear all values of "FOO" for user BAZ
			What users have value "BAR" for field "FOO"

		Example usages:

			What users have the alternative email address matching 
			"boo@fsck.com"
			What custom searches does user BAZ have defined?
			What is baz's default queue?

		Actually, I feel a little sketchy about Alternative Email 
		Addresses in there. I'm not quite sure why yet.

		The same would really be useful for queues. Damn it. I think
		I want a registry.



Searching

Must	Ability to define search result format.
should 	Saveable user searches.
nice	Sharable searches.


Scrips

must	Include more Conditions; at least those contributed so far
	that make sense in my grand scheme of things

should	The name should change to something that people don't think is
	spelled wrong.	("I will not invent words\n" x 1000)

nice	Scrips could apply to a list of queues, rather than just one queue or 
	all of them.


Custom fields

Must	"KeywordSelects" become "Custom Fields"
Should	String and multi-string custom fields.
Nice	Date custom fields
Nice	Some way to order and group custom fields.
Nice	Default values
Nice	Required values
Nice	Make custom fields apply to an enumerated list of queues, 
	rather than just one. 


Web infrastructure

Must	Full fastcgi support.


Installation 

Should	Better FSSTD conformance:
		bins in /bin
		admin tools in /sbin (does this include rtadmin?)
		ephemeral data in /var
		rename config file	
		force local RT search path?	

Mail gateway

must	Integrate gpg-authenticated command-by-mail mode
	


Core

should	Use apache logging, if available
should	Use syslog, if available.
should	Mail user new password, as an Action, so it can be invoked either 
	as a scripaction or from the web ui.



Web Services Framework

Should	Expose an API to create a ticket by HTTP posting an XML document.
Should  Provide an RSS feed to display tickets matching certain criteria
Nice	Allow ticket updates via the web ui
Nice	Export full ticket metadata and history as XML

Note: 	I currently favor the REST philosophy that GET and POST to specific,
	defined URLs provides everything one needs to build comprehensive
	web services without the massive added complexity of a SOAP or XML-RPC
	framework.


ACLs:

Wish	New ACL primitives for:

		List all users who have right "FOO" on object "BAR"
		List all rights user "BAZ" has for object "BAR"
		List all objects for which user "BAR" has right "FOO"


















For the near future:

	Use case:
		Jesse wants to get notified of all tickets in queue 'RT Bugs'
		with a severity of 'critical' and also have a requestor whcih matches 'fsck.com'.  
		I'm not sure this is the best idea.


	Site admins define a number of subscriptions and can sign up individual
	users, groups or metagroups to get mail on that subscription.

	Basically, an admin would define "On Condition, notify as comment with
	template _template_"

	There would be a new table called "subscriptions"(?) that would have
	the structure:

		id
		ScripId
		PrincipalType  ENUM: User, Group, Owner, Requestors, AdminCcs, Ccs
		PrincipalId --  UserId or GroupId.  For Owner, Requestors, AdminCcs, Ccs, it doesn't really make a lick of difference.