1 Current planned 2.2 feature list. subject to change.
10 Should New "Tools" top level menu
11 Should "This week in RT" at a glance.
12 Nice "RT Stats" overview.
13 Nice recent and favorite items
16 per-user configuration
18 Must Saveable user preferences.
20 The ideal implementation would be "saveable user metadata",
21 including things like "Alternate Email Addresses". To
22 do this right, not all user metadata would be directly
23 editable by the user who has "ModifySelf" it may be that
24 this is a "system" datastore that gets accessed by various
25 functions, some of which the user has access to modify and
26 some of which only the system does.
28 API: Set field "FOO" to value "BAR" for user BAZ
29 What values does field "FOO" have for user BAZ?
30 Clear all values of "FOO" for user BAZ
31 What users have value "BAR" for field "FOO"
35 What users have the alternative email address matching
37 What custom searches does user BAZ have defined?
38 What is baz's default queue?
40 Actually, I feel a little sketchy about Alternative Email
41 Addresses in there. I'm not quite sure why yet.
43 The same would really be useful for queues. Damn it. I think
50 Must Ability to define search result format.
51 should Saveable user searches.
52 nice Sharable searches.
57 must Include more Conditions; at least those contributed so far
58 that make sense in my grand scheme of things
60 should The name should change to something that people don't think is
61 spelled wrong. ("I will not invent words\n" x 1000)
63 nice Scrips could apply to a list of queues, rather than just one queue or
69 Nice Date custom fields
70 Nice Some way to order and group custom fields.
73 Nice Make custom fields apply to an enumerated list of queues,
82 Should Better FSSTD conformance:
84 admin tools in /sbin (does this include rtadmin?)
85 ephemeral data in /var
87 force local RT search path?
91 must Integrate gpg-authenticated command-by-mail mode
97 should Use apache logging, if available
98 should Use syslog, if available.
99 should Mail user new password, as an Action, so it can be invoked either
100 as a scripaction or from the web ui.
104 Web Services Framework
106 Should Expose an API to create a ticket by HTTP posting an XML document.
107 Should Provide an RSS feed to display tickets matching certain criteria
108 Nice Allow ticket updates via the web ui
109 Nice Export full ticket metadata and history as XML
111 Note: I currently favor the REST philosophy that GET and POST to specific,
112 defined URLs provides everything one needs to build comprehensive
113 web services without the massive added complexity of a SOAP or XML-RPC
114 framework. Sadly, the world doesn't agree with me
119 Wish New ACL primitives for:
121 List all users who have right "FOO" on object "BAR"
122 List all rights user "BAZ" has for object "BAR"
123 List all objects for which user "BAR" has right "FOO"
145 Jesse wants to get notified of all tickets in queue 'RT Bugs'
146 with a severity of 'critical' and also have a requestor whcih matches 'fsck.com'.
147 I'm not sure this is the best idea.
150 Site admins define a number of subscriptions and can sign up individual
151 users, groups or metagroups to get mail on that subscription.
153 Basically, an admin would define "On Condition, notify as comment with
156 There would be a new table called "subscriptions"(?) that would have
161 PrincipalType ENUM: User, Group, Owner, Requestors, AdminCcs, Ccs
162 PrincipalId -- UserId or GroupId. For Owner, Requestors, AdminCcs, Ccs, it doesn't really make a lick of difference.