Rt 4

RT Users
61

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

Think big.

Reiterate what some others have stated:

  1. Better Reporting - Average ticket close time by tech, closed tickets
    by tech, top 10 requestors, etc…
    I’ve needed to create all these, now learning / using Jasper, but it
    was a pain to come up with all the queries. I’m not a report creator,
    nor a SQL expert, and don’t have time to learn everything.

  2. Rights Management - I have “the book” (RT Essentials), and sometimes
    still confused (lots of trial and error).

  3. Easier way to do write SCRIPs. - For the “non-tech” bunch. Like how
    MS-Outlook (shudder) does rules (Rules and Alerts Wizard) - so easy,
    even my end-users can do it!!

  4. Active Directory interface/native integration - This is a biggie.
    NOBODY want’s / needs an extra user ID / password combo to remember.

  5. Asset Tracking built in - cradle to grave, I need to know a device’s
    history and problems.

Mike M.

62
  1. Rights Management - I have “the book” (RT Essentials), and sometimes
    still confused (lots of trial and error).

+1 on this. It would be great to have something like RTx::RightsMatrix in
core RT.

  1. Active Directory interface/native integration - This is a biggie.
    NOBODY want’s / needs an extra user ID / password combo to remember.

-1 on Active Directory integration; +1 on Kerberos integration that also
works with AD. Please don’t go down the platform-specific road; support the
open standard instead.

Kind regards,

Scott

Scott Courtney | “I don’t mind Microsoft making money. I mind them
scott@4th.com | having a bad operating system.” – Linus Torvalds
http://4th.com/ | (“The Rebel Code,” NY Times, 21 February 1999)
| PGP Public Key at http://4th.com/keys/scott.pubkey

63

Multiple ticket owners and asset tracking (<3 AT)

64

Scott Courtney wrote:

  1. Active Directory interface/native integration - This is a biggie.
    NOBODY want’s / needs an extra user ID / password combo to remember.

-1 on Active Directory integration; +1 on Kerberos integration that also
works with AD. Please don’t go down the platform-specific road; support the
open standard instead.

Perhaps I’m weird, but I don’t want any native authentication in RT.
Authentication is the domain of the web server. I vastly prefer RT to
behave appropriately according to the current web server authentication,
automatically creating new users as they appear, and all
non-authenticated users become anonymous. Of course, RT already
supports this mode of operation, so I’m happy. :sunglasses:

65
> If, for the sake of argument, Best Practical were to rewrite RT, what would you want to see in the new product? > > Think big. >
  • Better reporting
  • Spam!!!
  • PDF Export of Ticket History/Reports
  • Full LDAP Auth/Authz
  • Asterisk Integration :wink:
  • IRC and Jabber :wink:
  • Move to Catalyst :wink:
  • Move to TT :wink:
  • Move to Dojo :wink:

Or something like that…

66

Gavin Henry 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. >
  • Better reporting
  • Spam!!!

So, you want RT to send spam? :wink:

Mathew

67

Simplified customizations. For instance, despite the wiki and everyone saying
that simply adding a new status to RT_Siteconfig.pm or any other location should
create the new, working status in RT, it doesn’t seem to be that easy.

Mathew

Jesse Vincent wrote:

68

Scott Courtney wrote:

  1. Active Directory interface/native integration - This is a biggie.
    NOBODY want’s / needs an extra user ID / password combo to remember.

-1 on Active Directory integration; +1 on Kerberos integration that also
works with AD. Please don’t go down the platform-specific road; support the
open standard instead.

Perhaps I’m weird, but I don’t want any native authentication in RT.
Authentication is the domain of the web server. I vastly prefer RT to behave
appropriately according to the current web server authentication,
automatically creating new users as they appear, and all non-authenticated
users become anonymous. Of course, RT already supports this mode of
operation, so I’m happy. :sunglasses:

Seconded. If RT’s behind apache, there are a number of ways to kerberize
that (against AD if necessary) and RT will pick up the user from that.
Here, we use RT against our standard SSO implementation (which again
calls out to krb/AD behind the scenes).

Group membership integration is more interesting, but I’m reasonably
convinced (in our case at least) that by exposing the group membership
APIs via a remote interface we’ll be able to use our provisioning kit to
keep those synchronised.

jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/
Tel +44 (0)117 3317661 jan's very old home page
Hang on, wasn’t he holding a wooden parrot? No! It was a porcelain owl.

69

RT-Extension-MergeUsers-0.02 - Merges two users into the same effective user - metacpan.org

Ah, thanks, I somehow missed that - I am not sure if it was
announced when people were discussing this a while back. I’ll try it
out. Thanks!

