Project Open ships with a powerful workflow editor that lets you control how a ticket is processed. The workflow editor operates in one of two modes: Simple Process and Advanced Process. This tutorial will cover the Advanced Process.
I’ll break down the Advanced Process tutorial into these parts:
- Tasks and Places
- Roles and Responsibilities
- Arcs and Guards
- Automatic Processes
- Adding to Helpdesk Ticket Types
- Adjusting Dynfields
This section will cover Adjusting Dynfields.
To successfully run this tutorial, you’ll need:
- A working installation of Project Open 4.0.4.x
- A Project Open administrator ID
My Project Open installation runs on CentOS 6.5 Linux. I used Mozilla Firefox under OS X 10.10.2 to capture the screen shots.
If you remember from the last tutorial, we had almost everything in the new workflow working — up until we actually tried to use it. There were only a few fields on the ticket! It looked like Figure 1.
Figure 1: There aren’t a lot of fields on the default ticket.
As you can see, only fields like Name, SLA, Customer Contact, Type, and Status show up on the ticket. That’s not very useful!
Fortunately, Project Open is flexible enough to offer an easy way to fix this. Project Open lets you define what fields will display on a Helpdesk ticket depending on the type of workflow you select.
That reminds me of ancient days, when I wrote a help desk system in dBXL (and its compiler, Quicksilver), a dBASE III+ “super clone”. dBXL had windowing functions and great performance — under DOS (that’s Disk Operating System for you young ‘uns). I added features to the help desk that would change field labels depending on the group to which your ID belonged. But that was with a tool so old that Wikipedia doesn’t even have an entry for it.
I even helped beta test dBXL Arago, the version of dBXL that could have competed favorable with FoxPro — until Borland bought dBXL, and that was the end of that.
But, I digress.
If you’d like to follow along with this tutorial, perform these steps:
- Log into Project Open with an ID in the PO Admin group
- Click on the Admin tab
- Click on the Dynfield URL
- Click on the URL for Object Types
- Click on the URL for Ticket
- Scroll down and find/click on the URL for Attribute-Type-map
You should now see a screen like the one shown in Figure 2.
Figure 2: The Attribute-type-map for the object type Ticket lets you define what fields display on tickets that are part of a specific workflow.
Along the top, you’ll notice the names of workflows that showed up in the drop down box for Ticket types in the previous tutorial (Tutorial 5, Figure 5). Along the left side, you can see a listing of the available fields. At the intersection of each, you’ll see three radio buttons whose position has a specific meaning:
- The left radio button indicates a given field is not present or visible for the specified workflow
- The middle radio button means that the field will display, the the user cannot change its contents
- The right radio button means the field will display and be editable
If you look at the far right of our diagram, you’ll see the tutorial’s workflow listed (it’s called Tutorial Sample 001). If you follow its column down, you’ll see that all of the left radio buttons are selected.
For the purposes of our tutorial, I’ll select the right radio button for these two fields:
- Hardware Component
Then, I’ll scroll down and click the button called Submit.
Now, the ticket I try to create with the Tutorial Sample 001 workflow looks like the one in Figure 3.
Figure 3: After adjusting the Dynfield Attribute-Type-Map, you can see the fields that make sense for this workflow.
Of course, you’d select whatever fields your workflow needs. If you need more fields than Project Open ships with, you can use the Dynfield URL from the Admin tab to make more fields, then use the Dynfield Attribute Type Map to add them to your workflow’s tickets.
In this advanced workflow tutorial, we’ve covered everything from giving the workflow a name to creating its Tasks and Places to giving it conditional logic to adding the workflow to the available ticket types to, finally, fine-tuning the fields on your ticket by workflow/ticket type. With these techniques, you should be able to support workflows as diverse as requesting a code review to approving purchase orders to guiding complex implementations through their lifecycle — complete with approvals and an audit trail.
We need to remember that none of this would be possible without the efforts of the developers who put their time and energy into making Project Open what it is.
I hope this tutorial has been helpful!