1 files changed, 162 insertions, 0 deletions
diff --git a/rt/docs/design_docs/evil_plans b/rt/docs/design_docs/evil_plans
new file mode 100644
index 000000000..5b5cc58c1
--- /dev/null
+++ b/rt/docs/design_docs/evil_plans
@@ -0,0 +1,162 @@
+Current planned 2.2 feature list. subject to change.
+
+
+Core
+
+
+
+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
+
+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
+
+
+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. Sadly, the world doesn't agree with me
+
+
+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.