Hi All,
Has anyone implemented Mandatory Fields when updating a ticket?
Scenario: We want to force users to enter e.g. time “Worked:” value
before updating/resolving a ticket.
Has anyone done this?
I was considering using java-script to merely NOT submit if the
particular field is not filled but that would not be the solution, as it
would not be transaction linked, but merely to a page.
Any suggestions are welcome?
Rehan van der Merwe
Neil Harvey & Associates
Hi All,
Has anyone implemented Mandatory Fields when updating a ticket?
Scenario: We want to force users to enter e.g. time “Worked:” value
before updating/resolving a ticket.
Mandatory fields are a PITA. That is, from end-user perspective.
If they feel like it or have a reason to --and that moment will come-- they
will enter rubbish just to satisfy the “Sorry. This field is mandatory” form.
And from that moment on you’ve got junk data in your system.
Additionally, I personaly I find MF’s extremely irritating. Ever filled up a
company car at a gas station and you were required to punch in the mileage?
Ever visited a braindead web registration form and were forced to enter a ZIP
code just for submitting an email question? Then you know what I’m talking
about
FAFIC MF’s are “bugs” in the work policy. You should educate your
managers/end users for a proper work policy. If you must use MF’s limit it’s
use to the fields which are part of the logic of the data structures. E.g.
there is not much point in selecting an item if you haven’t entered it’s id)
JMO.
Koos Pol
Release Engineering - Compuware Europe B.V.
T: +31 20 3116122 E: koos_pol@nl.compuware.com
Koos Pol wrote:
FAFIC MF’s are “bugs” in the work policy. You should educate your
managers/end users for a proper work policy. If you must use MF’s limit it’s
use to the fields which are part of the logic of the data structures. E.g.
there is not much point in selecting an item if you haven’t entered it’s id)
Though I agree in general with Koos’ statements and specifically with
the ideal scenario being to properly educate your supported users to
enter appropriate information, I don’t think that’s always a realistic
goal. For example, educating a very large number of users (maybe a
quantity of five digits) to follow appropriate policy without enforcing
the policy through some kind of technical device is often just not
possible. I believe there are at least a couple of other common
support-ticket-input scenarios where policy enforcement is much more
practical than user education.
There is also a school of thought where policy is meaningless without
enforcement, be it through human or technical (computerized) processes.
That doesn’t exactly hold up in court, of course. 
To address the original inquiry about mandatory fields…
At a previous site where I implemented RT2, they wanted mandatory fields
for Name, Email, and a few other text fields that were pre-pended to the
ticket Content (e.g. Employee Number). I ended up with a system where we
had custom form pages for creating tickets and each of those pages had
an array containing which fields were mandatory.
It required modifying both the Create.html and Display.html pages (or
actually copying them for specific purposes and modifying them).
Create.html passed the mandatory fields list as an argument to
Display.html (in the hopes that such a design would be at least slightly
more easily extensible). If a mandatory field was missing, Display.html
kicked all the args back to Create.html, which would display the
originally input data in their forms along with an error message at the
top of the page explaining which fields had been left out. I had to pull
a trick concerning field names to make them more understandable to the
reader. I did this by specifying a “readable label” of the field, if you
will, along with the field name in the array I used for specifying which
fields were mandatory. It got the job done, but I really felt like the
whole thing was kludgy. Something like this could also do the job for you.
At my current site (RT3), I’m not using the aforementioned
implementation. However, we are currently creating some extensions to RT
that allow it to be used for accepting job applications. We decided to
go with RT, at least for the time-being, instead of rolling our own
database/web app because RT already had the framework to do a lot of
what we want… especially in the realm of ACLs.
The applicant processing extension we’re writing relies heavily on
CustomFields and some of them are mandatory (per the specification of
the selection committee). So we have created a couple of ways to
leverage the Descriptions of CustomFields. The first thing is that we
include a grouping within the CustomField Description. Accordingly, we
have a component that will display input forms for all CustomFields
matching some pattern, where that pattern could be found in the CF
Description. For example, we have a forms page with sections dedicated
to collecting “Personnel Info” or “References” information, where each
of those is a grouping of CFs. Similarly, we determine if a CF is
“Required” by searching for that string in the CF Description. Because
we’re using loose pattern matching, we have a lot of flexibility for
using the CF Description as an auxiliary data field… but we’ll need to
be careful about group names (can’t have “Required” in a group name or
everything gets screwy). And/or we could easily tighten up the RE
matching later.
We’re in the middle of development right now and still wrangling with a
couple of issues. But all in all, I think our extensions will be a quick
way to get a nice applicant processing system online.
I have a student assistant working on this with me. If/when we have
something presentable, we’ll be glad to share the result. I’m also
interested in hearing about other implementations of mandatory fields
(or applicant processing!) with RT.
Matt Disney
IT Administrator
Electrical and Computer Engineering
University of Tennessee