RT2 progress

RT Developers
1

The last days I’ve been doing almost nothing, as usual. Well, I’ve been
knocking my head a bit towards the wall because Jesse has done changes to
the Mason setup which required mod_perl and broke my CGI version.

Well, I guess I finally discovered that Apache::Session had nothing to do
with neither Apache nor mod_perl, so it was only fear that caused
me to knock my head towards the wall, and nothing else. It was really
nothing but looking through Jesses updates and then it was simple
plug’n’pray to get it into the .cgi. Well, the praying didn’t help that
much, I did have some problems, and it seems like I’m still having
problems, but I will probably resolve it.

The next problem that occurred was that Jesse had used an Apache request
object, which is a mod_perl thingy. I’ve quickly set up a wrapper object,
and I’ll add functionality to it until it works here.

Jesse is currently dealing with the GUI, so I can’t do much there. As I
see it, most of the things that remains before we can actually
start using RT2 here is related to the GUI.

I’m mostly done with my work with the links, except for the user interface
things. I’ll discuss my thoughts in my next mail.

The GUI development is totally controlled by Jesse at the moment.
Jesse; how much work would you suggest that remains? When he is finished,
I expect to use some days for debugging his things, adding things he has
forgotten and add other things that is important here.

Jesse has made some very basic authentication. It seems to work good
enough as for now.

The non-GUI-thing we really need before we can try to deploy RT2 here, is
to fix the date handling! I had totally forgotten about it! I’ll try to
deal with that today.

Except for that, there is:

  • probably a lot of details

  • user information + user prioritying.

Locally, we often have users with different emails. We need to keep track
of them, also when they change emails. We need to store comments about
them. Most important; we must be able to rate them! Good customers
should get a higher priority than ordinary requestors, and those
should get a higher priority than those who constantly bother us with
stupid FAQs.

I’d daresay that this will not be included in the official RT 2.0 release,
but it will be available as a user contributed patch, and it will be
included in post-2.0 releases (from now on; contr).

  • Admin tools & ACL.

We don’t need it locally for some weeks, at least - I handle it through
SQL as for now. Anyway, it must come before the official RT 2.0 release.

  • Groups

This is essensial for us if an admin tool should be useful. contr.

  • “Smart” Next/Prev-links

This is a GUI detail, which probably will have to wait until post-2.0.
(from now on; post).

  • Smart autoreplier

I have described the functionality earlier, and I think this is a good
thing. might be contr, might be post.

  • all other requested nifty features

post, probably :slight_smile:

Jesse has some RT1 queues at www.fsck.com for RT2 projects, bugs and
similar. Anyway, I find it a bit easier to deal with a plain text file,
so I will store this mail in the TODO file in the CVS. :slight_smile:

tobix@fsck.com

2

I am currently using RT 1.0.1 in a mid-sized (125 user) fast growing
business environment. RT has done well for the trouble-ticket facet of my
workspace, but where it is really lacking (especially when one considers
commercial products) is an integration of asset management tools.

I suggested to Jesses that perhaps some form of asset managment could be
integrated with RT. I would certainly voluteer my time to coordinate (and
write some code) for such a project. I have a moderately strong grasp of
database design and API abstraction, it is getting all that code written
that costs me… of course, having asset tracking would free up so much of
my time :slight_smile:

In any event, I am voluteering myself to be the contact person for this
effort. I would like to get a group of interested folks together to
collectively come up with possible ways to tackle this. Perhaps we can
even get so far as to have a basic design in mind.

I think that the best scheme would be to coordinate the integration with
RT, but have the asset management ‘seperate’ enough that it could be
developed and extended as a psuedo-independant entity. Probably the
biggest challenge would be to define the interface between the two
‘programs’ – deciding what they need to ‘know’ and ‘get’ from each other,
and putting in the proper hooks. Another big brainstorm would be coming
up with an asset system that is flexible enough to work in a wide range of
environments (as it RT) with maximum of portability.

I’m just tossing out the idea tonight… I have deeper ideas on the
subject, but am too beat to search for them. Please do contact me if you
want to converse on this more. I’m sure I am not the only one who wishes
they had a web-based asset tracking/managment system right there alongside
RT on an internal webserver!

