diff options
Diffstat (limited to 'rt/docs')
| -rwxr-xr-x | rt/docs/README.docs | 2 | ||||
| -rw-r--r-- | rt/docs/Security | 25 | ||||
| -rwxr-xr-x | rt/docs/design_docs/CARS | 66 | ||||
| -rwxr-xr-x | rt/docs/design_docs/TransactionTypes.txt | 48 | ||||
| -rw-r--r-- | rt/docs/design_docs/acls | 206 | ||||
| -rw-r--r-- | rt/docs/design_docs/basic-definitions.txt | 54 | ||||
| -rw-r--r-- | rt/docs/design_docs/cli_spec | 354 | ||||
| -rw-r--r-- | rt/docs/design_docs/cvs_integration | 164 | ||||
| -rw-r--r-- | rt/docs/design_docs/evil_plans | 167 | ||||
| -rw-r--r-- | rt/docs/design_docs/link-definitions.txt | 143 | ||||
| -rw-r--r-- | rt/docs/design_docs/local_hacking | 32 | ||||
| -rwxr-xr-x | rt/docs/design_docs/subscription-definitions.txt | 113 | ||||
| -rw-r--r-- | rt/docs/design_docs/users | 14 | ||||
| -rwxr-xr-x | rt/docs/rt.gif | bin | 0 -> 8811 bytes |
14 files changed, 1388 insertions, 0 deletions
diff --git a/rt/docs/README.docs b/rt/docs/README.docs new file mode 100755 index 000000000..38866b357 --- /dev/null +++ b/rt/docs/README.docs @@ -0,0 +1,2 @@ +Questions about docs should be sent to the RT Documentation Team (rt-docs@fsck.com) +which is led by Meri. diff --git a/rt/docs/Security b/rt/docs/Security new file mode 100644 index 000000000..c9787ac52 --- /dev/null +++ b/rt/docs/Security @@ -0,0 +1,25 @@ +RT2 runs setgid to some group (it defaults to 'rt'). + +rt's configuration file, 'config.pm', is not world readable because it +contains rt's database password. If a user gets access to this file, he +can arbitrarily manipulate the RT database. This is bad. You don't want +this to happen. config.pm is mode 550. No users should be members of +the 'rt' group unless you want them to be able to obtain your rt password. + +If you're running the web interface, you'll need to make sure your webserver +has access to config.pm. You could do this by letting your webserver's user +be a member of the 'rt' group. This has the disadvantage of letting +any mod_perl code on your web server have access to your RT password. + +Alternatively, you can run RT2 on its own apache instance bound to a high +port on 127.0.0.1 +which runs as a non-priviledged user which is a member of the group 'rt'. + +Configure your webserver to proxy requests to RT's +virtual directory to the apache instance you just set up. + +TODO: doc the apache configs needed to do this. + +The same technique can be used to run multiple RT2 instances on the same host. + + diff --git a/rt/docs/design_docs/CARS b/rt/docs/design_docs/CARS new file mode 100755 index 000000000..a4d2a78c5 --- /dev/null +++ b/rt/docs/design_docs/CARS @@ -0,0 +1,66 @@ +Conditional Automated Request Shuffler +Initial Design. <jesse@fsck.com> 9 Nov 99 + +#Try to find out what queue the incoming ticket is in +#Try to find out the default action for this invocation +#Read the ticket from STDIN +#Obtain the actor +#Obtain the serial # if we have one +#If the ticket has a ticket-id + #if this is a 'comment' + #add the current mime objects as a 'comment' + + #if this is 'correspondence' + #add the current mime object as 'correspondence' + + +#if this ticket does not yet have a ticket id + + #For now: + #Create a new ticket + + #In the distant future + + #load the regexp table matching this queue + #check the message agains the regexp table, ordered by precedence + #when we get a match + #get the ruleset for that regexp from the actions table + #evaluate the ruleset in order of precedence. + #if we get an 'exit' stop proccesing ALL rulesets +wpw #if we get a 'forward,' forward it to 'value'. + + #if we get a 'create,' create a request in 'value' + #elseif we get a 'map', add this as additional correspondence on ticket 'value' + + + #if we get an 'associate', associate the ticket number returned from the + 'create' or 'map' with the master ticket from 'value' + + #if we get a 'reply', + #load the reply template with id 'value' + #replace strings in the template + #send the template + + + + +CREATE TABLE Rules { +ID int AUTO_INCREMENT, +Desc varchar(120), +Regexp varchar(80), +Precedence int, +MatchField varchar(20), #Can be a headername or 'any' all header names + #end in : + + +CREATE TABLE Actions { +Rule int, +Action varchar(20), # Create, Forward, Squelch, Owner, Area, Associate +Value varchar(20), #queue or email address +Desc varchar(120) +} + +CREATE TABLE Autoreplies { +ID int AUTO_INCREMENT, +Content text +);
\ No newline at end of file diff --git a/rt/docs/design_docs/TransactionTypes.txt b/rt/docs/design_docs/TransactionTypes.txt new file mode 100755 index 000000000..942b72371 --- /dev/null +++ b/rt/docs/design_docs/TransactionTypes.txt @@ -0,0 +1,48 @@ +This is some loose scrabbling made by TobiX, they might eventually be relevant +for 2.1. + +INTERFACES, in general + +should: + +- provide the user (client?) with a list of possible actions (methods). +- let the user execute those actions (methods). +- Return information to the user/client. + +There are two kind of actions/methods: + +- Information retrieval +- Transactions + +For the first, I think the best thing is to just provide a lot of +methods for it in the libraries, and let it be an Interface Design +Issue what to show and how to show it. + +For the second, I think we can win in the long run on having a +generalized methods for + +- listing transaction types. +- creating & committing transactions. + +..with the possibility of just deploying new custom-developed modules +when new transaction types are needed. + + +$RT::TransactionTypes ...and... +%RT::TransactionTypes + - global object which contains all TransactionTypes + - used by all UIs to create menues of possible (user) actions (one TransactionType is a user action) + +The UIs should call sth like +$Ticket->AddTransaction($TransactionName), which should be equivalent +with i.e. $Ticket->Correspond when $TransactionName is 'Correspond' +(AUTOLOAD should call the do-sub if exists +$RT::TransactionTypes{$TransactionName}) + +The RT::Ticket::AddTransaction will create a new transaction of the +right TransactionClass (maybe via a sub +RT::TransactionTypes::NewTransaction). Then $Transaction->do is +called. + +TransactionType->do initializes a new object of the right TransactionClass, and + diff --git a/rt/docs/design_docs/acls b/rt/docs/design_docs/acls new file mode 100644 index 000000000..3b9d8567c --- /dev/null +++ b/rt/docs/design_docs/acls @@ -0,0 +1,206 @@ +$Header: /home/cvs/cvsroot/freeside/rt/docs/design_docs/acls,v 1.1 2002-08-12 06:17:07 ivan Exp $ + + + +# {{{ Requirements + +Here's the rough scheme I was thinking of for RT2 acls. Thoughts? I think +it's a lot more flexible than RT 1.0, but not so crazily complex that +it will be impossible to implement. One of the "interesting" features +is the ability to grant acls based on watcher status. This now lives +in design-docs/acls + + jesse + +Who can rights be granted to: + + users whose id is <foo> + users who are watchers of type <requestor/cc/admincc> for <queue/ticket> <id> + users who are watchers of type <requestor/cc/admincc> for <this ticket / this queue> + + +what scope do these rights apply to + queue <id> + system + + +What rights can be granted + Display Ticket + Manipulate Ticket + Only users with manipulate ticket level access will see comments + Maniplulate Ticket Status + Create Ticket + + Admin Queue Watchers + Admin Ticket Watchers + Admin user accounts + Admin scrips + Admin scripscopes + Admin Queue ACLS + Admin System ACLs + +# }}} + + +# {{{ Prinicpals These are the entities in your Access Control Element +# + +Principal: What user does this right apply to + + Made up of: + PrincipalScope, PrincipalType and PrincipalId + + + User: + Scope: User + Type: null + Id: A userid or 0 + + Owner: + Scope: Owner + Type: null + Id: none + + + Watchers: + + Scope: Ticket + Type: Requestors; Cc; AdminCc + Id: A ticket id or 0 for "this ticket" + + Scope: Queue + Type: Cc; AdminCc + Id: A queue id or 0 for "this queue" + + +# }}} + +# {{{ Object: What object does this right apply to + + Object is composed of an ObjectType and an ObjectId + + Type: System + Id: NULL + + Type: Queue + Id: Integer ref to queue id or 0 for all queues + +# }}} + +# {{{ Right: (What does this entry give the principal the right to do) + + + + For the Object System: + System::SetACL + System::AdminScrips + + User::Display + User::Create + User::Destroy + User::Modify + User::SetPassword + + + + For the Object "Queue": + Queue::Admin + Queue::SetACL + Queue::Create + Queue::Display + Queue::Destroy + Queue::ModifyWatchers + Ticket::Create + Ticket::Destory + Ticket::Display + Ticket::Update + Ticket::UpdateRequestors + Ticket::UpdateCc + Ticket::UpdateAdminCc + Ticket::NotifyWatchers + + + DEFERRED + + Ticket::SetStatus: (Values) + Open + Resolved + Stalled + <null> means any + + +# }}} + + +# {{{ Implementation: + +# {{{ SQL Schema +CREATE TABLE ACL ( + id int not null primary_key autoincrement, + PrinicpalId INT(11), + PrincipalType VARCHAR(16), + PrincipalScope VARCHAR(16), + ObjectType VARCHAR(16), + ObjectId INT, + Right VARCHAR(16) +); + +# }}} + +# {{{ perl implementation of rights searches + +sub Principals { +if (defined $Ticket) { + return "($UserPrincipal) OR ($OwnerPrincipal) OR ($WatchersPrincipal)"; + } +else { + return "($UserPrincipal) OR ($WatchersPrincipal)"; + } +} + +$Principals = " ($UserPrincipal) OR ($OwnerPrincipal) OR ($WatchersPrincipal)"; + +$UserPrincipal = " ( ACE.PrincipalScope = 'User') AND + ( ACE.PrincipalId = $User OR ACE.PrincipalId = 0)"; + +$OwnerPrincipal = " ( ACE.PrinciaplScope = 'Owner') AND + ( Tickets.Owner = "$User ) AND + ( Tickets.Id = $Ticket)"; + +$WatchersPrincipal = " ( ACE.PrincipalScope = Watchers.Scope ) AND + ( ACE.PrincipalType = Watchers.Type ) AND + ( ACL.PrincipalId = Watchers.Value ) AND + ( Watchers.Owner = $User )"; + +$QueueObject = "( ACE.ObjectType = 'Queue' and (ACE.ObjectId = $Queue OR ACE.ObjectId = 0)"; + +$SystemObject = "( ACE.ObjectType = 'System' )"; + + +# This select statement would figure out if A user has $Right at the queue level + +SELECT ACE.id from ACE, Watchers, Tickets WHERE ( + $QueueObject + AND ( ACE.Right = $Right) + AND ($Principals)) + +# This select statement would figure outif a user has $Right for the "System" + +SELECT ACE.id from ACE, Watchers, Tickets WHERE ( + ($SystemObject) AND ( ACE.Right = $Right ) AND ($Principals)) + +# }}} + +# }}} + +# {{{ Examples +# + +# }}} + + + +Unaddressed issues: + + There needs to be a more refined method for grouping users, such that members of the customer service department +can't change sysadmins' passwords. diff --git a/rt/docs/design_docs/basic-definitions.txt b/rt/docs/design_docs/basic-definitions.txt new file mode 100644 index 000000000..23d2c5748 --- /dev/null +++ b/rt/docs/design_docs/basic-definitions.txt @@ -0,0 +1,54 @@ +(todo ... basically, those are untouched from 1.0) +Ticket +Queue +(...more?) + +Requestor + + (...definition of a requestor .. blahblah) + + I'm often doing a distinction between "Internal Requestors" and "External + Requestors" (see below). The system doesn't make any difference between + requestors, but the distinction might be useful to discuss usage patterns, + templates and configurations. + + +External Requestor + + Might be a customer or a potential customer. The External Requestor + should be treated as a VIP. (S)he shouldn't need to see too much of RT. + The support (s)he gets should be as personal as possible. The external + requestor might eventually get access to the Web UI, but only to track + her/his own requests. If you're not planning to use RT for handling + external customers, all your requestors are probably "Internal + Requestors". + + +Watcher + + Somebody that are "subscribing" to a queue or a ticket (or something + differently). Basicly, somebody watching a queue or a ticket should get + all updates by email. A requestor is a (special) watcher. + + +Regular Watcher + + People within the same organization, people that have read access to whole + queues. + + I consider "Regular Watchers" as well as "Internal Requestors" as more + robust and capable human beeings than the fragile customers. We don't + mind letting them get entagled with RT, and we let them access the Web UI. + They can live with beeing just the Cc or Bcc at an email. + + +Internal Requestor + + An Internal Requestor is usually internal to the company. He might be 1st + line support sending matters to tech support or similar. Might be an + internal employee sending matters to tech support (or even 1st line + support if he's not sure where to send matters). It might also be that + "ordinary" requestors actually might be treated as intelligent human + beeings rather than VIPs, i.e. in open source projects ... we'll still + call them "Internal Requestors" as they don't need the special VIP + treatment. diff --git a/rt/docs/design_docs/cli_spec b/rt/docs/design_docs/cli_spec new file mode 100644 index 000000000..48a7f34e1 --- /dev/null +++ b/rt/docs/design_docs/cli_spec @@ -0,0 +1,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. + diff --git a/rt/docs/design_docs/cvs_integration b/rt/docs/design_docs/cvs_integration new file mode 100644 index 000000000..35c8737ed --- /dev/null +++ b/rt/docs/design_docs/cvs_integration @@ -0,0 +1,164 @@ +jesse@FSCK.COM: ok. anyone here + interested in having RT as a bug tracker integrated with CVS? () + +marc: in principle, sure. () + +jesse@FSCK.COM: want to write up your + ideal of how such a beast would work? () + +alex_c: what sort of integration are you thinking of, Jesse? () + +jesse@FSCK.COM: well, that's what I want + to know, alex. lots of people want their bug trackers tied to their + version control. I want to know what people want it to _do_ ;) () + +alex_c: weird. :) () + +marc: similarly to what the debian bts does. + you put a magic string ("rt-closes#123") and it causes the bug in rt to + be closed (or appended with a different magic string) with the commit + message. also nice would be if rt would then generate links to a + webcvs server. () + +jhawk: Hrmm. cvs front-end that strips 'em out? + Perhaps with RT: lines instead of CVS: lines in the commit + interaction? () + +marc: the magic string goes in the commit + message, that is. no, use one of the magic post-commit scripts. () + + +jesse@FSCK.COM: well, there's also the + pre-commit script to lock out commits wihtout a ticket id () + +jhawk: Personally, I don't want to force special + magic strings to the bug-tracking system, some of which may be + confidential, to appear in the cvs logs. () + +marc: I could see wanting that on a release + branch. () + +jhawk: I also think it would be cool to supply + template stuff for you to edit. () + +jesse@FSCK.COM: I'm not sure cvs can be + made to do that. can it? (generate templates) () + +jhawk: It would be reasonable, in my model, to + turn some kinds of RT: lines into things that fell in the commit + message, but not all kinds. () + +marc: I don't quite see jhawk's objection. () + +ghudson: In my observation, locking out commits + without a ticket ID is usually an impediment to development, and leads + to developers having the one bug which all commits cite. () + +jhawk: If you had a CVS frontend, it could geneate + the template and feed it to 'cvs commit -m' () + +ghudson: CVS can generate templates and verify + that they have been filled in. () + +jhawk: What Greg says sounds cool; greg, what do + you mean? marc: one sec. () + +marc: I think assuming a frontend is a terrible + idea. () + +jesse@FSCK.COM: greg: agreed. but people + seem to want it. the idea would be only for a locked down release + branch. () + +jhawk: marc: So, I might want to close an open + ticket as part of a commit message without that showing up in the + coommit message. Or to insert a splufty long comment into a ticket + while I do the commit but not close or really change the state, and + that comment might want to ramble a lot but not include that ramble in + the commit message. () + +jesse@FSCK.COM: well, then arguably, you + might want to not use the commit message for that update, but instead + just go straight to the bts () + +marc: I think the idea is to force you to + mention the ticket closing in the commit message. () + +jesse@FSCK.COM: but yeah, state changing + and 'update messages' are seperate concepts that should both be + supported. () + +jesse@FSCK.COM: part of the idea is to + drag the commit message into the BTS () + +jhawk: Err, I think it quite frequent that I want + to put seperate info in both the commit message and the ticket system, + and entering them at the same time seems cool. () + +jesse@FSCK.COM: ok. noted. I'll see if + that's doable, when i get around to this. () + +marc: so I think you want a custom front-end, + but I don't think what you want is what jesse is talking about. () + +jesse@FSCK.COM: the thing that would be + really cool that scare the pants off me is tracking which branches bugs + exist in / are fixed in () + +jesse@FSCK.COM: what jhawk wants should + be doable, now that I understand his reqts. () + +marc: that would require the bts to understand + branches in some fundamental way. () + +jesse@FSCK.COM: yes. see above, about + the pants. () + +sly: uh oh, not more people losing their pants... .. + + +ghudson: RT needs to know the names of branches + and their structure (so that you can tell it "fixed in foo" and it + knows that the bug is still fixed in anything that branches off of foo, + but not necessarily in other new branches), but nothing more than that. + +jhawk: So, note that what I'm describing is how + I'd like the UI to be, from a generic architectural level, and not + really thinking terribly specific. Greg, can you explain the CVS + template thing? () + +jesse@FSCK.COM: and it needs to know + exactly "when" a branch happens. because "fixed in foo" won't fix + something that branched off foo yesterday () + +marc: jesse was talking about integrating rt + with cvs. building a new developent+repository+bts from scratch would + be a problem with larger scope :-) () + +jesse@FSCK.COM: marc: was that in + response to jhawk? () + +ghudson: CVS and templates: "rcsinfo" lets you + specify a template for log messages, and "commitinfo" lets you check + them. () + +ghudson: Er, sorry, my bad. + s/commitinfo/verifymsg/ () + +marc: with cvs, if you have the revision number + of the fix (which you should). you can use the branch version number to + get a date and see when the branch happened relative to the fix. () + +marc: jesse: yes. () + +jesse@FSCK.COM: Ok. would people + consider "integration with CVS" to be subpar or incomplete if it didn't + deal with tracking branches? () + +marc: incomplete relative to an ideal, but not + subpar, as it would still be useful. () + +allbery@CS.CMU.EDU: CVS's branch + support sucks so much that failure to work with it is hardly a bug () + + diff --git a/rt/docs/design_docs/evil_plans b/rt/docs/design_docs/evil_plans new file mode 100644 index 000000000..34b9f81a2 --- /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. diff --git a/rt/docs/design_docs/link-definitions.txt b/rt/docs/design_docs/link-definitions.txt new file mode 100644 index 000000000..30b903567 --- /dev/null +++ b/rt/docs/design_docs/link-definitions.txt @@ -0,0 +1,143 @@ +For 2.0, those Linking actions should be supported: + +1. DependentOn; TobiX-style. + + BASE is dependent on TARGET. + + ...meaning that TARGET has to be resolved before BASE (really) is + resolved. + + According to TobiX, those "weird action" makes sense: + ...when the link and/or TARGET is created, the BASE might be stalled. + Alternatively, this should be very trivial to request through the UIs. + ...when the TARGET is resolved, BASE will be reopened if it's stalled. + + An alternative to those "weird actions" is to have some run-time logic that + takes care of this; i.e. letting the search interface handle "please hide + all requests with unresolved dependencies" + + TobiX will need to make dependency links into Bugzilla. + + Dependency links should be made when more work to BASE should be done + after the TARGET is resolved and/or BASE can't be resolved before TARGET is + resolved. + + Dependency links are often 1:1, but n:n links makes sense; one ticket can + depend on several others, several tickets can depend on one ticket, etc. + + Loops don't make sense at all, but the system above won't break if it + encounter loops. + + Dependency links is more for workflow than anything else. When a new + TARGET is created, some of the work might be passed over to another + department/person ... but _not_ the responsibility for the communication + with the external requestor. + +2. MemberOf link (grouping) + + BASE is a member of TARGET. + + TobiX-style "weird actions": + ...when TARGET is beeing replied to, all BASE requestors should get the + reply. + + ...when TARGET is resolved, all BASE tickets should be resolved (unless + they have other unresolved Dependencies/MemberOf links). + + ...when all BASEs to one TARGET are resolved, TARGET should be resolved. + + The alternative is to let the user choose "reply to all" and "resolve all" + through the user interfaces. + + MemberOf should be used when BASE ticket states more or less the same as + the TARGET ticket, and we do want to give a reply to all requestors, but we + don't want to merge them (Individual tickets from individual external + requestors should be respected as separate entities). If BASE tickets from + more than one external requestor is linked to a TARGET ticket, we denote + the TARGET ticket as a "Group ticket". This is only a documentation + definition, you won't find any references to "Group tickets" in the source. + + I think the proper etiquette should be to clearly state in a reply to a + group ticket that the mail is going to several persons, and that the + requestor should reply back if they feel their Ticket hasn't got the + attention it deserves. The user documentation should reflect this. + + MemberOf links can also be used to hand away the work flow. The person in + charge of the TARGET ticket will also be in charge of the BASE tickets and + the communication with the end user. + + If a work task needs to be splitted into two subtasks, MemberOf might also be + used. + + 1:n links makes more sense, but n:n can also work in some cases. + The reply stuff might break seriously upon loops. Recursement might be + handy for splitting a work task into subtasks (making a hierarchical tree + of the worktasks). + + +3. Merge (connecting) + + BASE is the same as TARGET. + + ...the system should somehow merge together transactions for both tickets. + ...BASE should be more or less deleted, only the TARGET should apply. + ...actions done toward BASE should be redirected to TARGET. + + I think MergeLinks should be used when two tickets accidentally has + appeared twice in the system, and/or there is no reason to keep the two + tickets separately. It might be that it's the same requestor (i.e. + clicking the "send" button twice in a web environment) or that we don't + care much about giving the requestor individual follow-up (typically + "internal" requestors, etc.) + + Based on user feedback, merged tickets will be displayed as the same ticket +within RT's user interfaces. but the original tickets' transactions will be +kept seperated in the database. this may require some magic. + +4. RefersTo / No Action link (linking) + + BASE is somewhat related to TARGET + + No special actions will be taken. + + Loops might maybe make sense + +BASE and TARGET are usually Tickets within one RT instance, but it +might also point to external RT instances, other DB systems, etc. + + + + +In future revisions, it should be very easy to set up site-specific link action types. +We should also consider to include more linking actions in the box. + +An example stolen from John Rouillard. Eventually the [comments] should be +removed, and the text modified to fit the planned 2.0 link actions: + + ticket problem + 1 can't connect to hosts with netscape + 2 ping is broken + 3 Can't send email: error no space on spool/mqueue + + You have the above in the queue. You realize that DNS is down. Spawn + a ticket + + 4 DNS is down + + mergelink 1 and 2 to it [I would rather say "make a MemberOf link _or_ a + dependency link from 1 and 2 to 4" --TobiX] (if you choose to stall 1 and + 2 automatically feel free, its just a shell script change) [well, you + might choose dependency instead of MemberOf --TobiX]. The person working + on 3 has come to the conclusion that outgoing mail is backing up because + of the DNS failure. She has cleared space by copying the mail queue to + another disk, but can't really get email working till DNS is up. So she + creates a Dependency linkon ticket 4 stalling ticket 3. + + We finally get DNS working and resolve ticket 3. What happens? Tickets 1 + and 2 are resolved and email is sent to requestors notifying them of the + resolution [This is the default behaviour for 2.0 MemberOf-linked tickets. + Remember that if we send Replies to "Group Tickets" (that is, the target + of several "MemberOf" links) --TobiX]. Ticket 4 [should be 3? --TobiX] is + reopened and the person working on it starts flushing the mail queue and + the moved mailq by hand. + diff --git a/rt/docs/design_docs/local_hacking b/rt/docs/design_docs/local_hacking new file mode 100644 index 000000000..c06d1126d --- /dev/null +++ b/rt/docs/design_docs/local_hacking @@ -0,0 +1,32 @@ +To facilitate local hacking, RT needs a mechanism to allow site administrators +to easily add HTML templates for the web ui and to replace sections +of code in RT's core modules _without_ having to modify those modules + +We'll use several methods to achieve this goal. + + Webui + HTML::Mason allows users to create multiple +component hierarchies. RT should ship with a local component root +defined and available. This root should be configured as the "primary" +component root. + + + Core modules + + This gets a bit trickier. we want to allow people to trivially +subclass core modules and to use those subclasses throughout the code. + +The way we're going to handle this is by setting up a number of subroutines +in config.pm that look something like this: + +sub NewTicketObj { + eval "require $TicketClass"; + my $object = new $TicketClass; + return ($object); +} + +# This variable is used for ref type checking +$TicketClass = "RT::Ticket"; + +we could use an eval around the require and thus completely avoid specifying +the object in two places. which feels like a win. but i'm worried about perf. diff --git a/rt/docs/design_docs/subscription-definitions.txt b/rt/docs/design_docs/subscription-definitions.txt new file mode 100755 index 000000000..deda35cda --- /dev/null +++ b/rt/docs/design_docs/subscription-definitions.txt @@ -0,0 +1,113 @@ +NEW SCRIP NOTES + + +RT Actions: + + + EmailOwnerAsComment + Send mail to the ticket owner from the queue's comment address + + EmailOwnerOrAdminWatchersAsComment + Send mail to the ticket owner, or if there is no owner, the ticket's admin watchers + from the queue's comment addresses + + EmailAdminWatchersAsComment + Send mail to the ticket's adminstrative watchers from the queue's comment address + + + + EmailOwner + Send mail to the ticket owner from the queue's correspond address + + EmailOwnerOrAdminWatchers + Send mail to the ticket owner, or if there is no owner, the ticket's admin watchers + from the queue's correspond addresses + + EmailAdminWatchers + Send mail to the ticket's adminstrative watchers from the queue's correspond address + + EmailWatchers + Send mail to the ticket watchers from the queue's correspond address + + AutoReply + Sendmail to the requestor from the queue's correspond address. + + + +RT Conditions: + OnCreate + OnEachTransaction + OnComment + OnCorrespond + + + + + +What is an Action? + +...some piece of code that can do something whenever a transaction is done. +The actions shipped with RT sends email and can handle some logic that makes +sense for some instances. site-specific modules can be dropped in to +perform special actions. + + +What can an Action do? + +- decide whether it's applicable or not +- prepare +- commit +- describe itself + +...and if it's a subclass of SendEmail, you can also override a lot. + +Currently the schema.mysql contains a list of the basic subscription-related +actions that will be bundled with RT. + + +What is a Scrip? + +...it's an entry in the database that tells that an action is to be +performed with a certain template and argument. Template and argument +doesn't make sense in all contexts. A scrip can be limited to transaction +types; the current implementation allows a comma-separated list (though for +a "cleaner" schema design, it should be a separate table for this?). It has +a name and a description. + + +What is a ScripScope? + +...an indication of what queues the different Scrips applies to. It should +be easy to remove/insert ScripScope objects by the admin tools. + + +What is a Watcher? + +...it's a request for beeing kept updated on a ticket and/or a queue +and/or whatever. It is to be used by the Actions. Watcher items can +easily be enabled/disabled through the `Quiet' attribute. `Type' might +indicate what emails the watcher wants to get and how to get them. + +The Bcc/Cc watchers should be handled by the NotifyWatchers action which is +run regardless of the Scrips. + + +What is a Template? + +...A template is a text template that is to be used for outgoing email - +or for different use for different actions. One template can be used by +several Scrips. + + +How does the system determinate whom to send mail to? + +The ScripScope table in the DB should indicate whether a Scrip is relevant +for a queue or not /* TobiX thinks that this might eventually be extended to +keywords, tickets, etc, and not only Queues */ ... the Scope table should +indicate whether the Scrip is relevant for a given transaction type ... then +the given Action should determinate whether it applies or not, and finally +the Action has to find out (via the Watchers table) whom it applies to, and +how to contact them ... and the Template tells how the mails that are sent +out should look like. + + diff --git a/rt/docs/design_docs/users b/rt/docs/design_docs/users new file mode 100644 index 000000000..71c4476c9 --- /dev/null +++ b/rt/docs/design_docs/users @@ -0,0 +1,14 @@ +RT2 makes everybody a user. some sites won't like this. there +should be away to make an "anonymous" user who the mailgate makes +the requestor for all mailed in tickets. it would then set the +ticket 'requestor' watcher's alternate email address to the real +requestor's email. + +additionally, eventually, users will need to be deleted. RT doesn't +want any user deleted. Instead, there will be a flag in the user's +entry in the users table called 'Disabled.' Disabled users will +not be able to be granted rights. + + The process of disabling a user should remove their acls and +should force the giving away of their tickets or reject the disabling. + diff --git a/rt/docs/rt.gif b/rt/docs/rt.gif Binary files differnew file mode 100755 index 000000000..693b06238 --- /dev/null +++ b/rt/docs/rt.gif |
