Apologies if this has been covered extensively before; I tried searching
on Google for this beforehand…
I have a situation where we are using RT (3.4.2) extensively as part of
our support offering, and it has been suggested that we relabel a couple
of status categories to better reflect their meaning internally. (for
example, renaming ‘Stalled’ into ‘Called Customer’, etc.)
How easy would it be to do this - are the names hardcoded into the
schema, or are they just called by ‘status ID’ that can be easily
redefined? I’d rather not have to create a custom field just for this,
since that would the most part duplicate the status field (which we
would have to block out somehow).
Thanks for any suggestions you can provide.
Best Wishes - Peter
Peter_Losher@isc.org | ISC | OpenPGP 0xE8048D08 | “The bits must flow”
signature.asc (186 Bytes)
I have a situation where we are using RT (3.4.2) extensively
as part of
our support offering, and it has been suggested that we
relabel a couple
of status categories to better reflect their meaning internally. (for
example, renaming ‘Stalled’ into ‘Called Customer’, etc.)
How easy would it be to do this - are the names hardcoded into the
schema, or are they just called by ‘status ID’ that can be easily
redefined? I’d rather not have to create a custom field just
for this,
since that would the most part duplicate the status field (which we
would have to block out somehow).
In RT_Config.pm (and RT_SiteConfig.pm), it has a place where you can add
more statuses, but warns you not to remove the default ones, presumably
because there is code that references the statuses by name. If you can,
I would suggest merely adding new statuses and asking your customers to
ignore the ones they don’t use. Just be sure, however, that if you
create any status that has more than 10 characters in the name, you must
then alter the Tickets table so that Status is longer than a
varchar(10).
Eric Schultz
United Online