1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
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.
|
