ManualApprovals: Difference between revisions

From Request Tracker Wiki
Jump to navigation Jump to search
mNo edit summary
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Prev: [[ManualScrips]] --- Up: [[UserManual]] --- Next: [[RTGlossary]]
Prev: [[ManualScrips]] --- Up: [[UserManual]] --- Next: [[RTGlossary]]


= Appendix 5 =
= Creating Approvals =
 
== 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.
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.
Line 9: 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'}-&gt;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 ===
 
Using the "[[CreateTickets]]" [[ScripAction]] and mandatory dependencies, RT now has the ability to model complex workflow. When a ticket is created in a queue that has a "[[CreateTickets]]" scripaction, that [[ScripAction]] parses its "Template"
 
=== FORMAT ===
 
[[CreateTickets]] uses the template as a template for an ordered set of tickets to create. The basic format is as follows:
 
<nowiki>===Create-Ticket: identifier
Param: Value
Param2: Value
Param3: Value
Content: Blah
blah
blah
ENDOFCONTENT
===Create-Ticket: id2
Param: Value
Content: Blah
ENDOFCONTENT
</nowiki>
 
Each ===Create-Ticket: 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 ===Create-Ticket boundary.
 
After each ticket is created, it's stuffed into a hash called %Tickets so as to be available during the creation of other tickets during the same [[ScripAction]]. The hash is prepopulated with the ticket which triggered the [[ScripAction]] as $Tickets{'TOP'}; you can also access that ticket using the shorthand $TOP.
 
A simple example:
 
<nowiki>===Create-Ticket: codereview
Subject: Code review for {$Tickets{'TOP'}-&gt;Subject}
Depended-On-By: TOP
Queue: ___Approvals
Type: approval
Content: Someone has created a ticket. you should review and approve it, so they can finish their work
ENDOFCONTENT
</nowiki>
 
A convoluted example:
 
      ===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-&gt;new($RT::SystemUser);
  $groups-&gt;LimitToUserDefinedGroups();
        $groups-&gt;Limit(FIELD =&gt; "Name", OPERATOR =&gt; "=", VALUE =&gt; "$name");
        $groups-&gt;WithMember($TransactionObj-&gt;CreatorObj-&gt;Id);
        my $groupid = $groups-&gt;First-&gt;Id;
        my $adminccs = RT::Users-&gt;new($RT::SystemUser);
        $adminccs-&gt;WhoHaveRight(
            Right =&gt; "AdminGroup",
            Object =&gt;$groups-&gt;First,
            IncludeSystemRights =&gt; undef,
            IncludeSuperusers =&gt; 0,
            IncludeSubgroupMembers =&gt; 0,
        );
          my @admins;
          while (my $admin = $adminccs-&gt;Next) {
              push (@admins, $admin-&gt;EmailAddress);
          }
      }
      Queue: Approvals
      Type: approval
      AdminCc: {join ("\nAdminCc: ",@admins) }
      Depended-On-By: {$Tickets{"TOP"}-&gt;Id}
      Refers-To: {$Tickets{"TOP"}-&gt;Id}
      Subject: Approval for ticket: {$Tickets{"TOP"}-&gt;Id} - {$Tickets{"TOP"}-&gt;Subject}
      Due: {time + 86400}
      Content-Type: text/plain
      Content: Your approval is requested for the ticket {$Tickets{"TOP"}-&gt;Id}: {$Tickets{"TOP"}-&gt;Subject}
      Blah
      Blah
      ENDOFCONTENT
      ===Create-Ticket: two
      Subject: Manager approval
      Depended-On-By: {$Tickets{"TOP"}-&gt;Id}
      Refers-On: {$Tickets{"approval"}-&gt;Id}
      Queue: Approvals
Content-Type: text/plain
      Content:
      Your approval is requred for this ticket, too.
      ENDOFCONTENT
 
=== ACCEPTABLE FIELDS ===
 
A complete list of acceptable fields for this beastie:
 
  *  Queue          =&gt; Name or id# of a queue
    Subject        =&gt; A text string
  ! Status          =&gt; A valid status. defaults to 'new'
    Due            =&gt; 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          =&gt;
    Started        =&gt;
    Resolved        =&gt;
    Owner          =&gt; Username or id of an RT user who can
                        and should own this ticket
+  Requestor      =&gt; Email address
+  Cc              =&gt; Email address
+  AdminCc        =&gt; Email address
    TimeWorked      =&gt;
    TimeEstimated  =&gt;
    TimeLeft        =&gt;
    InitialPriority =&gt;
    FinalPriority  =&gt;
    Type            =&gt;
  +! DependsOn      =&gt;
  +! DependedOnBy    =&gt;
  +! RefersTo        =&gt;
  +! ReferredToBy    =&gt;
  +! Parents        =&gt;
  +! Children        =&gt;
    Content        =&gt; 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    =&gt; the content-type of the Content field
CustomField-&lt;id#&gt; =&gt; custom field value
 
Fields marked with an * are required. Fields marked with a + man have multiple values, simply by repeating the fieldname on a new line with an additional value.
 
Fields marked with a ! are postponed to be processed after all tickets in the same actions are created. Except for 'Status', those fields can also take a ticket name within the same action (i.e. the identifiers after ==Create-Ticket), instead of raw Ticket ID numbers.
 
When parsed, field names are converted to lowercase and have -s stripped. Refers-To, [[RefersTo]], refersto, refers-to and r-e-f-er-s-tO will all be treated as the same thing.
 
For another explanation, see [[ApprovalCreation]].


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

Latest revision as of 13: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"