Patrick

Patrick Hennessey Manager, Information Solutions
spectre@sigmatel.com SigmaTel, Inc.

defination of active imagination by C.G. Jung:
“a sequence of fantacies produced by deliberate concentration”

3

I am currently using RT 1.0.1 in a mid-sized (125 user) fast growing
business environment. RT has done well for the trouble-ticket facet of my
workspace, but where it is really lacking (especially when one considers
commercial products) is an integration of asset management tools.

Hm, my English comes a bit short here. An asset, what is it? I have a
feeling that you’re thinking of values the companies owns, such as all
kind of equipment, bank accounts, loans, cars, software licenses, food
in the fridge, +++?

There is some tools I’ve always wanted for personal usage as much as
anything else; a good asset management, a good tool for tracking
requests as well as private mail, a good tool for keeping a
calendar/diary, and a good tool for tracking worktasks, and all this
perfectly integrated. Every item I have should have a built in GPS and a
wireless communication to the database. There should be a bar code reader
and a weight at the fridge door, so it always would be easy to update the
database of what’s inside the fridge. That way I would always manage to
locate my passport, my keys, the box opener (we have started the concept
of redundancy at home; in every drawer there is a scissor, and we have
four box openers and three wine openers distributed through the drawers

  • but still it’s an expensive concept), the cheese I bought last week
    and maybe I would even manage to find my kitchen table. I’m too much of a
    mess to keep track of all those things myself, I need technology to help
    me. Well, in most cases low-tech solutions might help out better for a
    single individ (because the database administration might be too
    cumbersome and time consuming), but for a mid-size and big company it’s
    different.

I have a dream that all those things might come true for some future
version of RT. RT3, maybe :slight_smile:

While RT1 is good enough for our support department, I must admit that
it’s not good enough for me.

So I absolutely encourage you to share your ideas, and come with the
different instances where it makes sense combining an asset manager with a
request tracker.

I think that the best scheme would be to coordinate the integration with
RT, but have the asset management ‘seperate’ enough that it could be
developed and extended as a psuedo-independant entity.

nod. We have the link concept that should make it easy to “draw links”
between one external database system and RT.

I’m just tossing out the idea tonight… I have deeper ideas on the
subject, but am too beat to search for them. Please do contact me if you
want to converse on this more. I’m sure I am not the only one who wishes
they had a web-based asset tracking/managment system right there alongside
RT on an internal webserver!

I guess it’s really hasn’t that much to do with RT. Put it up as a
project at www.SourceForge.net, or ask Jesse to create a project for it at
cvs.fsck.com, and get a separate mailinglist for it.

4

I am currently using RT 1.0.1 in a mid-sized (125 user) fast growing
business environment. RT has done well for the trouble-ticket facet of my
workspace, but where it is really lacking (especially when one considers
commercial products) is an integration of asset management tools.

Hm, my English comes a bit short here. An asset, what is it? I have a
feeling that you’re thinking of values the companies owns, such as all
kind of equipment, bank accounts, loans, cars, software licenses, food
in the fridge, +++?

Asset managment is keeping track of things like hardware, peripherals and
components. It’s probably the number one most requested complement to RT
these days. There are a number of ways in which RT and an asset manager
could be tied together to make using RT for IT / systems support better.
Imaging being able to see all the tickets associated with the mail server
in the corner. Or see how many Quad Fast Ethernet cards have needed
tickets opened against them. These are the sorts of things that
asset managment will bring to RT. I was overjoyed when Patrick
volunteered to help coordinate RT Asset Tracking (Asset Tracker?).
A bit of the initial discussion is probably relevant here, but I expect
to branch it to its own list soon.

Asset managment is, I hope, going to be loosely coupled to RT. it should
be possible to use RT without AT and vice versa. That said, I hope
that AT gets implemented using the same basic Database API and
the same web templating system. The two tools should “Feel” similar
to programmers and end users.

I guess it’s really hasn’t that much to do with RT. Put it up as a
project at www.SourceForge.net, or ask Jesse to create a project for it at
cvs.fsck.com, and get a separate mailinglist for it.

