Request for comments: Configurable Status

RT Users
21

Ruslan wrote:

I don’t like idea that somebody can change statuses set.

If it would be then it would be in 3.2.x or even more in 3.4.x, but now
with ‘Advanced RT Search Builder’ we can construct complex queries on CFs.
As I can see it also allow customize output of search results and save
search query.
I think there is few steps needed to meet required flexibilty in this area:

  1. Add ability to modify ticket’s CFs on reply/comment/resolve… actions.
  2. Add ability to put saved searches on own home page.
  3. Add ability to output CFs in search results.

I agree that with our organisation, if our custom fields were as available
as the status field, it would solve our problem. I am not sure this would
solve the problem for everyone, however, since there is the special
handling attached to states which might be more heavily used by some
(we don’t use anything beyond ‘open’ and ‘resolved’).

Having custom fields available on the basic update ticket and in the
initial searches would (for us) be more useful than being able to select
a status, because then we would be able to use other custom fields as
we like, instead of just a status custom field.

I guess what I’m thinking of is along the lines of RTFM custom fields.
If, alongside the queue-based custom fields, there were also global
custom fields in the style of RTFM, and these fields were available in
the default search before the queue is selected, I think that all
the comments I receive concerning status types would be ended. I’d
also like to be able to set defaults for custom fields and require a
value for a field, but these are other matters.

Another advantage for me in global custom fields would be that I wouldn’t
have to run a script to create the field whenever I create a queue. Note
that I’m not suggesting global custom fields replace queue-based ones,
because we often also have fields with the same names but different choices
in different queues.

So, in light of what Ruslan says, I’m more in favor of a greater integration
of custom fields over the modification of status names. Although I guess
both would be nice, now that I think about it more fully, the custom
field integration would give wider benefits, at least for us.

Groetjes,
Ann

22

Yes, I could live with greater integration of custom fields as well,
since I’ve already scoped out about 8 or 10 tables I want to create
based on custom fields. However, until I actual come out with a
proto-type and start playing with it, I’m unsure of what my specific
needs will be. I’m trying to do all the analysis and design right now,
before we actually start entering real data on the proto type.

I’m scoping out some hardware for purchase. And right now I’m
considering a 2.8ghz, 1 Gb Ram system with dual 250gb SATA drives. It
will probably be running some flavor of RedHat or perhaps Fedora2
[which is what I have is running on now]. I’m not expecting more than
50,000 or so tickets, but I am expecting large file attachments, as
many of our users will be asked to attached alot of data with an open
ticket. When I attached a binary file, I didn’t see it anywhere on the
file system, so I’m guessing RT 3.011 saves this as a blob in MySQL? If
so, is this configurable [in other words, to save it to the file
systems somewhere?] ? I would guess that a large number of big blobs
might impact the system.

kdl

K.D. Lucas
lucaskeli@fastmail.fm

ann@drop.2organize.com wrote:

Ruslan wrote:
  
I don't like idea that somebody can change statuses set.

If it would be then it would be in 3.2.x or even more in 3.4.x, but now

with ‘Advanced RT Search Builder’ we can construct complex queries on CFs.

As I can see it also allow customize output of search results and save

search query.

I think there is few steps needed to meet required flexibilty in this area:


    

  1. Add ability to modify ticket’s CFs on reply/comment/resolve… actions.
    2. 

  2. Add ability to put saved searches on own home page.
    3. 

  3. Add ability to output CFs in search results.
    

I agree that with our organisation, if our custom fields were as available
as the status field, it would solve our problem.  I am not sure this would
solve the problem for everyone, however, since there is the special
handling attached to states which might be more heavily used by some
(we don't use anything beyond 'open' and 'resolved').

Having custom fields available on the basic update ticket and in the
initial searches would (for us) be more useful than being able to select
a status, because then we would be able to use other custom fields as
we like, instead of just a status custom field.

I guess what I'm thinking of is along the lines of RTFM custom fields.
If, alongside the queue-based custom fields, there were also global
custom fields in the style of RTFM, and these fields were available in
the default search before the queue is selected, I think that all
the comments I receive concerning status types would be ended.  I'd
also like to be able to set defaults for custom fields and require a
value for a field, but these are other matters.

Another advantage for me in global custom fields would be that I wouldn't
have to run a script to create the field whenever I create a queue.  Note
that I'm not suggesting global custom fields replace queue-based ones,
because we often also have fields with the same names but different choices
in different queues.

So, in light of what Ruslan says, I'm more in favor of a greater integration
of custom fields over the modification of status names. Although I guess
both would be nice, now that I think about it more fully, the custom
field integration would give wider benefits, at least for us.

Groetjes,
Ann
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

RT Developer and Administrator training is coming to LA, DC and Frankfurt this spring and summer.
http://bestpractical.com/services/training.html

Sign up early, as class space is limited.
23

Although I generally find the current working model fine, I have received
feedback from others in our organization stating that they would like some
kind of access control to keep techs from making the status “stalled” as
there can be a tendency to lose or forget about tickets that are stalled.
We really haven’t seen the need at all however for custom values.

24

We have used the status “hold” in other systems. Same as “stalled”,
except a date was attached, at which time it would become open again.
Basically a “don’t bother me for a few weeks” status.

bobg