Rt 4

RT Users
1

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

PGP.sig (186 Bytes)

2

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

Include AT or write your own asset tracking module which does the same
thing as AT does.

include network interface so that RT/AT databases can be inquired from
external machines.

Tom

3

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

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

Justin Zygmont
System and Network Administrator
Cityfone Telecommunications Inc

604.629.8841
justin at cityfone dot net

4

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

  • Multiple Ticket Owners.

  • Sub-selections in Custom Field input. Eg) Choose a Department, you
    can
    then only select certain other fields based on that choice.

  • Mandatory fields. Custom fields are weak on this currently, I can set
    something to mandatory but RT ignores it.
    Time Worked not being filled in on ticket resolve is an issue we are
    having here. A tick box per queue making it mandatory would be nice.

  • Resolved Tickets not springing open when someone replies saying
    “thanks”.

  • HTML in Templates so we can highlight parts of a reply better.

  • Reminder system that sends out Emails to remind owners and provides
    a summary to managers showing what tickets are over due.

  • LDAP/ActiveDirectory native support, particularly Groups.

  • Import of Custom Fields from text file list. (cut and pasting from
    excel is soo much fun)

  • A way copy a Queues setup from one system to another eg) our Dev
    system to our Production System.

  • Backup, Restore, Clustering - Enterprise level stuff built in would
    help ‘sell’ RT to larger organizations of the size that will pay
    for support.

Thanks,
Scott

5

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.

The ability to set the complexity of the interface, based on the group
of the logged-in user. Think Google’s default interface (for front-line
tech support) vs their “advanced query page” (for 2nd/3rd tier support).

We tried to get another group using RT but were rebuffed with “that’s
too complex for our CSRs.”

Graham

6

I’d like to see the following:

  1. Better Documentation and resources for the product (current methods
    are cumbersome and slow ie. List Archives or the Wiki)
  2. Ruby on rails would be great… but as your PERL guys I assume
    unrealistic. Really a complete SOA architecture would be fantastic
  3. More complexity around Custom Fields, current model is very
    cumbersome
  4. Have every function and feature exported into a fully functional API
    layer
  5. Ability for RT to natively sync data between multiple RT instances
    (Enterprise feature set)
  6. A robust change management interface that follows ITIL standards
  7. Way to track SLA’s based on Response and remedy commitments
  8. Ability to do more site maintenance tasks in the GUI, DB backups, RTx
    Extensions, Simple Branding, etc.
  9. Reporting layer utilizing the Jasper Framework-----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

7

  1. Rights
    1a. Display Rights that are inherited with grayed-out boxes. For
    instance, if Global Everyone has SeeQueue, then have SeeQueue show with a
    grayed-out box already present in Queue Everyone. This will make it easy
    to see effective rights and explicit rights at all levels.
    1b. Have negative Rights (Denies?). For instance, it would be nice to
    enable ModifyTicket for Global Requestors, but take it away for Requestors
    in a specific queue.

  2. Templates
    2a. Within a template, have pulldown menus for selecting the To, Cc, and
    Bcc recipients. For instance, in my template I can choose to send to
    requestors and user-defined, and cc admincc and user-defined. User-defined
    could be implemented similar to “my @ToAddresses = @{$self->ToAddresses}”
    and “$self->ToAddresses->Add(‘me@myaddress.com’)”.

  3. Queues
    3a. Let me define queue-wide variables that I can access in any template
    or scrip. For instance, if my “UhOhBigProblems” address is
    “bigprobs@mycompany.com” I’d like to be able to set it once in the Queue
    and then access it as something like $self->Queue->QV{“UhOhBigProblems”} in
    any of my scrips or templates. Changing the address would then be as easy
    as making a single change at the queue level rather than a bunch of changes
    at the scrip and template level. This would be a wonderful thing to have
    when developing new systems (while testing, the ITSO address is my address,
    for production I change it to a group address).

  4. Custom Fields
    4a. Allow me to have custom fields that are hidden in the ticket. I would
    use these for process flow-control or just to store info that no one really
    needs to see displayed in a ticket. Basically a way to implement a
    ticket-specific queue-wide global variable (different for each ticket, but
    accessible by all scrips and templates in this queue)…
    4b. Allow for custom fields to be defined at the queue level instead of
    having to choose global custom fields to use in the queue.

  5. Scrip execution
    5a. Make it easy (or easier) to determine the order in which scrips are
    executed, transactions are generated, templates are run. For instance, I
    have a scrip that does a $self->TicketObj->SetOwner and
    $self->TicketObj->SetPriority. I would like to know that the resulting
    transactions will not be triggered until everything associated with this
    scrip is complete.