A seperate CVS module and list have always been in the plans.

jesse

jesse reed vincent – jrvincent@wesleyan.edu – jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
rlon. It is incredibly powerful, gives terse,
cryptic answers and has a lot of things going on in the background.

5

Jesse is currently dealing with the GUI, so I can’t do much there. As I
see it, most of the things that remains before we can actually
start using RT2 here is related to the GUI.

Well, I’m doing some work with the GUI. but not as much as I’d like.
I’m just too damn busy these days. but the ticket display looks a bit
better right now.

I’m mostly done with my work with the links, except for the user interface
things. I’ll discuss my thoughts in my next mail.

If I’m correct the API for dealing with sets of links is also
missing.

The GUI development is totally controlled by Jesse at the moment.
Jesse; how much work would you suggest that remains? When he is finished,
I expect to use some days for debugging his things, adding things he has
forgotten and add other things that is important here.

If I had a web designer to do the design it would probably be a week of
fulltime hacking to get something reasonably robust. I don’t. nor do I have
time to work full time on this right now.

Jesse has made some very basic authentication. It seems to work good
enough as for now.

where for now != production. it checks to see if the password is the same
as the username. this should be pretty trivial to fix.

The non-GUI-thing we really need before we can try to deploy RT2 here, is
to fix the date handling! I had totally forgotten about it! I’ll try to
deal with that today.

Except for that, there is:

  • probably a lot of details

  • user information + user prioritying.

Locally, we often have users with different emails. We need to keep track
of them, also when they change emails. We need to store comments about
them.

Sure. the schema for user comments is there, someone needs to write the
web admin ui for user manipulation

Most important; we must be able to rate them! Good customers
should get a higher priority than ordinary requestors, and those
should get a higher priority than those who constantly bother us with
stupid FAQs.

I’d daresay that this will not be included in the official RT 2.0 release,
but it will be available as a user contributed patch, and it will be
included in post-2.0 releases (from now on; contr).

That, in my mind, is fairly useless bloat. you’re welcome to spend your
time on it. but I can almost guarantee that it will stay as a contrib. item

  • Admin tools & ACL.

We don’t need it locally for some weeks, at least - I handle it through
SQL as for now. Anyway, it must come before the official RT 2.0 release.

  • Groups

This is essensial for us if an admin tool should be useful. contr.

  • “Smart” Next/Prev-links

This is a GUI detail, which probably will have to wait until post-2.0.
(from now on; post).

  • Smart autoreplier

I have described the functionality earlier, and I think this is a good
thing. might be contr, might be post.

Post 2.0

  • all other requested nifty features

post, probably :slight_smile:

Jesse has some RT1 queues at www.fsck.com for RT2 projects, bugs and
similar. Anyway, I find it a bit easier to deal with a plain text file,
so I will store this mail in the TODO file in the CVS. :slight_smile:

The TODO file should, if anything, be generated from the queues. I really
don’t like it having items that aren’t tracked in RT in it.

–
tobix@fsck.com

Rt-devel mailing list
Rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel

jesse reed vincent – jrvincent@wesleyan.edu – jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
, he would have given us an internal
materialisation/dematerialisation control.
– Shoshe Cole

6

Would anyone else than me want this feature?

[tobix]

Good customers
should get a higher priority than ordinary requestors, and those
should get a higher priority than those who constantly bother us with
stupid FAQs.

[jesse]

That, in my mind, is fairly useless bloat. you’re welcome to spend your
time on it. but I can almost guarantee that it will stay as a contrib. item

Actually the possibility to sort out and priority requests by grouping
requestors is something we will need here. I can hardly think that this
is the only place it’s needed?

Of course a workaround is to have a separate queue for high-priority
requestors, and only give those access to the separate queue.

As earlier mentioned, in a “pure” request tracking setting (lots and lots
of requests, most requests only demand one reply, and if a request should
involve more amounts of work anyway, it should be “spawned” or moved to
the 2nd line support queue. In this scenario priorities for the 1st
line support queue won’t make any sense at all unless they are automaticly
set.

tobix@fsck.com