Rt 4

Jon_Forrest1 · May 1, 2007, 10:58pm

Jesse Vincent wrote:

If, for the sake of argument, Best Practical were to rewrite RT, what
would you want to see in the new product?

A “native mode” ticket deletion function. I know that Ruslan wrote
a ticket remover but my understanding is that RT was designed
assuming that tickets wouldn’t be deleted. In these days of
massive spam, I don’t think that’s a reasonable assumption.

Jon Forrest
Unix Computing Support
College of Chemistry
173 Tan Hall
University of California Berkeley
Berkeley, CA
94720-1460
510-643-1032
jlforrest@berkeley.edu

James_Alspach · May 1, 2007, 11:17pm

Jesse;

First let me say “Thank you” for soliciting our thoughts. This is at
the heart of why I prefer to use open source software. It is not the
money you may save but the proximity to the people whose hands are
actually in the code.

There are a few things we would like to see that have already been
mentioned. I will still mention them again here just to reinforce.
Also, I know many of the things we are looking for may be covered using
plug-in or workarounds but, since we are just tossing out ideas, I
included those as well.

Asset tracking
A way to track the lifetime of a piece of equipment along with
any upgrades, problems, etc…
Configuration / change management
It would be nice for our help desk people to be able to look to
see if work had recently been done on a specific server. If a problem
seems to be related to that work, set the owner of the server ticket as
the owner or a watcher on the new tickets being opened. Also, the
ability of that tech to see what was done and why so that he can decide
whether or not to roll the changes back.
Built in ability to customize screens
Users in group A see RTFM and a list of their open tickets but
otherwise only see the self service screen.
Users in group b see RTFM and their tickets and also have the
ability to search.
Built in management reports
Average ticket close time by tech, closed tickets by tech, top
10 requestors, etc…
Ability to print a hard copy summary of a ticket.
Something that generally fits on one page and gives an overview
of the problem and solution (if there is one).
Active Directory interface
This would allow us to set up users in AD and give them access
to RT right there.

We are not actually using RT (yet?) so these things may be less
important than they seem now and /or we may come up with other things
later, but the above are the things that my managers questioned when we
first started looking into RT.

Thanks again;
James

PS I just read someone suggest an AJAX interface. That would be cool
especially if combined with #3 and #4 above. A dashboard type interface
that a person could modify (think Google desktop or the like) up to the
limits set by the admins. Plus the ability to build a ‘window’ on the
dashboard that is the result of a saved search. Now that would be nice!

James Alspach
Systems Applications Technician
Shasta County Office of Education

Robert_Long · May 1, 2007, 11:56pm

Thanks for asking Jesse!

I’d like to jump on the AJAX bandwagon, I know, I scoff too but it
would be nifty. More flexibility in the layout.
Official support for LDAP
wildcard user names - for example if I didn’t want to give everyone
create privs on a queue but did want everyone @companyA, would be nice
to do *@companyA.com …
search builder should have an option to sum or count queries - would
be useful for adding up all the hours in a particular queue, how many
tickets requested by users in a particular time, etc
a way to set the order in which scrips run, doesn’t need to be
terribly granular, maybe 3 groups you could put them into, say 1, 2 and

Run all the scrips in the first group, then the second, the the 3rd.

.r’

Jesse Vincent wrote:

Fernando_Frota_Macha · May 2, 2007, 12:08am

A way to extract and print “service orders” to field personnel (field staff?).
We are in charge a telephone system and we need to print extracts of the
ticketst to instruct the technicians that will fix the customer problems.
Something like the “extract articles” option.

Ability to print a hard copy summary of a ticket.
Something that generally fits on one page and gives an overview
of the problem and solution (if there is one).

 Fernando Frota Machado de Morais
    IR Team - Divisao de Redes de Comunicacao
    Centro de Computacao
    Universidade Federal de Minas Gerais
    Brasil
    Tel. +55(31)3499.4007  Fax. +55(31)3499.4004

/"
\ / Campanha da fita ASCII - contra mail html
X ASCII ribbon campaign - against html mail
/ \

Pedro_Santa · May 2, 2007, 1:09am

Hi Jesse!

Here it goes then…