I tried it out, and it does get part of the way.

First off, installation troubles:
I had to modify the test perl script in two ways:
one was to add a use lib “/usr/local/request-tracker/lib/” to get it to be
able to find RT.pm.

And then I had to change the tests, since I don’t have a “general” queue.

But, now it is installed.

I merged user1 to user2.

Sending an email from user1 creates the ticket as requested by user2, very
nice.

However, if I login as user1, I don’t have any tickets assigned.

What would be nifty is if when logging in as user1 or user2, he would
basically end up in the same place, and see all of the same tickets.

70

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.

Having a very strong and complete SQL model (not one hacked up with
arbitrary values for “lack of relation” and such) would make this
much simpler. The DB would handle all the cascading work for you and
all you need to do is delete either the user or the ticket and the
rest of the garbage goes with it.

This would be my number 1 “feature” of RT4: a solid relational
database model in which the DB enforces all data integrity for you.

My number 2 feature would be simplification of the permissions
management interface… right now it slices vertically so you have to
go to each queue and manage users per queue. I’d also like to view
it horizontally and manage queues per user, for example. If
possible, the permissions mechanism should be fixed such that its
representation in SQL would make for an easier way to query it when
computing for example the top ten unowned tickets… right now with
complex setups with multiple queues you sometimes see fewer than 10
tickets since you can’t view all of the top 10 based on your
permissions which are computer too late.

71

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.

Having a very strong and complete SQL model (not one hacked up with
arbitrary values for “lack of relation” and such) would make this
much simpler. The DB would handle all the cascading work for you and
all you need to do is delete either the user or the ticket and the
rest of the garbage goes with it.

This would be my number 1 “feature” of RT4: a solid relational
database model in which the DB enforces all data integrity for you.
It’s also now possible as MySQL has support for triggers, however
I don’t think it’s a good way to go before RT 5.0 :slight_smile:

My number 2 feature would be simplification of the permissions
management interface… right now it slices vertically so you have to
go to each queue and manage users per queue. I’d also like to view
it horizontally and manage queues per user, for example. If
possible, the permissions mechanism should be fixed such that its
representation in SQL would make for an easier way to query it when
computing for example the top ten unowned tickets… right now with
complex setups with multiple queues you sometimes see fewer than 10
tickets since you can’t view all of the top 10 based on your
permissions which are computer too late.
+1 on this

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

Best regards, Ruslan.

72

When creating queues, I want the option to copy a queue (and/or) a queue
template from the configuration GUI.

I also want to be able to setup the MTA configuration from within the
GUI.

I want to be able to manage the database from within RT. (And create
indexes)

I want to be able to obtimise the database from the gui

I want to be able to setup replication from within the GUI.

I want the ability to schedule things from inside the GUI, including
emailing custom reports that I created through the GUI.

Brian Gupta
Time Inc
Information Technology Dept
212-522-1401

73

Hey Jesse,

Thanks for that patch, however it doesn’t quite do what I’m looking for
and I was hoping you could point me in the correct direction here…

With multiple email addresses, we would want the email to go out to the
address that was used to send in the ticket - the scenario that plays
out here is we’ll have a client mail server problem, so their mail is down.

Is it possible to link the accounts to have the same privileges without
changing the email address? Or could I just comment out a few of the
CanonicalizeEmailAddress and get my desired effect?

Thanks,

Robert

Jesse Vincent wrote:

74

Alle 19:31, martedì 8 maggio 2007, Brian_Gupta@timeinc.com ha scritto:

I also want to be able to setup the MTA configuration from within the
GUI.

I think this is not a good idea: in an heavy duty environment, MTAs simply are
on different servers then webinterface.
Also MTAs configuration is a totally separated job, MTAs can get information
from a big plethora of sources: AD/LDAP, SASL, DB, local files…

In a small environment with low traffic and only one poor lerned sysadm, MTA
configuration from webinterface should be a good start point, but it can be
optional and not mandatory, otherwise RT will not be a good choice for large
installation.

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

75

In case you are still collecting … some of my suggestions may already
been stated so apology for duplicates;
1- group unprivileged users (so each member of that group can view the
group tickets)
2- more reports built in, sla related,first response time/active ticket
life (not stalled time etc), with business::hours module integrated.
3- performance:
i- archive (resolved tickets can be pushed into an archive db and
search able from query builder)
ii- Content searching (maybe have an objectId field in the attachment
table and thus avoiding the need to join Transactions)
iii- Fork searching from a replicated db if replication is used
4- REST is good but everybody else work with SOAP, so an integrated
soap interface

