Here 'tis.
My addition to the Create {} subroutine is lines 130-138. The check for
uniqueness and auto-choosing the next highest number happen in
additional subroutines beginning at line 230.
We call the relevant field “COE Number” (sometimes “CoE Number”, the
case seems not to matter); change that wherever I have it to whatever
you call your field.
Lines 133 and 137 are where I needed to know that the custom field was
#1 (‘CustomField-1’). There are two SELECT queries, one (line 322)
where I searched for the field by name and one (line 244) where I
searched for it by number. Probably I should have done both of those
the same way, for clean code purposes. Probably searching by name would
be the way to go, for even cleaner code purposes.
We assume that we’ll be adding (whenever I get this live) existing
assets to a clean database, so we accept input for the COE Number. I do
some basic testing, to make sure that if there is input, it is a number
and not, say, an SQL command. I don’t do any sort of sanity checking on
the given number, except to see if it’s already in use; someone could,
for instance, input “1000000” instead of “1000” and kick our asset
numbers up a few orders of magnitude. Probably with some additional work
the getNextNumber subroutine could look for such gaps and fill them in,
but I don’t think I’ll be getting around to that extra work anytime soon.
I believe there are some rigorous tests that can be used on RT
extensions; I have not done anything of that sort with this code. I’ve
only played with it on a couple of test systems (both RT 4.2), but it so
far does what I want it to.
If you have any questions, I’ll try to answer, hopefully with something
better than “It made sense at the time”.
If any accomplished programmers would like to shred it and tell me
everything I could do better, I’d appreciate the education.
Share and enjoy,
KyleOn 03/15/2016 12:34 PM, Seever, Kenny wrote:
Kyle,
Thanks for the reply. If possible would you be willing to share what
you have? This will be something I�ve never attempted so need all the
help I can get.
Thanks again,
Kenny
*From:*Kyle Dippery [mailto:kyle.dippery@uky.edu]
Sent: Monday, March 14, 2016 8:34 AM
To: rt-users@lists.bestpractical.com
Cc: Seever, Kenny Kenny.Seever@mgpingredients.com
Subject: Re: [rt-users] Unique custom fields for assets
Kenny,
I haven’t looked at RT 4.4 yet, so perhaps it’s built in there, but it
wasn’t in RT 4.2.
What you will need to do, if it isn’t there already, is create your
own extension to the Asset.pm module, call it Asset_Local.pm, and add
code there to check for uniqueness and auto-populate the field. The
Create {} subroutine is the one you’ll most likely want to override.
One gotcha that I remember (I did this about a year ago) is that I
needed to know the number of the custom field; I couldn’t figure out
how to search the $args{} array for the field by name. That being our
most critical custom field, though, it made sense to create it first
so it would be “CustomField-1”.
I’m reluctant to post my actual code, because it’s crappy and I don’t
want to release bad code into the wild, but if you’d like to see it I
can sanitize it some and share it.
Cheers,
Kyle
On 03/11/2016 11:38 AM, Seever, Kenny wrote:
Hello,
I am working on evaluating using the Assets module in RT to manage
our equipment, but haven�t been able to figure out if there is a
way to make a field unique. All of our equipment has a 5 digit
asset number (2XXXX) that is unique. I need to be able to add a
field that makes sure that each number is only used once. Ideally
it would auto populate with the next number when a new asset is
added, but that may be asking for too much. Is there build in
functionality for any of this that I�ve missed in the documentation?
Thanks in advance,
Kenny
–
Kyle Dippery
Engineering Computing Services
219 RMB
859-257-1346
Kyle Dippery
Engineering Computing Services
219 RMB
859-257-1346
Asset_Local.pm (8.3 KB)