Tickets Moderation!!: Even with spamfilters some spam still reaches
RT. So, in order to have a clean RT I would like to have an moderation
interface similar to mailman’s approval/moderation interface.
Something like, “Tickets waiting for moderation”. This would make the
RT Database lot less spammed. Rejected tickets would inform the
requestor of the rejection.
RSS feeds: Why not!
A Global costumizable CSS.

That’s all I remember… for now.

The best regards.

Pedro Machado Santa

Mathew_Snyder2 · May 2, 2007, 1:36am

Shredder is actually native in the 3.7 devel release.

Keep up with me and what I’m up to: http://theillien.blogspot.com

Jon Forrest wrote:

Robert_Blayzor · May 2, 2007, 1:29am

Pedro Santa wrote:

Tickets Moderation!!: Even with spamfilters some spam still reaches
RT. So, in order to have a clean RT I would like to have an moderation
interface similar to mailman’s approval/moderation interface.
Something like, “Tickets waiting for moderation”. This would make the
RT Database lot less spammed. Rejected tickets would inform the
requestor of the rejection.

RSS feeds: Why not!

A Global costumizable CSS.

I would have to agree with the three above, all great ideas that
probably be nice additions to the current version or new version if
possible.

Ticket moderation is a good idea; maybe even something as simple as if a
ticket comes in via email a confirmation email and link is provided. I
know this might not work in all cases… or maybe even have a queue for
approved new tickets, some make it into the appropriate queue, while
others can be discarded.

RSS would be nice… Many RSS clients would allow a quick view at the
queues.

And yes, global CSS for the look and feel. (ie: skins) would be nice.

Robert Blayzor, BOFH
INOC, LLC
rblayzor@(inoc.net|gmail.com)
PGP: 0x66F90BFC @ http://pgp.mit.edu
Key fingerprint = 6296 F715 038B 44C1 2720 292A 8580 500E 66F9 0BFC

Nostalgia: The good old days multiplied by a bad memory…

Mathew_Snyder2 · May 2, 2007, 1:51am

RSS already exists in 3.6

Mathew
Keep up with me and what I’m up to: http://theillien.blogspot.com

Pedro Santa wrote:

Philip_Kime · May 2, 2007, 2:32am

One thing I saw mentioned was Mandatory field support - we implemented a
pretty robust Mandatory field system in RT here with a separate checkbox
so that validation and Mandatory are separate. Also pushed all the code
into the core API so it works via REST, email and GUI. This has been
submitted as patches against 3.6.3.

Another thing is the ability to display (and sort by) the RealName of
users everywhere instead of the Name field. This is crucial in (silly)
places where the policy is to have completely numeric usernames (like
AD/LDAP authentication where corporate policy is employee IDs as
usernames …). RT is really crippled if you can’t tell easily by
looking, who did what. I have patches to put in two flags to decide
which to display, against 3.6.3. Jesse mentioned that this might already
be in 3.7 but I installed 3.7.1 and there doesn’t seem to be anything in
there like this.

PK

Asif_Iqbal2 · May 2, 2007, 2:49am

Would be nice to have PAM auth builtin or capabilities.On 5/1/07, Philip Kime pkime@shopzilla.com wrote:

One thing I saw mentioned was Mandatory field support - we implemented a
pretty robust Mandatory field system in RT here with a separate checkbox
so that validation and Mandatory are separate. Also pushed all the code
into the core API so it works via REST, email and GUI. This has been
submitted as patches against 3.6.3.

Another thing is the ability to display (and sort by) the RealName of
users everywhere instead of the Name field. This is crucial in (silly)
places where the policy is to have completely numeric usernames (like
AD/LDAP authentication where corporate policy is employee IDs as
usernames …). RT is really crippled if you can’t tell easily by
looking, who did what. I have patches to put in two flags to decide
which to display, against 3.6.3. Jesse mentioned that this might already
be in 3.7 but I installed 3.7.1 and there doesn’t seem to be anything in
there like this.

PK

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu

Sasha_Gerrand · May 2, 2007, 8:31am

Active Directory interface
This would allow us to set up users in AD and give them access
to RT right there.

This falls under LDAP, really. If you have native LDAP functionality
(bind, query, filter, etc), you can bind to an AD server. It’d be good
to see this moved into the core functionality.

