import rt 2.0.14

[freeside.git] / rt / docs / design_docs / evil_plans

diff --git a/rt/docs/design_docs/evil_plans b/rt/docs/design_docs/evil_plans
new file mode 100644 (file)
index 0000000..34b9f81
--- /dev/null
+++ b/rt/docs/design_docs/evil_plans
@@ -0,0 +1,167 @@
+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.