Difference between revisions of "ManualApprovals"

From Request Tracker Wiki
Jump to navigation Jump to search
m
 
(2 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 ==
 
<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>
 
== 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 <code>===Create-Ticket:</code> sections in a template. Each <code>===Create-Ticket:</code> 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 <code>===Create-Ticket:</code> 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 <code>Content:</code> section with a newline.
 
After each ticket is created, it's stuffed into a hash called <code>%Tickets</code> making it available during the creation of other tickets during the same ScripAction. The hash key for each ticket is <code>create-[identifier]</code>, where <code>[identifier]</code> is the value you put after <code>===Create-Ticket:</code>.  The hash is prepopulated with the ticket which triggered the ScripAction as <code>$Tickets{'TOP'}</code>. 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 <code>*</code> are required.
 
Fields marked with a <code>+</code> may have multiple values, simply by repeating the fieldname on a new line with an additional value.
 
Fields marked with a <code>!</code> have processing postponed until after all tickets in the same actions are created.  Except for <code>Status</code>, those fields can also take a ticket name within the same action (i.e. the identifiers after <code>===Create-Ticket:</code>), instead of raw ticket ID numbers.
 
When parsed, field names are converted to lowercase and have hyphens stripped. <code>Refers-To></code> <code>RefersTo</code>, <code>refersto</code>, <code>refers-to</code> and <code>r-e-f-er-s-tO</code> 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"