I’d like to see better documentation, myself. It took me a while to get
to grips with the way some of the functions work.

Regards,
Sasha

Sasha Gerrand
Web & Database Developer

Austbrokers Holdings Limited
Level 21, 111 Pacific Highway
North Sydney NSW 2060
PO Box 1813 North Sydney NSW 2060

Ph: 02 9935 2230
Mobile: 0448 278 500
Email: sashag@austbrokers.com.au
Web: http://www.austbrokers.com.au

NOTICE
If you are not an authorised recipient of this email, please contact
Austbrokers Holdings immediately by return e-mail or by telephone on
+61-2-4920-6117. In this case, you should not read, print, re-transmit,
store or act on this e-mail or any attachments. Please destroy the
message and attachments. This e-mail and any attachments are
confidential and may contain legally privileged information and/or
copyright material of Austbrokers Holdings or third parties. You should
only re-transmit, distribute or commercialise the material if you are
authorised to do so. Internet e-mails are not necessarily secure,
Austbrokers Holdings does not accept responsibility for changes made to
this message after it was sent. This Notice should not be removed.From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of James
Alspach
Sent: Wednesday, 2 May 2007 9:18 AM
To: rt-users@lists.bestpractical.com
Subject: RE: [rt-users] RT 4

Jesse;

First let me say “Thank you” for soliciting our thoughts. This is at
the heart of why I prefer to use open source software. It is not the
money you may save but the proximity to the people whose hands are
actually in the code.

There are a few things we would like to see that have already been
mentioned. I will still mention them again here just to reinforce.
Also, I know many of the things we are looking for may be covered using
plug-in or workarounds but, since we are just tossing out ideas, I
included those as well.

Asset tracking
A way to track the lifetime of a piece of equipment along with
any upgrades, problems, etc…
Configuration / change management
It would be nice for our help desk people to be able to look to
see if work had recently been done on a specific server. If a problem
seems to be related to that work, set the owner of the server ticket as
the owner or a watcher on the new tickets being opened. Also, the
ability of that tech to see what was done and why so that he can decide
whether or not to roll the changes back.
Built in ability to customize screens
Users in group A see RTFM and a list of their open tickets but
otherwise only see the self service screen.
Users in group b see RTFM and their tickets and also have the
ability to search.
Built in management reports
Average ticket close time by tech, closed tickets by tech, top
10 requestors, etc…
Ability to print a hard copy summary of a ticket.
Something that generally fits on one page and gives an overview
of the problem and solution (if there is one).
Active Directory interface
This would allow us to set up users in AD and give them access
to RT right there.

We are not actually using RT (yet?) so these things may be less
important than they seem now and /or we may come up with other things
later, but the above are the things that my managers questioned when we
first started looking into RT.

Thanks again;
James

PS I just read someone suggest an AJAX interface. That would be cool
especially if combined with #3 and #4 above. A dashboard type interface
that a person could modify (think Google desktop or the like) up to the
limits set by the admins. Plus the ability to build a ‘window’ on the
dashboard that is the result of a saved search. Now that would be nice!

James Alspach
Systems Applications Technician
Shasta County Office of Education

-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-
bounces@lists.bestpractical.com] On Behalf Of Jesse Vincent
Sent: Tuesday, May 01, 2007 10:55 AM
To: RT Users
Subject: [rt-users] RT 4

If, for the sake of argument, Best Practical were to rewrite RT, what
would you want to see in the new product?

Think big.

Jesse

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

Community help: http://wiki.bestpractical.com Commercial support:
sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Jan_Grant · May 2, 2007, 8:40am

If, for the sake of argument, Best Practical were to rewrite RT, what would
you want to see in the new product?

Keep the decent layered architecture.

(Obviously) a complete REST or other remote api. (I like the
simplicity of the REST model.)

Extend externally pluggable authnz: in two minds about that. I’d like to
get closer integration of the group management in particular with our
LDAP service here (which is built around the OID provisioning tools).
However, there’d be nothing to stop me from integrating closely already
using the existing capabilities of OID’s provisioning tools, IF group
membership were manageable via a remote API. The external authn is
already good.

