From 160be29a0dc62e79a4fb95d2ab8c0c7e5996760e Mon Sep 17 00:00:00 2001 From: cvs2git Date: Mon, 12 Aug 2002 06:17:10 +0000 Subject: This commit was manufactured by cvs2svn to create branch 'BESTPRACTICAL'. --- rt/docs/design_docs/basic-definitions.txt | 54 ------------------------------ rt/docs/design_docs/local_hacking | 32 ------------------ rt/docs/rt.gif | Bin 8811 -> 0 bytes 3 files changed, 86 deletions(-) delete mode 100644 rt/docs/design_docs/basic-definitions.txt delete mode 100644 rt/docs/design_docs/local_hacking delete mode 100755 rt/docs/rt.gif (limited to 'rt/docs') 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/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. diff --git a/rt/docs/rt.gif b/rt/docs/rt.gif deleted file mode 100755 index 693b06238..000000000 Binary files a/rt/docs/rt.gif and /dev/null differ -- cgit v1.2.1 From 945721f48f74d5cfffef7c7cf3a3d6bc2521f5dd Mon Sep 17 00:00:00 2001 From: ivan Date: Tue, 15 Jul 2003 13:16:32 +0000 Subject: import of rt 3.0.4 --- rt/docs/design_docs/acls | 228 ++----------- rt/docs/design_docs/approval_notices | 8 + rt/docs/design_docs/approval_template | 25 ++ rt/docs/design_docs/cf_search | 72 ++++ rt/docs/design_docs/cli_spec | 361 ++------------------- rt/docs/design_docs/delegation | 115 +++++++ rt/docs/design_docs/evil_plans | 9 +- rt/docs/design_docs/groups_notes | 88 +++++ .../recursive_group_membership_algorithm | 109 +++++++ rt/docs/design_docs/rql_parser_machine.graphviz | 32 ++ rt/docs/design_docs/string-extraction-guide.txt | 100 ++++++ rt/docs/design_docs/ticket_templates | 16 + 12 files changed, 622 insertions(+), 541 deletions(-) create mode 100644 rt/docs/design_docs/approval_notices create mode 100644 rt/docs/design_docs/approval_template create mode 100644 rt/docs/design_docs/cf_search create mode 100644 rt/docs/design_docs/delegation create mode 100644 rt/docs/design_docs/groups_notes create mode 100644 rt/docs/design_docs/recursive_group_membership_algorithm create mode 100644 rt/docs/design_docs/rql_parser_machine.graphviz create mode 100644 rt/docs/design_docs/string-extraction-guide.txt create mode 100644 rt/docs/design_docs/ticket_templates (limited to 'rt/docs') 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 - users who are watchers of type for - users who are watchers of type for - - -what scope do these rights apply to - queue - 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 - 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/approval_notices b/rt/docs/design_docs/approval_notices new file mode 100644 index 000000000..5e7611924 --- /dev/null +++ b/rt/docs/design_docs/approval_notices @@ -0,0 +1,8 @@ +Notification on "your request approved by" +Notification on "your request approved by all approvers" +Notification on "your request denied by" +Reject ticket on rejection of any approval + +"Ticket N is pending your approval" + + diff --git a/rt/docs/design_docs/approval_template b/rt/docs/design_docs/approval_template new file mode 100644 index 000000000..16a988c5d --- /dev/null +++ b/rt/docs/design_docs/approval_template @@ -0,0 +1,25 @@ +===Create-Ticket: approval + { my $name = "HR"; + my $groups = RT::Groups->new($RT::SystemUser); + $groups->LimitToUserDefinedGroups(); + $groups->Limit(FIELD => 'Name', OPERATOR => '=', VALUE => "$name"); + $groups->WithMember($TransactionObj->CreatorObj->Id); + + my $groupid = $groups->First->Id; + + my $adminccs = RT::Users->new($RT::SystemUser); + $adminccs->WhoHaveRight(Right => 'AdminGroup', IncludeSystemRights => undef, IncludeSuperusers => 0, IncludeSubgroupMembers => 0, Object => $groups->First); + + my @admins; + while (my $admin = $adminccs->Next) { + push (@admins, $admin->Name); + } + } + Queue: Approvals + Type: Approval + AdminCcs: {join (", ",@admins) } + Depended-On-By: {$tickets{'TOP'}->Id} + Refers-To: {$tickets{'TOP'}->Id} + Due: {time + 86400} + Content-Type: text/plain + Content: Your approval is requested for the ticket {%$tickets{'TOP'}->Id}: {$tickets{'TOP'}->Subject} diff --git a/rt/docs/design_docs/cf_search b/rt/docs/design_docs/cf_search new file mode 100644 index 000000000..456a9febb --- /dev/null +++ b/rt/docs/design_docs/cf_search @@ -0,0 +1,72 @@ +find all tickets where: + + + CF Foo + Has values (talk or read) AND + Has values (bar and baz) AND + doesn't have values (bing or bong) + + +LimitCustomFieldValues { + my %args = ( CustomField => undef, + ClauseId => 'CustomFields', + OPERATOR => undef, + ENTRYAGGREGATOR => undef, + VALUES => undef, + @_) ; + + unless ( $self->{'TicketAliases'}{$args{'ClauseId'}}{'CustomField'} ) { + $self->{'TicketAliases'}{$args{'ClauseId'}}{'CustomField'} = $self->NewAlias('CustomFields'); + $self->Join(TABLE1 =>$self->{'TicketAliases'}{$args{'ClauseId'}}{'CustomField' }, + FIELD1 => 'QueueId', + TABLE2 => 'main', FIELD2 => 'QueueId'); + + if ($args{'OPERATOR'} =~ /!=|IS/i) { + } + else { + } + +} + # {{{ if it's a keyword + elsif ( $TYPES{ $restriction->{'FIELD'} } eq 'CUSTOMFIELD' ) { + + my $null_columns_ok; + my $TicketCFs = $self->Join( TYPE => 'left', + ALIAS1 => 'main', + FIELD1 => 'id', + TABLE2 => 'TicketCustomFieldValues', + FIELD2 => 'Ticket' ); + + foreach my $value ( @{ $restriction->{'VALUES'} } ) { + $self->SUPER::Limit( ALIAS => $TicketCFs, + FIELD => 'Content', + OPERATOR => $restriction->{'OPERATOR'}, + VALUE => $value, + QUOTEVALUE => $restriction->{'QUOTEVALUE'}, + ENTRYAGGREGATOR => 'AND', ); + } + if ( ( $restriction->{'OPERATOR'} =~ /^IS$/i ) or ( $restriction->{'OPERATOR'} eq '!=' ) ) { + $null_columns_ok = 1; + } + + #If we're trying to find tickets where the keyword isn't somethng, also check ones where it _IS_ null + if ( $restriction->{'OPERATOR'} eq '!=' ) { + $self->SUPER::Limit( ALIAS => $TicketCFs, + FIELD => 'Content', + OPERATOR => 'IS', + VALUE => 'NULL', + QUOTEVALUE => 0, + ENTRYAGGREGATOR => 'OR', ); + } + + $self->SUPER::Limit( LEFTJOIN => $TicketCFs, + FIELD => 'CustomField', + VALUE => $restriction->{'CUSTOMFIELD'}, + ENTRYAGGREGATOR => 'OR' ); + + } + + # }}} + + } + 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= Find only tickets in the range - synonyms: - --limit-id, --tickets, --limit-tickets - --limit-queue= - --limit-status= - --limit-owner= - --limit-priority= - --limit-requestor= - --limit-subject= (Subject contains) - --limit-body= (body contains) - --limit-created=(before/after) - --limit-due=(before/after) - --limit-starts=(before/after) - --limit-started=(before/after) +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= Start on the th row returned by the - database - --limit-rows= Find only 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= - --owner= - --queue= - --time-left= +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= - --del-requestor= - --add-cc= - --del-cc= - --add-admincc= - --del-admincc= +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= - --final-priority= -Date related editing: - - --due=date - --starts=date - --started=date - --contacted=date - - - -Ticket updates: - - --comment - --reply | --respond - - -Links - - --add-link - --type= - needs one of: - --target= - --base= - - --del-link - - - -Condiments: - any update can take: - - --time-taken - - 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 ----- - -Date: Fri, 14 Apr 2000 11:43:18 -0400 (EDT) -From: deborah kaplan -To: Jesse -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 - is one of: - - - help - print an overview of the commands which can be run - - - print - with no options, dump to the screen a list of all open - requests in -- the equivalent of "Display Queue" in - the existing Web interface. - - is the name of an RT queue -