Thanks;
Roy

Jesse Vincent wrote:

76

In case you are still collecting … some of my suggestions may already
been stated so apology for duplicates;
1- group unprivileged users (so each member of that group can view the
group tickets)

This one puzzles me. I think others have mentioned it, so
I want to comment.

In RT, “privileged” means “you are allowed to have privileges”,
not that you have any specific ones.

If I have a consultant with various privileges, and I need
to turn off those privileges, I can revoke the “privilege” flag
easily, and the person can still create new tickets as
an unprivileged client.

If you allow unprivleged users to be put into groups,
and give those groups some sort of privilege, then what does
“unprivileged” mean?

What you need to do is make a group “consultants”,
and put your consultants in that. Then you can have
other groups for clients if you want. They clients
would have to be privileged, but they would not have
consultant privileges.

bobg

77

The ability to customize the colors easily from the Configuration menu.

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

Jesse Vincent wrote:

78

Using Nagios as an example.
Its written also in Perl, but there’s a Java port which basically eliminates
the installation completely.
Download a bunch JARs and fire up Java.
If there was a port of RT in Java - this would do wonders for the adoption
rate.
Many big corporation don’t allow open source stuff and Perl-based software
in particular…From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Mathew Snyder
Sent: Friday, May 18, 2007 2:20 AM
To: Jesse Vincent
Cc: RT Users
Subject: Re: [rt-users] RT 4

The ability to customize the colors easily from the Configuration menu.

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

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
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

79

Using Nagios as an example.
Its written also in Perl, but there’s a Java port which basically eliminates
the installation completely.
Download a bunch JARs and fire up Java.
If there was a port of RT in Java - this would do wonders for the adoption
rate.
Many big corporation don’t allow open source stuff and Perl-based software
in particular…

That makes my head spin!

Are you saying the installation is a turnoff, regardless of language?
If so, there are alternatives to java, such as a VM image.
Or, like WebGUI (a CMS I’m playing with), you can download
a full runtime, including apache, mysql, and perl itself,
so there isn’t the usuall “installation”.

Are you saying it must be java, just because of “policy”?
That the shop knows java, doesn’t know perl, and won’t
install anything but java?

Are you saying bigcos don’t like things writting in perl
because perl is open source? Even if the app is not open?
Even though RT is open in the way I care about, it is closed
in the sense that changes in the official distribution are
vetted by a company. Besides, what now that java is being open-sourced?

I’m not that familiar with nagios. Do the jars include a database
and web server? Also, how do they ensure that the perl and java
versions actually work the same?

bobg

80

Whoa, take it easy…
All I’m saying, and this is coming from personal experience trying to bring
RT into my workplace, it is very difficult to introduce this type of
software (no matter how good it is) into a huge company.
When our security group hears about Perl or sendmail or MySQL - you can
pretty much kiss your software goodbye.

Now, the reason I took Java as an example is because while it is (almost)
open source - it is also installed on every UNIX box.
There’s no reason to have GCC and other supporting software in order to
install the software you want.

Also, with Java 1.5 - there’s an ability to have embedded DB.

It may very well be a VM image. I’ve playing with a monitoring solution
called Zenoss which gives you a VM image that you can fire up in 20 minutes
and have a complete working solution.

In any event, in my company it is VERY difficult to bring RT in through the
official channels precisely because of the install process.

Sal.From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Bob Goldstein
Sent: Friday, May 18, 2007 9:57 AM
To: RT Users
Subject: Re: [rt-users] RT 4

Using Nagios as an example.
Its written also in Perl, but there’s a Java port which basically
eliminates the installation completely.
Download a bunch JARs and fire up Java.
If there was a port of RT in Java - this would do wonders for the
adoption rate.
Many big corporation don’t allow open source stuff and Perl-based
software in particular…

That makes my head spin!

Are you saying the installation is a turnoff, regardless of language?
If so, there are alternatives to java, such as a VM image.
Or, like WebGUI (a CMS I’m playing with), you can download a full runtime,
including apache, mysql, and perl itself, so there isn’t the usuall
“installation”.

Are you saying it must be java, just because of “policy”?
That the shop knows java, doesn’t know perl, and won’t install anything but
java?

Are you saying bigcos don’t like things writting in perl because perl is
open source? Even if the app is not open?
Even though RT is open in the way I care about, it is closed in the sense
that changes in the official distribution are
vetted by a company. Besides, what now that java is being open-sourced?

I’m not that familiar with nagios. Do the jars include a database and web
server? Also, how do they ensure that the perl and java versions actually
work the same?

bobg
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