Validation of workflow

RT Users
1

I’m using RT 3.4.4 fairly successfully at my company to handle day to
day requests for my group. Some of these requests involve multiple
groups (setting up for a new build, for example). So we’ve implemented a
kind of workflow where the initial ticket is created, work is done, and
when it reaches a certain milestone (as indicated by the owner of the
ticket via transaction custom fields) another ticket is created so that
part of the setup can be started in parallel. That second ticket is
created in a different queue and copies some of the custom field values
out of the original.

We’ve found that there are times when the owner says the work has
reached the milestone, but have not completely filled in all the
required custom fields. Interally, we use the custom fields to record
and communicate attributes of the work (build location, for example), so
when that information is missing, people get confused.

The owner indicates the milestone as a yes/no custom field on
transactions. There is a Scrip that fires if there is a transaction
custom field is set to “yes” and that creates the new ticket in the
other queue.

What I’d like is one of the following, and I was wondering if anyone has
either implemented these or has any other ideas.

1)If the custom field was conditionally available on the WebRT form
based on some generic condition (like the build location is not null),
we can prevent anyone from indicating that milestone until criteria have
been met.

  1. There is an opportunity to feedback to the user that the milestone
    change is not valid prior to committing the transaction (in other words,
    the transaction is conditionally allowed to proceed). If the transaction
    fails to meet some criteria (generic condition code), it provides
    immediate feedback to the owner about why. This would obviously force
    the owner to meet criteria prior to setting the milestone.

One problem we think we have with using scrips as they exist now is that
the mechanism to create the second ticket may occur before the
"milestone is valid" check. We could combine the two scrips into one,
but then feedback is not very effective (send e-mail saying hey this
didn’t work). The fear is that the owner will in his mind think he is
done, delete the e-mail stating he’s not, resolve the ticket and never
really create the second ticket.

Any thoughts? Any other suggestions?

Thanks

-Eric

-eric

2

Eric Horne wrote:

We’ve found that there are times when the owner says the work has
reached the milestone, but have not completely filled in all the
required custom fields.

You could check the state of those custom fields before you commit
anything. Doesn’t RT->Logger have the ability to post messages that the
user can see at the top of the page? Like

$RT::Logger->error(“Fill in the Building field, dingus!”);

I’ve never actually used that, but I suppose I could.

The owner indicates the milestone as a yes/no custom field on
transactions. There is a Scrip that fires if there is a transaction
custom field is set to “yes” and that creates the new ticket in the
other queue.

Remember you can have two different bits of commit code: the “prep” code
that has to return true, and the “commit” code that has to return true.

So you could perform these checks in the prep code, and fail to commit
if the prep code doesn’t check out.

1)If the custom field was conditionally available on the WebRT form
based on some generic condition (like the build location is not null),

Gack, no idea.

  1. There is an opportunity to feedback to the user that the milestone
    change is not valid prior to committing the transaction (in other words,
    the transaction is conditionally allowed to proceed). If the transaction
    fails to meet some criteria (generic condition code), it provides
    immediate feedback to the owner about why.

Yeah, look into $RT->Logger.

Rick R.