From ded0451e9582df33cae6099a2fb72b4ea25076cf Mon Sep 17 00:00:00 2001 From: ivan Date: Tue, 15 Jul 2003 13:30:43 +0000 Subject: reverting to vendor branch rt 3.0.4, hopefully --- rt/docs/design_docs/acls | 228 +++---------------- rt/docs/design_docs/basic-definitions.txt | 54 ----- rt/docs/design_docs/cli_spec | 361 ++---------------------------- rt/docs/design_docs/evil_plans | 9 +- rt/docs/design_docs/local_hacking | 32 --- rt/docs/rt.gif | Bin 8811 -> 0 bytes 6 files changed, 57 insertions(+), 627 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/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/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= 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 -