Query model: it’d be nice to get full text search out of the box. The
stock query builder is the thing we get most complaints about from our
users, and is the thing that’d benefit most from closer web-client
integration.

Tidy up some of the loose ends: better integration of custom fields with
the mailgate, for instance.

Namespace management: eg, being able to configure per-queue custom
fields in a per-queue namespace.

Perhaps “queue groups” for the above.

Some finer-grained SeeQueue/QueryQueue rights. We typically turn off
“SeeQueue” for our users in order to manage the front-page clutter (a
hundred queues is a lot) - but we’d really like them to be able to raise
tickets and query across all queues. So, some approach to this - possibly
using UI-specific rights on queues to manage the default home-page
widgets; possibly just having some better parameterisable UI widgets.
“Queue groups” might help here.

Think big.

When and only when the above are addressed the “think big”: we’re
using RT in anger here - the application of technology to solve people
problems - to stop requests between teams from dropping on the
floor; looking at it to manage requests for access to e-science grid
systems; and a whole bunch of other kinds of things. Lots of folks want
RT set up in different ways - eg, a “closed shop” where users are all
preregistered or a more traditional outward-facing setup.

That typically means multiple RT instances. However, by having lots of
RT instances, you lose a lot of the benefit of having all your queues
under one system. I don’t have a design for this, or even more than a
vague “it’d be nice” feeling, but it’d be nice to have some kind of
inter-RT-instance capability: even if that just means divorcing the UI
from the instance and having one UI capable of fronting several RT
instances together.

Cheers,
jan

jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/
Tel +44 (0)117 3317661 jan's very old home page
There’s no convincing English-language argument that this sentence is true.

Luca_Villani · May 2, 2007, 8:50am

Alle 19:54, martedì 1 maggio 2007, Jesse Vincent ha scritto:

If, for the sake of argument, Best Practical were to rewrite RT, what
would you want to see in the new product?

native and official LDAP/AD support;
mysql replication cluster support.

Luca Villani Mobile Team, Dada S.p.A.
Tel: +39 055 2267220 Mob: +39 335 8753086
ICQ: 76272621 Skype: luca.villani
GPG key fingerprint: 7FC9 E2FE 0BEE 9DF8 1719 8761 1B79 82CC F0B5 B7CF

Manuel_Subredu · May 2, 2007, 9:20am

Hi,

thanks for asking. All my wishes have been said. All but 2.
I would really like a better organized web interface from a web
designers point of view. This will open the way for the second wish.
Support for themes per user and per group.

Jesse Vincent wrote:

John_Parker · May 2, 2007, 9:19am

As a code-blind admin I would love to see a slicker front end out of the
box: I know lots of people will have applied their web design skills to
build on RT but I for one can’t.

I would also love to see a RTFM grow to be a knowledge base module with
an inline editor like kupu or FCK so that we can create content rich
articles.

Echoing other comments an asset tracking module / change management
functionality would be good.

Regards

John Parker

We have taken all reasonable precautions to ensure that no viruses are transmitted from FMG Support to any third party. FMG Support accept no responsibility for any damage or loss resulting directly or indirectly from the use of this e-mail or its contents.

This e-mail and any files transmitted with it are confidential and solely for the use of the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on this e-mail, is prohibited and may be unlawful. Opinions expressed in this e-mail are those of the individual and not those of the Company unless specifically indicated to that effect.

If you have received this e-mail in error please inform us and delete it from your mailbox and/or any other storage mechanism.

FMG Support Ltd T:0870 830 3830 mailto:support@fmgsupport.com.

FMG Support Ltd. Registered in England. Company registration number: 3813859.
FMG Support Ltd (FIM). Registered in England. Company registration number: 2658067.
FMG Support Ltd (RRRM). Registered in England. Company registration number: 2762997.
FMG Support Ltd (VRM). Registered in England. Company registration number: 2415387.
Registered office: FMG House, St Andrews Road, Huddersfield HD1 6NA.

Steve_McStravick · May 2, 2007, 1:13pm

Here are a few ideas that I’d like to see.

