[rt-users] RT 4

[Gene LeDuc]

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 at 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 at 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
>
>
>
>_______________________________________________
>http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>
>Community help: http://wiki.bestpractical.com
>Commercial support: sales at 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