PM (ProcessMaker) Plugin Concept

Introduction

You'll find a good documentation about ProcessMaker Server: http://wiki.processmaker.com/2.5.x/Community%20Edition
And to be read before using PM plugin: http://wiki.processmaker.com/index.php/ProcessMaker_Basic_Concepts

Mapping between PM and GLPI:

Workflow design

A new workflow definition (=process) can be designed in PM server ("http://my.server.com/pm"). See http://wiki.processmaker.com/index.php/2.0/Processes, and http://wiki.processmaker.com/index.php/2.0/Tasks

Some information are needed for GLPI plugin configuration:
  • General ProcessMaker server configuration: like URL, workspace, user interface,... (see Plugin configuration).
  • Process => a PM process is defined in GLPI via a manual synchronization in plugin configuration (see Plugin configuration)
  • Task => Tasks from a process are defined in GLPI (via manual synchronization).

Workflow execution

  • Case => is an running instance of a process. A case is embedded into a Ticket and viewed in a dedicated Ticket tab (called 'Process - Case'). One and only one case can be linked to a ticket.
  • A new case (for an activated process) can be started at any time for a ticket.
  • At creation, status of the newly created case is 'DRAFT': when in this status, a case can be deleted.
  • Running status of a case is 'TO_DO': in this status, a case can only be 'CANCELLED' (or 'COMPLETED' when finished).
  • Completed (= finished) case status is 'COMPLETED'
  • Task => Tasks from a running cases are mapped to Ticket Tasks. They are dynamically added to the Ticket during the running of the case.
  • When a new PM task is activated (or routed), then a new task is created in the ticket. Assigned technician to the Ticket Task is set accordingly to the assignee in PM process definition.
  • When a PM task is finished, then the mapped ticket task is set as done. start and end date are set accordingly.
  • When a PM task is re-assigned, then the Ticket Task is re-assigned to the new technician.
  • If GLPI notifications are enabled for Ticket Tasks, then notifications for Task Events are going to be sent.
  • Case Variables => some case variables are automatically injected into the case by the plugin. At ticket creation and updates.
  • GLPI_ITEM_CAN_BE_SOLVED => is a boolean variable that can be used to inform GLPI that the ticket hosting the case can be solved, otherwise, ticket solution can't be set if a case is still in 'TO_DO' status.
  • GLPI_TICKET_ID => is the Ticket ID
  • GLPI_ITEM_TYPE => is the type of the object that hosts the case (i.e. Ticket, or Problem, or else)
  • GLPI_TICKET_REQUESTER_GLPI_ID => is the GLPI ID of the requester of the Ticket
  • GLPI_TICKET_REQUESTER_PM_ID => is the ProcessMaker UID of the requester of the Ticket
  • GLPI_TICKET_TITLE => is the Ticket title (=name) field
  • GLPI_TICKET_DESCRIPTION => is the Ticket description (=content) field
  • GLPI_TICKET_DUE_DATE => is the Ticket Due Date
  • GLPI_TICKET_URGENCY => is the Ticket Urgency field
  • GLPI_ITEM_IMPACT = is the Ticket Impact field
  • GLPI_ITEM_PRIORITY => is the Ticket Priority field
  • GLPI_TICKET_GLOBAL_VALIDATION => is the Ticket global validation field (contains: 'none', 'waiting', 'accepted', rejected')
  • GLPI_TICKET_TECHNICIAN_GLPI_ID => is the GLPI ID of the assigned technician of the Ticket
  • GLPI_TICKET_TECHNICIAN_PM_ID => is the ProcessMaker UID of the assigned technician of the Ticket

Note 1: variables with TICKET in their names will be replaced in a near future (next release?) by ITEM to be more generic. Example: GLPI_TICKET_xxxx, will be replaced by GLPI_ITEM_xxxx
Note 2: plugin maintains both user's IDs, as a PM process knows only the PM user's UID, and GLPI knows only the GLPI user's ID.

And some variables may be used in a case to give back some info to GLPI.

  • GLPI_ITEM_TASK_CONTENT => is a string to use to fill next ticket task description. To be set in a Process Trigger, before 'Routing'. Plugin uses this value to set next task description, and after task creation, it will reset this variable to ''.
  • GLPI_ITEM_APPEND_TO_TASK => is a string to append to current solved ticket task description. To be set in a Process Trigger, before 'Routing'. Plugin appends this value to current task description, and after routing, it will reset this variable to ''.
  • GLPI_ITEM_CAN_BE_SOLVED => is a boolean variable that can be used to inform GLPI that the ticket (or item) hosting the case can be solved, otherwise, ticket (or item) solution can't be set if a case is still in 'TO_DO' status.
And since plugin version 2.3.2:
  • GLPI_ITEM_INITIAL_DUE_DATE (since version 2.3.2) => only available when using plugin in simplified interface (helpdesk). Is a date variable that can be used to set due date for ticket at ticket creation.
  • GLPI_NEXT_GROUP_TO_BE_ASSIGNED (since version 2.3.2) => Is GUID of ProcessMaker group used for next Task. Must be set in a Process Maker trigger before assignment of next task. Must be used when:

-> Next Process Maker task assignment rule is 'Self Service' AND when several Process Maker groups have the rights to execute next task.
or
-> Next Process Maker task assignment rule is 'Self Service Value Based Assignment'. More info on http://wiki.processmaker.com/index.php/2.0/Tasks#Self_Service_Value_Based_Assignment

Note: this variable can also be used at any time when a group is assigned to a task and this group is a subset of the people with the rights to execute next task.

Note: a case can run without these variables!

  • Dynaform => Dynaforms are viewed in the special dedicated Ticket tab (called 'Process - Case').
  • Process Map => Process map can be viewed in the dedicated Ticket tab (called 'Process - Case').
  • Case History => Case History can be viewed in the dedicated Ticket tab (called 'Process - Case').
  • Permissions TODO
Process Permissions
Process Supervisor
Roles
  • Steps => are embedded in the dedicated Ticket tab (called 'Process - Case')