1- Complete the Project Management piece. We really struggle trying to get
tickets related to projects organized and reported on properly.
2- Ability to De-select Global Templates/Scrips on a queue
basis…currently I need to delete the Global Scrip/Template and recreate
them in each queue which does use them.
3- This is related to the #2, if it isn’t possible…ability to copy
scrips/templates or at least assign them to a queue (similar to the way
custom fields are done)
4- Better configuration options to the ticket entry display…Currently the
customer fields are in 2 rows which you could select the order, but
depending upon the cf type, I may want to see 3 custom fields in one row,
only one in another
5- Maybe someone already has a hack for this…but having a drop-down list
for Custom Fields (select one value)…like is available for “status” or
“owner”… It would just make the ticket display look cleaner.
6- The Rtx:EmailCompletion module is very handy for time-saving and less
data-entry errors…seeing that Native to RT would be great.

Thank you Jesse for a great product already!

Steve McStravick
Business Systems Analyst - MES
BreconRidge
www.breconridge.com

Isaac_Vetter · May 2, 2007, 1:36pm

Hey Jesse;

Think big.

One idea I have would be to maintain a focus on simplicity.

I hadn’t intended to reply to this, because I figured that there would
be no shortage of suggestions.

Although I’d like to see bundled LDAP integration, methods for better
handling spam, ajax RT’s and RTFM’s web interface, the ability to more
easily create scrips …

The single thing that would increase adoption rates of RT is easier
installation; be that a live cd, an option of bundled perl mods/db, or,
preferably, just a simple install.

Isaac Vetter

smime.p7s (2.85 KB)

Dmitri_Tikhonov · May 2, 2007, 1:39pm

Isaac Vetter wrote:

The single thing that would increase adoption rates of RT is easier
installation; be that a live cd, an option of bundled perl mods/db, or,
preferably, just a simple install.

How about PAR files? They can also contain apache configuration in them.

Dmitri.

http://par.perl.org

Sven_Sternberger · May 2, 2007, 2:24pm

my 2c

1.) Archiving - Store tickets older then 2 years in archive. It should
be possible to search the archive.

2.) Better User Interface (look at launchpad from ubuntu)

3.) User Management. We have 50 Users in our department, and

1000 user on the campus. So we start to organize everything in groups,
but this sometimes don’t works with RT. We have 15 queues, for
each queue I defined a group, which is allowed to work on tickets,
one group to get emails from this queue, and on to see the queue in
ui. The result is that I have > 45 groups. I’m not sure how to solve
this, but I think a “role” would be helpful. So I define roles
for the queues and assign the roles to the users

4.) user management. delete user, assign additional email adresses,
merge users.

5.) ticket management. purge tickets by status, purge tickets by
creator. we need this to handle spam and even worse the trillions
of mails/tickets monitor scripts produce by accident.

6.) rich email gateway. seems to be very difficult.
signatures won’t work, because there to complicated
to install and maintain in big organizations.

7.) Management tools. my boss would like a report page.
how many tickets came into our department, how much
does we solve, how long it take (not as a queue view,
but for the instance).

8.) cli/gui. A external tool would be nice, which supports
handicap (blind) person, offline usage and faster
search results via caching.

9.) packaging I want a apt/yum repository for REHL
and Debian systems. All these problems with CPAN and
perl version vs. distribution version … are annoying
I think it should be easy to build the packages, and
for this kind of service I would willing to spend some money.

10.) support. this is not directly related to the software.
but i would wish that you offer support via. email in a
smaller size. So we have 200k Tickets, but we don’t want a platinum
contract. All we want is a address to send support questions,
and get an answer in a week.

hope that helps!

svenOn Tue, 2007-05-01 at 13:54 -0400, Jesse Vincent wrote:

If, for the sake of argument, Best Practical were to rewrite RT, what
would you want to see in the new product?

Think big.

Jesse

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Jon_Daley1 · May 2, 2007, 2:29pm

If, for the sake of argument, Best Practical were to rewrite RT, what would
you want to see in the new product?

I'd like to be able to merge users, so someone can respond with

any of the email addresses that he has, and they are all treated as the
same email address - ie. no reply to his other email address, if he logs
in, he will see all tickets requested by any of his email addresses. It
would probably be nice to have the same password for all email accounts,
though that part isn’t necessary.