Multiple ticket owners and asset tracking (3 AT)
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials
Scott Courtney wrote:
3. 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
quote who=Jesse Vincent
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 ;-)
* IRC and Jabber ;-)
* Move
Gavin Henry wrote:
quote who=Jesse Vincent
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? ;)
Mathew
* PDF Export of Ticket History/Reports
* Full
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:
If, for the sake of argument, Best
What about the ability to have different ticket numbering systems per
queue, for example:
* The number for the RMA queue can have the "RMA" prefix, and then the
year followed by the ticket number: "RMA-07-020".
* Service queue for a specific customer may be different.
Luis
Jesse Vincent
On Wed, 2007-05-02 at 10:29 -0400, Jon Daley wrote:
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
On May 3, 2007, at 6:45 PM, Dale Bewley wrote:
On Wed, 2007-05-02 at 10:29 -0400, Jon Daley wrote:
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
On Thu, 3 May 2007, Jesse Vincent wrote:
On May 3, 2007, at 6:45 PM, Dale Bewley wrote:
On Wed, 2007-05-02 at 10:29 -0400, Jon Daley wrote:
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
.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 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
On Tue, 1 May 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?
Keep the decent layered architecture.
(Obviously) a _complete_ REST or other remote api. (I like the
simplicity of the REST model.)
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 VillaniMobile Team,
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:
If, for the sake of argument, Best
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
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
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.
1.
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
Thank you for asking Jesse,
As Sven Sternberger just asked for, we would appreciate an embedded statistics
module. Currently, this is only available as a
contribution - which works with some bugs, and it does not seem to be
maintained anyway - and we are about to use it intensely for
auditing
On Tue, 1 May 2007 13:54:43 -0400
Jesse Vincent [EMAIL PROTECTED] 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
Since my org. has only been using RT for 1yr I was going to keep my
mouth shut, and
] On Behalf Of Kevin Squire
Sent: Wednesday, May 02, 2007 12:27 PM
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] RT 4
On Tue, 1 May 2007 13:54:43 -0400
Jesse Vincent [EMAIL PROTECTED] wrote:
If, for the sake of argument, Best Practical were to rewrite RT, what
would you want to see
On Wed, 02 May 2007 13:34:47 -0500
Carlos Ramon Lopez Midence [EMAIL PROTECTED] wrote:
- The one thing that we have come across that we don't seem to find a
way to do it, it is searching in custom fields for ticket
transactions, specifically in resolving a ticket. We use these custom
fields
-Original Message-
If, for the sake of argument, Best Practical were to rewrite RT,
what
would you want to see in the new product?
Think big.
snip
I would also like to put a vote AGAINST ajax like improvements. I
like
the simplicity, and with the simplicity, the choices.
On Tue, 1 May 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?
1. An easy migration path for version 3 installs with custom code.
2. Ability to store one ticket in multiple queues.
3. Ability to add
On Tue, 1 May 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?
Include AT or write your own asset tracking module which does the same
thing as AT does.
include network interface so that RT/AT
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
___
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
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.
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
On Tuesday 01 May 2007 23:24, 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?
First thing that comes to mind:
Remove embedded code in HTML and use a templating system or equivalent
to make an MVC-compliant
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
[...]
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
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
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
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
[ 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
Em Terça 01 Maio 2007 15:05, Tomasz Wlodek escreveu:
- 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
--
On Tue, 2007-05-01 at 12:18 -0700, Justin Brodley wrote:
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
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
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
Thanks, Nicolas. I'll see what I can find in RT::Attributes.
At 12:56 PM 5/1/2007, Nicolas Chuche wrote:
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
[...]
4. Custom Fields
4a. Allow me to
A dynamic interface which didn't require a page refresh for every click.
Something along the lines of AJAX.
Mathew
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
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.
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
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
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.
5) Ability to print a
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
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
RSS already exists in 3.6
Mathew
Keep up with me and what I'm up to: http://theillien.blogspot.com
Pedro Santa wrote:
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
101 - 147 of 147 matches
Mail list logo
