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
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
|
Find tickets to operate on:
--id=<tickets> Find only tickets in the range <tickets>
synonyms:
--limit-id, --tickets, --limit-tickets
--limit-queue=<queue>
--limit-status=<status>
--limit-owner=<owner>
--limit-priority=<priority>
--limit-requestor=<email>
--limit-subject=<string> (Subject contains)
--limit-body=<string> (body contains)
--limit-created=(before/after) <date>
--limit-due=(before/after) <date>
--limit-starts=(before/after) <date>
--limit-started=(before/after) <date>
--limit-first=<int> Start on the <int>th row returned by the
database
--limit-rows=<int> Find only <int> rows
Display:
--show shows a ticket history
--history ditto
--summary default option. shows a ticket summary
--format Optional format string. If not specified,
uses the value of ENV{'RT_LISTING_FORMAT'}
or an internal default
Basic ticket editing:
--status=(open|stall|resolve|kill)
--subject=<string>
--owner=<owner>
--queue=<queue>
--time-left=<minutes>
Watcher-related editing:
--add-requestor=<email>
--del-requestor=<email>
--add-cc=<email>
--del-cc=<email>
--add-admincc=<email>
--del-admincc=<email>
Priority related editing:
--priority=<int>
--final-priority=<int>
Date related editing:
--due=date
--starts=date
--started=date
--contacted=date
Ticket updates:
--comment
--reply | --respond
Links
--add-link
--type=<DependsOn|MemberOf|RelatedTo>
needs one of:
--target=<ticketid>
--base=<ticketid>
--del-link <link-id>
Condiments:
any update can take:
--time-taken <minutes>
Ticket updates can take:
--source -- specify a source file to read the content from
--edit = give me an editor to edit the message
--no-edit = don't give me an editor to edit the message.
----- Forwarded message from deborah kaplan <deborah@curl.com> -----
Date: Fri, 14 Apr 2000 11:43:18 -0400 (EDT)
From: deborah kaplan <deborah@curl.com>
To: Jesse <jesse@fsck.com>
Subject: Re: [rt-devel] RT Projects list
Finally, here is the functional spec for the command line
interface. This is for the user interface only; if you think
this is right, I will add the administrative interface as well.
Should I post to rt-devel, add to the ticket, or just modify
based on your kibbitzing? When you are happy with it I'll start
the code.
-deborah
RT command line interface functional specification
Author: Deborah Kaplan (Deborah@suberic.net)
Version:0.1
Requirements:
RT needs a CLI for various reasons. If a user is restricted to a
dumb terminal, she needs to be able to access the RT database and
manipulate it fully. The full functionality of both the RT
database and the RT administrative interface should be available
from this CLI.
There are two possible types of CLI which I will discuss here.
The first is a curses-style interface, which allows the user to
move about a series of menus and choices, usually using arrow
keys. As RT supplies a Web interface, there is no need for this
curses-style interface to be written as part of RT. Instead, the
RT developers should pick one tty-based Web browser (e.g. lynx,
w3m) and make sure that all of the RT pages are easily readable
with that tty based browser. Installation of that browser should
be recommended in the RT installation documentation as a
supported method of accessing RT from a tty.
The second possible type of CLI is more minimal: a series of
commands which can be run at a UNIX command prompt which provide
full functionality to the RT database and administrative
interface. There are two major benefits to this second type of
CLI. First of all, in order to use this CLI, you need no extra
tools (Web browsers, etc.). All that is required is a UNIX
command line prompt and an installation of RT. Secondly, a user
of RT who has a very specific command to run and who knows the
appropriate CLI commands can accomplish her task much more
quickly with a single command then she could navigating through a
menu based interface.
In the specification, I will describe the second type of CLI.
Caveats:
This specification draws heavily on the structure of formatting
command line options for cvs. RT faces a smaller version of the
same kinds of problems cvs faces: we want to create a very rich
command set without sacrificing ease-of-use.
I am not wedded to any specific command names if they seem
impractical; I merely am proposing the command names that seem
reasonable to me at this moment.
Finally, I am finding the functioning of the web UI from RT 1.
If the functionality differs greatly in RT 2, I will need to
modify this specification.
Specification:
There are two commands: "rt", which is the primary interface to
the database, and "rtadmin", which is the administrative
interface to the database.
The format of an rt command is as follows:
rt <command>
<command> is one of:
- help
print an overview of the commands which can be run
- print <queue> <options>
with no options, dump to the screen a list of all open
requests in <queue> -- the equivalent of "Display Queue" in
the existing Web interface.
<queue> is the name of an RT queue
<option> is either:
-f <filename> | --filename <filename>
where <filename> is the name of a file (defaulting to
~/.rtrc) in which the options described below can be
placed in the format "^ <long option name> <option value>
$".
Or a series of the following options:
-o <owner name> | --owner <owner name>: restrict tickets
viewed to those owned by <owner name>.
This option can be used multiple times in one call of
the rt command in order to produce a list which
contains tickets owned by multiple owners. Giving the
empty string ("") as an option to this switch will
restrict tickets viewed to those which have no owner.
If this switch is given with no argument, the option
defaults to the user name of the currently running
process.
-r <requestor name> | --requestor <requestor name>:
restrict tickets viewed to those requested by <requestor
name>.
This option can be used multiple times in one call of
the rt command in order to produce a list which
contains tickets requested by multiple requesters. If
this switch is given with no arguments, it produces an
error.
-s <status> | --status <status>: restrict tickets viewed
to those with the status named in <status>.
This option can be used multiple times in one call of
the rt command in order to produce a list which
contains tickets with multiple statuses (statii?
Dragon NaturallySpeaking recognizes "statuses" as a
word). This option defaults to status "open".
-j <subject> | --subject <subject>: restrict tickets
viewed to those which contain <subject> as a substring in
the subject field of the ticket.
This command can be used multiple times in one call of
the rt command in order to produce a list which
contains tickets with various subject substrings. If
the option is called with no argument, the result is
an error.
-h | --help: print a usage message.
-n | --number: print out a specific ticket.
This command can be used multiple times to produce a
list which contains multiple tickets. If the option
is called with no argument, the result is an error.
This completes all of the print options which are available
in the Web interface, except the sort options. I maintain
that this command is already excessively complex, and that
adding functionality which can be replicated easily by
standard UNIX tools is unnecessary added complexity. I
recommend that the man pages and documentation for this
option contain an example of a command line run (e.g. of rt |
awk) which replicates the sorting functionality provided by
the Web interface.
- edit <ticket> <options>
with no options, or with no <ticket>, produces the same
output as the --help option.
Otherwise, edits the ticket with number <ticket> as
indicated in the options given. All options listed below
except for --help and --number can be used in conjunction
with one another to change many features of the same ticket
all at once.
-h | --help: print usage message
-s <status> | --status <status>: change the status to the
status listed in <status>.
No <status> listed, or 1 listed it does not come from
a list of approve statuses, produces an error.
-o <owner name> | --owner <owner name>: set to the owner
of the ticket the owner named.
Follows whatever convention is finally decided on for
the requirement to steal a ticket that is owned by
somebody else. No <owner named> listed has the user
who is running the rt program take the ticket. If
that user is not a valid owner, or the 1 listed does
not come from a list of approve names, produces an
error.
-r <requestor name> | --requestor <requestor name>: sets
the requestor to <requestor name>.
Follows any conventions that the Web UI follows to
make sure that this is a legal name. If not legal, or
left blank, produces an error.
-j <subject> | --subject <subject>: sets the subject of
the ticket to <subject>.
If the option is called with no argument, the result
is an error.
-n <number one> <number 2> | --number <number one>
<number 2>: merges ticket number <number one> into ticket
<number 2>.
If both arguments are not provided, the result is an
error.
-q <queue> | --queue <queue>: set the queue to that
named.
If <queue> is not listed, or the 1 listed does not
come from a list of approve queues, produces an
error.
-a <area> | --area <area>: set the area of the ticket to
that named.
If <area> is not listed, or the 1 listed does not come
from a list of approve areas, produces an error.
-c <time stamp> | --contact <time stamp>: sets the last
user contact field, and produces an error if the format
is invalid.
If the argument is left blank, sets the last user
contact field to now.
-p <priority> | --priority <priority>: sets the current
priority to the 1 listed.
Produces an error if the argument is left blank.
-f <priority> | --final <priority>: sets the final
priority to the 1 listed.
Produces an error if the arguments left blank.
-d <date due> | --datedue <date due>: sets the due date
to the 1 listed.
Produces an error if the argument is left blank, or if
the format is invalid.
- comment <options>
with no options, this command reads from standard input
until it sees EOF and appends that to the ticket as a
comment.
-h | --help: print usage message
-c | --comment: append as a comment. This is the default behavior.
-r | --reply: append as a reply.
-f <filename> | --file <filename>: can be used with
either the comment or reply options. Instead of reading
from standard input, read the text of the comment or
reply from the file <filename>.
- report <options>
this command is a place holder for reporting functionality
which does not yet exist. It will probably have the
default behavior to select reports at the command line or
choose default reports from a .rtrc file. In a future
version, it can output graphs in some graphical format.
----- End forwarded message -----
--
jesse reed vincent -- root@eruditorum.org -- jesse@fsck.com
70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90
"If IBM _wanted_ to make clones, we could make them cheaper and faster than
anyone else!" - An IBM Rep. visiting Vassar College's Comp Sci Department.
|