Thanks for asking!

At 10:54 AM 5/1/2007, 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

Gene LeDuc, GSEC
Security Analyst
San Diego State University

8

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

First thing that comes to mind:

Remove embedded code in HTML and use a templating system or equivalent
to make an MVC-compliant app.

Regards,

– Raju
Raj Mathur raju@kandalaya.org http://kandalaya.org/
GPG: 78D4 FC67 367F 40E2 0DD5 0FEF C968 D0EF CC68 D17F
It is the mind that moves

9
  1. Queues
    3a. Let me define queue-wide variables that I can access in any template
    or scrip. For instance, if my “UhOhBigProblems” address is
    […]
  2. Custom Fields
    4a. Allow me to have custom fields that are hidden in the ticket. I would
    use these for process flow-control or just to store info that no one really

If I understand your needs, for those 2 you can perhaps use RT::Attribute.

10

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

  1. Full functional API, both local and network accessible.
    I have in mind integrating RT with other apps, possibly
    point-to-point, or with some SOA/message bus. This could
    mean RT-to-RT sync, account provisioning-to-RT, RT-to-other helpdesk,
    extra funtionalities like AT, and so on.

    Do I remember correctly that some RT-ness (like checks for privilege)
    take place in the mason components? If so, that should be moved
    to the perl modules, so that the API would contain all this goodness.
    In particular, it should be possible to write an entirely new
    UI, at whatever complexity the author wishes, and have it safely
    interoperate with the official RT UI on the same RT instance.

  2. Better development docs. Maybe I just want the API above to be
    well documented, I’m not sure. But I want to understand the code
    architecture and data model at something higher than the subroutine
    or file level, and lower than the UI.

  3. Other features could be built on top, by you or others. Ad hoc reports,
    adjustment of cron jobs from the UI (e.g. send mail to ticket owners
    if the consultant hasn’t responded in 2 days, …), project tracking
    (maybe integrate RT into Trac), more formal change management,
    calendar integration (an RT ticket might be linked to, or create,
    a meeting on a calendar, or sync RT todo list with a calendar/pda).

    bobg

11
  1. Better docs
  2. Better API (we want to integrate with our Vtiger system)
  3. Better security
  4. Expanded external authentication

We use multiple systems and use a single SQL database for authentication of
usernames and passwords

Mark Fuller

BandTel Engineering

12

Even though it’s not necessarily things that should be added into RT
itself, these are things that we’ve wanted to see in regards to RT.

A way to keep track of daily/weekly recurring tasks integrated into RT
would be nice. Assign task X to group Y. Anyone in group Y can
update/complete the task. Every $recurrence days
(Daily/Weekly/Mon,Wed,Fri/etc) a new instance of the task shows up,
automatically. Basically part of Hiveminder within RT. So far, this is
the only thing preventing us from completely getting rid of our old help
desk application, since we haven’t really been able to find a
replacement that just “feels right”.

The ability to send out “random” (for definable values of “random”)
feedback surveys that include ticket history/number, and definable
questions for the requestors of a ticket to fill out. Having the filled
out surveys linked directly within the ticket details, and from
searches, but only to “managers”, and other key people. Stats about
number of surveys sent out vs number completed, and time to completion
Would Be Nice™. We have started working on this using custom fields,
custom field permissions, and external an CGI/database, but having it
more tightly integrated into RT would be nice.

Integrating some of the excellent add-ons that others have created would
be another nice thing. RTx-Calendar, RTx-EmailCompletion, and
jscalendar for example.

The only other things that we really wanted to see added, we’ve been
able to add on our own, so far: Soft closing tickets (ticket actually
closes after X days in “pending” status), tracking items sent out in
regards to tickets, weekly reports of items sent out.

