1 Current planned 2.2 feature list. subject to change.
6 Should Make "Owner" a watcher type, rather than a special ticket attribute,
7 under the hood. This wins for ACL and code consistency reasons.
11 Should New "Tools" top level menu
12 Should "This week in RT" at a glance.
13 Nice "RT Stats" overview.
14 Nice recent and favorite items
17 per-user configuration
19 Must Saveable user preferences.
21 The ideal implementation would be "saveable user metadata",
22 including things like "Alternate Email Addresses". To
23 do this right, not all user metadata would be directly
24 editable by the user who has "ModifySelf" it may be that
25 this is a "system" datastore that gets accessed by various
26 functions, some of which the user has access to modify and
27 some of which only the system does.
29 API: Set field "FOO" to value "BAR" for user BAZ
30 What values does field "FOO" have for user BAZ?
31 Clear all values of "FOO" for user BAZ
32 What users have value "BAR" for field "FOO"
36 What users have the alternative email address matching
38 What custom searches does user BAZ have defined?
39 What is baz's default queue?
41 Actually, I feel a little sketchy about Alternative Email
42 Addresses in there. I'm not quite sure why yet.
44 The same would really be useful for queues. Damn it. I think
51 Must Ability to define search result format.
52 should Saveable user searches.
53 nice Sharable searches.
58 must Include more Conditions; at least those contributed so far
59 that make sense in my grand scheme of things
61 should The name should change to something that people don't think is
62 spelled wrong. ("I will not invent words\n" x 1000)
64 nice Scrips could apply to a list of queues, rather than just one queue or
70 Must "KeywordSelects" become "Custom Fields"
71 Should String and multi-string custom fields.
72 Nice Date custom fields
73 Nice Some way to order and group custom fields.
76 Nice Make custom fields apply to an enumerated list of queues,
82 Must Full fastcgi support.
87 Should Better FSSTD conformance:
89 admin tools in /sbin (does this include rtadmin?)
90 ephemeral data in /var
92 force local RT search path?
96 must Integrate gpg-authenticated command-by-mail mode
102 should Use apache logging, if available
103 should Use syslog, if available.
104 should Mail user new password, as an Action, so it can be invoked either
105 as a scripaction or from the web ui.
109 Web Services Framework
111 Should Expose an API to create a ticket by HTTP posting an XML document.
112 Should Provide an RSS feed to display tickets matching certain criteria
113 Nice Allow ticket updates via the web ui
114 Nice Export full ticket metadata and history as XML
116 Note: I currently favor the REST philosophy that GET and POST to specific,
117 defined URLs provides everything one needs to build comprehensive
118 web services without the massive added complexity of a SOAP or XML-RPC
124 Wish New ACL primitives for:
126 List all users who have right "FOO" on object "BAR"
127 List all rights user "BAZ" has for object "BAR"
128 List all objects for which user "BAR" has right "FOO"
150 Jesse wants to get notified of all tickets in queue 'RT Bugs'
151 with a severity of 'critical' and also have a requestor whcih matches 'fsck.com'.
152 I'm not sure this is the best idea.
155 Site admins define a number of subscriptions and can sign up individual
156 users, groups or metagroups to get mail on that subscription.
158 Basically, an admin would define "On Condition, notify as comment with
161 There would be a new table called "subscriptions"(?) that would have
166 PrincipalType ENUM: User, Group, Owner, Requestors, AdminCcs, Ccs
167 PrincipalId -- UserId or GroupId. For Owner, Requestors, AdminCcs, Ccs, it doesn't really make a lick of difference.