diff options
Diffstat (limited to 'rt/docs/design_docs')
| -rw-r--r-- | rt/docs/design_docs/acls | 228 | ||||
| -rw-r--r-- | rt/docs/design_docs/basic-definitions.txt | 54 | ||||
| -rw-r--r-- | rt/docs/design_docs/cli_spec | 361 | ||||
| -rw-r--r-- | rt/docs/design_docs/evil_plans | 9 | ||||
| -rw-r--r-- | rt/docs/design_docs/local_hacking | 32 |
5 files changed, 57 insertions, 627 deletions
diff --git a/rt/docs/design_docs/acls b/rt/docs/design_docs/acls index 3b9d8567c..bb093adcb 100644 --- a/rt/docs/design_docs/acls +++ b/rt/docs/design_docs/acls @@ -1,206 +1,50 @@ -$Header: /home/cvs/cvsroot/freeside/rt/docs/design_docs/acls,v 1.1 2002-08-12 06:17:07 ivan Exp $ +Does principal baz have right foo for object bar -# {{{ Requirements +What rights does user baz have for object bar -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 +# {{{ Which principals have right foo for object bar - jesse -Who can rights be granted to: +if ($args{'ObjectType'} eq 'Ticket') { + $or_check_ticket_roles = " OR ( Groups.Domain = 'TicketRole' AND Groups.Instance = '".$args{'ObjectId'}."') "; + # If we're looking at ticket rights, we also want to look at the associated queue rights. + # this is a little bit hacky, but basically, now that we've done the ticket roles magic, we load the queue object + # and ask all the rest of our questions about the queue. + my $tick = RT::Ticket->new($RT::SystemUser); + $tick->Load($args{'ObjectId'}); + $args{'ObjectType'} = 'Queue'; + $args{'ObjectId'} = $tick->QueueObj->Id(); - 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)) +if ($args{'ObjectType'} eq 'Queue') { + $or_check_roles = " OR ( ( (Groups.Domain = 'QueueRole' AND Groups.Instance = '".$args{'ObjectId'}."') $or_check_ticket_roles ) + AND Groups.Type = ACL.PrincipalType AND Groups.Id = Principals.ObjectId AND Principals.PrincipalType = 'Group') "; +} -# This select statement would figure outif a user has $Right for the "System" +if (defined $args{'ObjectType'} ) { + $or_look_at_object_rights = " OR (ACL.ObjectType = '".$args{'ObjectType'}."' AND ACL.ObjectId = '".$args{'ObjectId'}."') "; -SELECT ACE.id from ACE, Watchers, Tickets WHERE ( - ($SystemObject) AND ( ACE.Right = $Right ) AND ($Principals)) +} -# }}} +my $query = "SELECT Users.* from ACL, Groups, Users, Principals, Principals UserPrinc, CachedGroupMembers WHERE + Users.id = UserPrinc.ObjectId AND UserPrinc.PrincipalType = 'User' AND + Principals.Id = CachedGroupMembers.GroupId AND + CachedGroupMembers.MemberId = UserPrinc.ObjectId AND + UserPrinc.PrincipalType = 'User' AND + (ACL.RightName = 'SuperUser' OR ACL.RightName = '$right') AND + (ACL.ObjectType = 'System' $or_look_at_object_rights) AND + ( + (ACL.PrincipalId = Principals.Id AND + Principals.ObjectId = Groups.Id AND + ACL.PrincipalType = 'Group' AND + (Groups.Domain = 'SystemInternal' OR Groups.Domain = 'UserDefined' OR Groups.Domain = 'ACLEquivalence') + ) + $or_check_roles + )"; # }}} -# {{{ 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. +What objects does principal baz have right foo for +; diff --git a/rt/docs/design_docs/basic-definitions.txt b/rt/docs/design_docs/basic-definitions.txt deleted file mode 100644 index 23d2c5748..000000000 --- a/rt/docs/design_docs/basic-definitions.txt +++ /dev/null @@ -1,54 +0,0 @@ -(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 index 48a7f34e1..ae5f29f76 100644 --- a/rt/docs/design_docs/cli_spec +++ b/rt/docs/design_docs/cli_spec @@ -1,354 +1,31 @@ -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> +Things the cli must do + create ticket + comment + reply + update ticket metadata + search for tickets + update a bunch of tickets. + list tickets + login/logout - --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 +should support multiple rt servers - --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 - +create/edit/update should use EDITOR or take from a file or stdin -Basic ticket editing: +should be able to update ticket sttributes from a commandline without invoking an editor or needing to use stdin. - --status=(open|stall|resolve|kill) - --subject=<string> - --owner=<owner> - --queue=<queue> - --time-left=<minutes> +login/logout should store RT session cookies rather than constantly transmitting the username/password combo. -Watcher-related editing: +rtserver and rt username should come from env variables. but should be able to be overridden by commandline options. - --add-requestor=<email> - --del-requestor=<email> - --add-cc=<email> - --del-cc=<email> - --add-admincc=<email> - --del-admincc=<email> +rt password should be able to be specified on the commandline (say from a script) or, failing that be prompted for within the application (as rt's sbin/initdb script does) ...or maybe able to be read from a stash file on disk. -Priority related editing: +must be able to dowaload attachments from cli. + + it might also be cool to be able to generate session-length urls for attavhments so you can use a browser. but that's not necessary. - --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. +I'm envisioning this as similar to the subversion cli, actually. diff --git a/rt/docs/design_docs/evil_plans b/rt/docs/design_docs/evil_plans index 34b9f81a2..5b5cc58c1 100644 --- a/rt/docs/design_docs/evil_plans +++ b/rt/docs/design_docs/evil_plans @@ -3,8 +3,7 @@ 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 @@ -67,8 +66,6 @@ nice Scrips could apply to a list of queues, rather than just one queue or 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 @@ -79,8 +76,6 @@ Nice Make custom fields apply to an enumerated list of queues, Web infrastructure -Must Full fastcgi support. - Installation @@ -116,7 +111,7 @@ 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. + framework. Sadly, the world doesn't agree with me ACLs: diff --git a/rt/docs/design_docs/local_hacking b/rt/docs/design_docs/local_hacking deleted file mode 100644 index c06d1126d..000000000 --- a/rt/docs/design_docs/local_hacking +++ /dev/null @@ -1,32 +0,0 @@ -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. |