Jacob Helwig
PC Technician
Busch’s Help Desk
Desk: x35221
Direct: 734-214-8221-----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 1:55 PM
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

13

[ I’m not generally going to be trying to address folks’ suggestions,
but wanted to set one fact straight here]On May 1, 2007, at 3:58 PM, Bob Goldstein wrote:

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

Do I remember correctly that some RT-ness (like checks for
privilege)
take place in the mason components?

No, that is not the case. Any access control checks done in the UI
layer are done so as to not present people with UI for things they
can’t do.

PGP.sig (186 Bytes)

14

  • A “duplicate” option, usefull when people complains/ask for lots of things
    in a single ticket)

  • A tool to “undo” merge

  • the abilities of RTIR to emphasize IPs and domains, or embedded RTIR without
    default queues and scripts

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

15

I’d like to see the following:

  1. Better Documentation and resources for the product (current methods
    are cumbersome and slow ie. List Archives or the Wiki)
  2. Ruby on rails would be great…
 Just curious, why ror.  I would be that RT4 would be written 
 using Jifty.

but as your PERL guys I assume
unrealistic. Really a complete SOA architecture would be fantastic
3. More complexity around Custom Fields, current model is very
cumbersome
4. Have every function and feature exported into a fully functional API
layer
5. Ability for RT to natively sync data between multiple RT instances
(Enterprise feature set)
6. A robust change management interface that follows ITIL standards
7. Way to track SLA’s based on Response and remedy commitments
8. Ability to do more site maintenance tasks in the GUI, DB backups, RTx
Extensions, Simple Branding, etc.
9. Reporting layer utilizing the Jasper Framework

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

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

Scott T. Hildreth shildret@scotth.emsphone.com

16

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

Since time is money it would be nice if the Time(Estimated,Left,Worked)
functionality could be factored out so the
equivalent money items could be tracked.

Jeff Voskamp

17

I would like to see fully customizable ajax validation for both custom
fields and all other fields. See link Below for example.

http://tetlaw.id.au/upload/dev/validation/

James P. White III
Enterprise Site Engineering / CDC1
Phone: 302.669.4473
james.p.white@jpmchase.com
CDC1 On-Call Pager: 877-467-8552
Peregrine Queue: X1DCOUSBEAR

rt-users-bounces@lists.bestpractical.com wrote on 05/01/2007 01:54:43 PM:

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
[attachment “PGP.sig” deleted by James P White/DE/ONE]

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

This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of
any financial instrument or as an official confirmation of any
transaction. All market prices, data and other information are not
warranted as to completeness or accuracy and are subject to change
without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
and affiliates.

This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase &
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.

Please refer to Disclosures for
disclosures relating to UK legal entities.

18

Thanks, Nicolas. I’ll see what I can find in RT::Attributes.

At 12:56 PM 5/1/2007, Nicolas Chuche wrote:

  1. Queues
    3a. Let me define queue-wide variables that I can access in any template
    or scrip. For instance, if my “UhOhBigProblems” address is
    […]
  2. Custom Fields
    4a. Allow me to have custom fields that are hidden in the ticket. I would
    use these for process flow-control or just to store info that no one really

If I understand your needs, for those 2 you can perhaps use RT::Attribute.

Gene LeDuc, GSEC
Security Analyst
San Diego State University

19

A dynamic interface which didn’t require a page refresh for every click.
Something along the lines of AJAX.

Mathew

Jesse Vincent wrote:

20

Thanks for asking Jesse,

My number 1 desire would be: Ability to group Unprivileged Users.

That is, allow Unpriv users to be grouped per Company or even a sub-set
Company-Department, such that all correspondence on tickets can be viewed
by members of the same Company or Company-Department. When RT is
currently used to service external customers, it requires a bodge to
insert other unpriv users of the same company as a Cc. RT needs a way to
group Unpriv users to form Company or Company-Department sets and that
users can then opt-in or opt-out of receiving all tickets associated with
their company or company-department.

Hope that makes sense.

BenR

Jesse Vincent jesse@bestpractical.com
Sent by: rt-users-bounces@lists.bestpractical.com
02/05/2007 03:54 AM

To
RT Users rt-users@lists.bestpractical.com
cc

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

PGP.sig (193 Bytes)