Difference between revisions of "OnCreateSetDeptHeadCc"

From Request Tracker Wiki
Jump to navigation Jump to search
m (4 revisions imported)
m
 
Line 17: Line 17:
* Custom Condition:
* Custom Condition:


<nowiki># make sure we are called from a on create condition and
<pre>
# make sure we are called from a on create condition and
  # make sure department is filled out
  # make sure department is filled out
  if (
  if (
Line 38: Line 39:
  }
  }
   
   
  </nowiki>
  </pre>


* Custom action preparation code:
* Custom action preparation code:


  <nowiki># example: for 'Systems' the group is 'Head Systems'
  <pre>
# example: for 'Systems' the group is 'Head Systems'
  my $derivedGroupName = 'Head ' . $self-&gt;TicketObj-&gt;FirstCustomFieldValue('Department');
  my $derivedGroupName = 'Head ' . $self-&gt;TicketObj-&gt;FirstCustomFieldValue('Department');
   
   
Line 81: Line 83:
   return 1;
   return 1;
  }
  }
  </nowiki>
  </pre>


* Custom action cleanup code:
* Custom action cleanup code:

Latest revision as of 21:17, 13 August 2016

Overview

Dept heads need to see and reply to tickets opened by their staff. This is accomplished by giving the global 'Cc' group ShowTicket perms and automatically making the dept head a Cc on the ticket.

On create in the case that CustomField.Department = 'Foo' then add group 'Head Foo' as a Cc. Be sure to first check that the Requestor is not in the 'Head Foo' group. That may be problematic for odd departments or units with more than one member in a 'Head x' group. (See also OnCreateAddGroupCc.)

Scrip

All tickets have a Department custom field mapping the ticket to a dept. I globally grant the Cc role ShowTicket and ReplyToTicket permission and then add the department head as Cc on their staff's tickets. This way they can add comments and be aware of issues in their department. I do not yet wish to give them powers such as ModifyTicket, so they can't monkey with priorities etc. Therefore, I felt Cc more appropriate than AdminCc even after granting extra rights to Cc.

  • Custom Condition:
 # make sure we are called from a on create condition and
 # make sure department is filled out
 if (
        (
          ($self->TransactionObj->Type eq "Create")
          || ($self->TransactionObj->Type eq "CustomField")
        ) && (
          $self->TicketObj->FirstCustomFieldValue('Department')
          && ($self->TicketObj->FirstCustomFieldValue('Department') ne 'None')
        )
     ) {
     #$RT::Logger->info("Met User Defined OnCreateSetDeptHeadCc Condition #".
     #    $self->TicketObj->id ." ".
     #    $self->TicketObj->FirstCustomFieldValue('Department') );
     return 1;
 } else {
     #$RT::Logger->info("Did Not Meet User Defined OnCreateSetDeptHeadCc Condition #".
     #   $self->TicketObj->id ." ". $self->TicketObj->FirstCustomFieldValue('Department') );
     return undef;
 }
 
 
  • Custom action preparation code:
 # example: for 'Systems' the group is 'Head Systems'
 my $derivedGroupName = 'Head ' . $self->TicketObj->FirstCustomFieldValue('Department');
 
 # instantiated a group object
 my $groupObj = RT::Group->new($RT::SystemUser);
 $groupObj->LoadUserDefinedGroup($derivedGroupName);
 return undef unless $groupObj;
 
 # one doesn't want to be a requestor and a Cc on the same ticket.
 # don't add group as CC if requestor is in that group
 # this could certainly be a problem if there are multiple members in a group
 my $requestorsGroupObj = $self->TicketObj->Requestors;
 # UMO grabs group members in subgroups too it is recursive
 my $requestorsMembersObj = $requestorsGroupObj->UserMembersObj;
 
 my $userObj;
 while ($userObj = $requestorsMembersObj->Next) {
     if ($groupObj->HasMember($userObj->PrincipalObj)) {
         $RT::Logger->info("Requestor '" . $userObj->Name .
             "' is in group '$derivedGroupName' not adding Cc on ticket #" .
             $self->TicketObj->id );
 
         return undef;
     }
 }
 
 # add group as Cc on ticket. see Ticket_Overlay.pm
 $RT::Logger->info("Add group '$derivedGroupName' as Cc on ticket #" .
     $self->TicketObj->id );
 my ($success, $msg)= $self->TicketObj->AddWatcher(
                              Type => "Cc",
                              PrincipalId => $groupObj->PrincipalId);
 
 if (! $success) {
  $RT::Logger->info($msg);
  return undef;
 } else {
  return 1;
 }
 
  • Custom action cleanup code:
# blank
 
 

Include CC Tickets in SelfService

After the Department head has been made CC on a ticket they need an easy way to view all such tickets. So, let's modify SelfService to show them.

Put the pieces in place:

[root@lakshmi Elements]# mkdir -p /usr/local/rt/html/SelfService/Elements
[root@lakshmi Elements]# cp MyRequests /usr/local/rt/html/SelfService/Elements

Make one small change.

[root@lakshmi Elements]# diff -u MyRequests /usr/local/rt/html/SelfService/Elements/MyRequests
--- MyRequests  2005-02-01 06:20:40.000000000 -0800
+++ /usr/local/rt/html/SelfService/Elements/MyRequests  2006-02-27 11:00:31.000000000 -0800
@@ -70,7 +70,7 @@
 $title ||= loc("My [_1] tickets", $friendly_status);
 my $MyTickets;
 $MyTickets = new RT::Tickets ($session{'CurrentUser'});
-$MyTickets->LimitWatcher(TYPE => 'Requestor', VALUE => $session{'CurrentUser'}->EmailAddress);
+$MyTickets->LimitWatcher(VALUE => $session{'CurrentUser'}->EmailAddress);
 $MyTickets->OrderBy(FIELD => 'id', ORDER => 'ASC');

 foreach my $status (@status) {

Bugs in Solution

  • If there is more than one user in a 'Head X' group and one user opens a ticket, the other user will not become a Cc.

This would in an issue in departments with more than one "head". We can worry about that later. (Also see OnCreateAddGroupCc.)

  • If the Department changes during the life of the ticket, the new Cc will be added, but the old Cc will not be removed.
  • How can send the AutoReply to the department head as well as the requestor?