Difference between revisions of "ManualApprovals"

From Request Tracker Wiki
Jump to navigation Jump to search
m
 
(4 intermediate revisions by the same user not shown)
Line 7: Line 7:
The custom programming to create tickets involves the Create Tickets scrip action and a template that asks a supervisor to look at the ticket asking for approval.
The custom programming to create tickets involves the Create Tickets scrip action and a template that asks a supervisor to look at the ticket asking for approval.


Here is an example of the process by RT's head honcho, Jesse Vincent:
Please see the [https://docs.bestpractical.com/rt/latest/customizing/approvals.html Customizing/Approvals] and [https://docs.bestpractical.com/rt/latest/RT/Action/CreateTickets.html RT::Action::CreateTickets] pages in our official documentation for more about Approvals in RT.
 
== NAME ==
 
RT::Action::CreateTickets - Create one or more tickets according to an externally supplied template
 
== SYNOPSIS ==
 
<nowiki>===Create-Ticket: codereview
Subject: Code review for {$Tickets{'TOP'}->Subject}
Depended-On-By: TOP
Content: Someone has created a ticket. you should review and approve it,
so they can finish their work
ENDOFCONTENT</nowiki>
 
== DESCRIPTION ==
 
The "[[CreateTickets]]" [[ScripAction]] allows you to create automated workflows in RT, creating new tickets in response to actions and conditions from other tickets.
 
=== Format ===
 
[[CreateTickets]] uses the RT template configured in the scrip as a template for an ordered set of tickets to create. The basic format is as follows:
 
<pre>===Create-Ticket: identifier
Param: Value
Param2: Value
Param3: Value
Content: Blah
blah
blah
ENDOFCONTENT
===Create-Ticket: id2
Param: Value
Content: Blah
ENDOFCONTENT</pre>
 
As shown, you can put one or more <pre>===Create-Ticket:</pre> sections in a template. Each <pre>===Create-Ticket:</pre> section is evaluated as its own Text::Template object, which means that you can embed snippets of Perl inside the Text::Template using {} delimiters, but that such sections absolutely can not span a <pre>===Create-Ticket:</pre> boundary.
 
Note that each Value must come right after the Param on the same line. The Content: param can extend over multiple lines, but the text of the first line must start right after Content:. Don't try to start your <pre>Content:</pre> section with a newline.
 
After each ticket is created, it's stuffed into a hash called <pre>%Tickets</pre> making it available during the creation of other tickets during the same ScripAction. The hash key for each ticket is <pre>create-[identifier]</pre>, where <pre>[identifier]</pre> is the value you put after <pre>===Create-Ticket:</pre>.  The hash is prepopulated with the ticket which triggered the ScripAction as <pre>$Tickets{'TOP'}</pre>. You can also access that ticket using the shorthand TOP.
 
A simple example:
 
<pre>===Create-Ticket: codereview
Subject: Code review for {$Tickets{'TOP'}->Subject}
Depended-On-By: TOP
Content: Someone has created a ticket. you should review and approve it,
so they can finish their work
ENDOFCONTENT</pre>
 
A convoluted example:
 
<pre>===Create-Ticket: approval
{ # Find out who the administrators of the group called "HR"
  # of which the creator of this ticket is a member
    my $name = "HR";
 
    my $groups = RT::Groups->new(RT->SystemUser);
    $groups->LimitToUserDefinedGroups();
    $groups->Limit(FIELD => "Name", OPERATOR => "=", VALUE => $name, CASESENSITIVE => 0);
    $groups->WithMember($TransactionObj->CreatorObj->Id);
 
    my $groupid = $groups->First->Id;
 
    my $adminccs = RT::Users->new(RT->SystemUser);
    $adminccs->WhoHaveRight(
        Right => "AdminGroup",
        Object =>$groups->First,
        IncludeSystemRights => undef,
        IncludeSuperusers => 0,
        IncludeSubgroupMembers => 0,
    );
 
    our @admins;
    while (my $admin = $adminccs->Next) {
        push (@admins, $admin->EmailAddress);
    }
}
Queue: ___Approvals
Type: approval
AdminCc: {join ("\nAdminCc: ",@admins) }
Depended-On-By: TOP
Refers-To: TOP
Subject: Approval for ticket: {$Tickets{"TOP"}->Id} - {$Tickets{"TOP"}->Subject}
Due: {time + 86400}
Content-Type: text/plain
Content: Your approval is requested for the ticket {$Tickets{"TOP"}->Id}: {$Tickets{"TOP"}->Subject}
Blah
Blah
ENDOFCONTENT
===Create-Ticket: two
Subject: Manager approval
Type: approval
Depended-On-By: TOP
Refers-To: {$Tickets{"create-approval"}->Id}
Queue: ___Approvals
Content-Type: text/plain
Content: Your approval is requred for this ticket, too.
ENDOFCONTENT</pre>
 
=== Acceptable Fields ===
 
A complete list of acceptable fields:
 
  <pre>*  Queue          => Name or id# of a queue
      Subject        => A text string
    ! Status          => A valid status. Defaults to 'new'
      Due            => Dates can be specified in seconds since the epoch
                          to be handled literally or in a semi-free textual
                          format which RT will attempt to parse.
      Starts          =>
      Started        =>
      Resolved        =>
      Owner          => Username or id of an RT user who can and should own
                          this ticket; forces the owner if necessary
  +  Requestor      => Email address
  +  Cc              => Email address
  +  AdminCc        => Email address
  +  RequestorGroup  => Group name
  +  CcGroup        => Group name
  +  AdminCcGroup    => Group name
      TimeWorked      =>
      TimeEstimated  =>
      TimeLeft        =>
      InitialPriority =>
      FinalPriority  =>
      Type            =>
    +! DependsOn      =>
    +! DependedOnBy    =>
    +! RefersTo        =>
    +! ReferredToBy    =>
    +! Members        =>
    +! MemberOf        =>
      Content        => Content. Can extend to multiple lines. Everything
                          within a template after a Content: header is treated
                          as content until we hit a line containing only
                          ENDOFCONTENT
      ContentType    => the content-type of the Content field.  Defaults to
                          'text/plain'
      UpdateType      => 'correspond' or 'comment'; used in conjunction with
                          'content' if this is an update.  Defaults to
                          'correspond'
 
      CustomField-<id#> => custom field value
      CF-name          => custom field value
      CustomField-name  => custom field value</pre>
 
Fields marked with an <pre>*</pre> are required.
 
Fields marked with a <pre>+</pre> may have multiple values, simply by repeating the fieldname on a new line with an additional value.
 
Fields marked with a <pre>!</pre> have processing postponed until after all tickets in the same actions are created.  Except for <pre>Status</pre>, those fields can also take a ticket name within the same action (i.e. the identifiers after <pre>===Create-Ticket:</pre>), instead of raw ticket ID numbers.
 
When parsed, field names are converted to lowercase and have hyphens stripped. <pre>Refers-To></pre> <pre>RefersTo</pre>, <pre>refersto</pre>, <pre>refers-to</pre> and <pre>r-e-f-er-s-tO</pre> will all be treated as the same thing.
 
For another explanation, see [[ApprovalCreation]].


----
----
Line 169: Line 13:
Prev: [[ManualApache]] --- Up: [[UserManual]]
Prev: [[ManualApache]] --- Up: [[UserManual]]
[[Category:RT User Manual]]
[[Category:RT User Manual]]
[[Category:RT44]]

Latest revision as of 14:51, 2 April 2019

Prev: ManualScrips --- Up: UserManual --- Next: RTGlossary

Creating Approvals

Approvals are a useful way to get tickets OK'd by management without creating a new system. A supervisor's approval can be a ticket; another ticket can depend on that ticket being resolved.

The custom programming to create tickets involves the Create Tickets scrip action and a template that asks a supervisor to look at the ticket asking for approval.

Please see the Customizing/Approvals and RT::Action::CreateTickets pages in our official documentation for more about Approvals in RT.

Prev: ManualApache --- Up: UserManual

Retrieved from "https://rt-wiki.bestpractical.com/index.php?title=ManualApprovals&oldid=26904"