Process Tickets Forms

[crythias]

Some hints for Processes:
1) If you want to have lookup of customers, drag Customer ID as an available field in an activity dialog.
2) If you want tasks/tickets in parallel, in version 4+, use Transition Action TicketCreate (with a whole lot of fields).
3) If you want Processes to create Process Tickets, assign values to the following on the ticket create:
DynamicField_ProcessManagementProcessID (Look at the address bar for Process-verylonghexvalue)
DynamicField_ProcessManagementActivityID (Edit an activity or hover over an activity for Activity-verylonghexvalue)

Note you don't (necessarily) have to create a new *Process* to split a ticket with different workflows. Logic with separate Actions should work as expected. What this means is ...

Let's say you have a new hire that needs Accounting, Facilities, and IT in parallel.

Once the intake form has been submitted for the process, the ProcessID is the same, but each ticketcreate can use its own ActivityID.

Note you can pass variables from the master process ticket to the other activities: Title: <OTRS_TICKET_Title>, etc.

[crythias]

Here's an example of a TransitionAction (TicketCreate) that's making a ProcessTicket:

Configuration:
ArticleType: note-external
Body: Please set up new hire for <OTRS_TICKET_DynamicField_NewHireName>
ContentType: text/plain; charset=ISO-8859-15
CustomerID: <OTRS_TICKET_CustomerID>
CustomerUser: <OTRS_TICKET_CustomerUserID>
DynamicField_ProcessManagementActivityID: Activity-e10a55a13151430607d537711c0df4d3
DynamicField_ProcessManagementProcessID: Process-ef0238a5f4023d2169ec0733a64df530
HistoryComment: New ticket created by process
HistoryType: WebRequestCustomer
LinkAs: Child
Lock: unlock
OwnerID: 1
Priority: 3 normal
Queue: Facilities
SenderType: agent
State: new
Subject: New Hire Setup <OTRS_TICKET_DynamicField_NewHireName>
Title: OnboardingFacilities - <OTRS_TICKET_DynamicField_NewHireName> <OTRS_TICKET_DynamicField_DateRequestedStart>

Note: HistoryType should be one of EmailAgent|EmailCustomer|PhoneCallCustomer|WebRequestCustomer|SystemRequest if you want Agent notifications to happen with built-in notifications. Otherwise, you'll need to create specific agent notifications.

Note that you can force a notification anyway...
ForceNotificationToUserID: 123,134
(123,134 is the database id of the agent(s) to send to)

[crythias]

note: this is merely because I needed something ... not that I'd recommend it.
Within a Process form, let's say you want to modify a field or group of fields, but after render (Move them around, color, etc.)
By default, the fields have a "class" only: "Row Row_DynamicField_myName"
in Kernel\Output\Standard\ProcessManagement\DynamicField.tt, you modify the div line to include an id:

Code: Select all

<div class="Row Row_DynamicField_[% Data.Name %]" id="mydiv_DynamicField_[% Data.Name %]">

now the #mydiv_DynamicField_myField can be directly customized via CSS. The optimal way to do this is to make the CSS in its own file and include that in SysConfig Framework Core::Web

But let's say you want to do even more customization (javascript DOM changes). This one is a bit more difficult.

within var/httpd/htdocs/js/Core.Agent.TicketProcess.js is where the "onChange" show ActivityDialog code exists. While it's not generally recommended to break code to do things, after line 127 ( $('#AJAXDialog').val('1');), the ActivityDialog has been rendered, so js code can be placed here to be "after render". While this is "core" code, the best way (a minimally invasive way, anyway) to handle this is to place your function(s) in another custom.js file, include that in SysConfig like above, and place the function call after the line 127 above.

(This is Agent Side. The customer side has the js attached to the .tt)

Note that these changes have to be "remembered" as they won't survive updates and the changes are not in any way supported by OTRS proper, let alone by anyone here. I'm recording this as a "how I did it" in case anyone would like a bit of "jumping off" point.

As an example of javascript code:

Code: Select all

var mynewdiv = document.createElement('div');
mynewdiv.id = 'mydivcontent';
var el = [document.getElementById('mydiv_DynamicField_Field1'),document.getElementById('mydiv_DynamicField_Field2')];
document.getElementById('mydiv_DynamicField_FieldToPutDiv').appendChild(mynewdiv);
for (var i=0; i<2; i++) {
mynewdiv.insertBefore(el[i], mynewdiv.childNodes[0]);
}

Code above hand written. no guarantees of zero bugs. Hopefully you understand what's going on.

[crythias]

Let's say you have multiple fields (checkboxes) on the first Activity/Activity Dialog that you need transition actions that apply when certain checkboxes are filled out.

At least one way to handle this is to create a daisy chain of Activities and Transitions for each checkbox dynamic field where both checked and unchecked transitions go to the next Activity (the checked transition does TransitionActions and the unchecked does nothing, for instance). But the problem is that each activity only "works" on an event, even if there are no Activity Dialogs in the Activity. The following modifies a core file in OTRS 4.x where it keeps processing transitions until the transition process returns the same ActivityEntityID and then stops. The proper way to stop going to the next step is to make sure the next activity is unreachable without human input.


A sample update to Kernel/System/Ticket/Event/TicketProcessTransitions.pm so that it runs through all the Activities until it needs to stop:

Code: Select all

    my $loop = 1;
    # Looping Transitions
    while($loop == 1) {

    my $TransitionApplied = $ProcessObject->ProcessTransition(
        ProcessEntityID  => $ProcessEntityID,
        ActivityEntityID => $ActivityEntityID,
        TicketID         => $Param{Data}->{TicketID},
        UserID           => $Param{UserID},
    );

    if ( $Self->{Debug} ) {

        $Kernel::OM->Get('Kernel::System::Log')->Log(
            Priority => 'error',
            Message =>
                "Transition for to TicketID: $Param{Data}->{TicketID}"
                . "  ProcessEntityID: $ProcessEntityID OldActivityEntityID: $ActivityEntityID "
                . ( $TransitionApplied ? "was applied." : "was not applied." ),
        );
    }

    # Check if there's a new activity
    # We need to ticket get again

    %Ticket = $TicketObject->TicketGet(
        TicketID      => $Param{Data}->{TicketID},
        DynamicFields => 1,
        Silent        => 1,
    );

    #ActivityIDField is consistent and the name of the field that holds the ActivityID
    my $NewActivityEntityID = $Ticket{"DynamicField_$ActivityIDField"};
    #If this is the same Activity, let's exit the loop
    if ($ActivityEntityID eq $NewActivityEntityID) { $loop=0; };

    if ( $Self->{Debug} ) {
        $Kernel::OM->Get('Kernel::System::Log')->Log(
            Priority => 'error',
            Message =>
                "Loop: $loop. Checking for new ActivityEntityID. old: $ActivityEntityID. new: $NewActivityEntityID",

        );
    }

    #NewActivityID.
    $ActivityEntityID = $NewActivityEntityID;

    }

[nedmaj]

Hi Crythias,

Thanks for the hints!

I'm wondering if it's possible to make OTRS automatically open the next form (activity dialog) without have to click on its link -- assuming the next activity has only one activity dialog.