[rt-devel] Mandatory Fields

[Matt Disney]

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