Re: [rt-users] Avoiding backscatter & enabling self help

[Kurt Zeilenga]

Thanks for you comments, they got me thinking a deeper into our problem.

On Apr 1, 2011, at 9:28 PM, Odhiambo Washington wrote:

> 
> 
> On Sat, Apr 2, 2011 at 05:06, Kurt Zeilenga  wrote:
> We've been experimenting with RT this week at OpenLDAP.org for servicing 
> various "help" and "contact" by email services... i...@opendlap.org, 
> webmas...@openldap.org, etc.   We have a general policy here at OpenLDAP.org 
> to avoid email auto-responders, so as not to contribute to the backscatter 
> problem.  But we also like "self help" services.
> 
> We presently have the 'On Create Autoreply To Requestors' scrip disabled.
> 
> I see there is a suggestion in the Wiki article 
>  for generating 
> passwords on first create (from email) from the user, and including this in 
> the autoreply on create message.  I'm wondering if I might apply this patch 
> to the response ticket so that on response to a user without a password will 
> cause a password to be generated.  That would provide some "self help" 
> opportunities to the user.  Any thoughts on how best to do this?
> 
> For all other possible emails to the requestor, never send if the password 
> hasn't ever been set.  Any thoughts on how to accomplish this?
> 
> Without even reading the Wiki, what I recall off the top of my head is that 
> you need to replace the default Autoreply Template with the one  from the 
> Wiki. After that, you need to enable the scrip you disabled. This will have 
> your desired action.

Unfortunately that's not an option for us as it would cause us to generate 
backscatter.

I note that preventing backscatter, especially backscatter to those we have no 
relationship with, is more importance to us than enabling self help.

> Again, what we want is to never send an email to a requestor without a human 
> generating a correspondence to that requestor (and hence setting up their 
> password).  Until then, we want to assume the email had a forged from 
> address.  Am I on the right track above?  or is there a better way to setup 
> RT to behave in this manner?
> 
> In that case, I believe you want full human intervention on creating users 
> and assigning them passwords. In that case, there is no need for using a 
> scrip. That is not the way I know RT to work.

The problem here is the number of steps.  We really don't want to have the 
owner doing anything more than they normally would do, just respond to the 
ticket they just took.

> "Until then, we want to assume the email had a forged from address" - makes 
> me wonder how the human will verify that the e-mail address is legit.

Well, the human is not really checking the email address but the ticket as a 
whole.  If the ticket doesn't look legit, then it our assumption that the 
requestor is not legit for this ticket.  We expect our ticket handlers to use 
the 'Report Spam' extension to mark it as Spam.

Now if the ticket is legit, we then respond to it.

I was initially think not to send any automated mail to a requestor without a 
password until a human has manually responded.  But now I'm thinking it would 
be even better to generally not send any automated mail to requestor/CCs until 
a human a human has manually responded.

This could be implemented, I'm thinking, using flag on the ticket, which would 
be false until responded to by a human, to enable/disable automated email to 
the requestor/CCs.

> I think what you need is a "customized registration" page somewhere, which 
> uses captcha, submits the details to a custom script that then injects the 
> details into RT and generates a response to the registrant with their 
> password, and details on how to track their request via your RT.

We're using RT to handle events we expect to be initiated via email.  We have 
no expectation that the requestor would attempt to look at the website before 
submitting their initial email.  The first email they'll get from us will be 
the manually generated ticket in response to their initial email.  Our initial 
correspondence seems like the appropriate place to include any web access 
information, including providing any necessary credentials.

> 
> 
> 
> -- 
> Best regards,
> Odhiambo WASHINGTON,
> Nairobi,KE
> +254733744121/+254722743223
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> Damn!!
> 

Re: [rt-users] Avoiding backscatter & enabling self help

[Odhiambo Washington]

On Sat, Apr 2, 2011 at 05:06, Kurt Zeilenga  wrote:

> We've been experimenting with RT this week at OpenLDAP.org for servicing
> various "help" and "contact" by email services... i...@opendlap.org,
> webmas...@openldap.org, etc.   We have a general policy here at
> OpenLDAP.org to avoid email auto-responders, so as not to contribute to the
> backscatter problem.  But we also like "self help" services.
>
> We presently have the 'On Create Autoreply To Requestors' scrip disabled.
>
> I see there is a suggestion in the Wiki article <
> http://requesttracker.wikia.com/wiki/AutogeneratedPassword> for generating
> passwords on first create (from email) from the user, and including this in
> the autoreply on create message.  I'm wondering if I might apply this patch
> to the response ticket so that on response to a user without a password will
> cause a password to be generated.  That would provide some "self help"
> opportunities to the user.  Any thoughts on how best to do this?
>
> For all other possible emails to the requestor, never send if the password
> hasn't ever been set.  Any thoughts on how to accomplish this?
>

Without even reading the Wiki, what I recall off the top of my head is that
you need to replace the default Autoreply Template with the one  from the
Wiki. After that, you need to enable the scrip you disabled. This will have
your desired action.

Again, what we want is to never send an email to a requestor without a human
> generating a correspondence to that requestor (and hence setting up their
> password).  Until then, we want to assume the email had a forged from
> address.  Am I on the right track above?  or is there a better way to setup
> RT to behave in this manner?
>
> In that case, I believe you want full human intervention on creating users
and assigning them passwords. In that case, there is no need for using a
scrip. That is not the way I know RT to work. "Until then, we want to assume
the email had a forged from address" - makes me wonder how the human will
verify that the e-mail address is legit. Perhaps you need some custom
condition that will send out a mail to the address, with a url with captcha,
let the recipient follow the captcha... scratch that. I think what you need
is a "customized registration" page somewhere, which uses captcha, submits
the details to a custom script that then injects the details into RT and
generates a response to the registrant with their password, and details on
how to track their request via your RT.



-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254733744121/+254722743223
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Damn!!

[rt-users] Avoiding backscatter & enabling self help

[Kurt Zeilenga]

We've been experimenting with RT this week at OpenLDAP.org for servicing 
various "help" and "contact" by email services... i...@opendlap.org, 
webmas...@openldap.org, etc.   We have a general policy here at OpenLDAP.org to 
avoid email auto-responders, so as not to contribute to the backscatter 
problem.  But we also like "self help" services.

We presently have the 'On Create Autoreply To Requestors' scrip disabled.

I see there is a suggestion in the Wiki article 
 for generating 
passwords on first create (from email) from the user, and including this in the 
autoreply on create message.  I'm wondering if I might apply this patch to the 
response ticket so that on response to a user without a password will cause a 
password to be generated.  That would provide some "self help" opportunities to 
the user.  Any thoughts on how best to do this?

For all other possible emails to the requestor, never send if the password 
hasn't ever been set.  Any thoughts on how to accomplish this?

Again, what we want is to never send an email to a requestor without a human 
generating a correspondence to that requestor (and hence setting up their 
password).  Until then, we want to assume the email had a forged from address.  
Am I on the right track above?  or is there a better way to setup RT to behave 
in this manner?

FYI, I'm using RT 3.8.9 on FreeBSD 7-stable.

-- Kurt

Re: [rt-users] QuickSearch has broken links for some users

[Adam Bernstein]

Sorry to resurrect an old thread, but did Ed make any progress on this? 
 Because we're having the same trouble, after changing the URL at which 
RT is addressed on our system: We have three users, and one of us sees 
everything fine, while the other two see the old URL appearing in ticket 
links under the QuickSearch listings (and only there).


The only difference we've been able to find so far in the database is 
that the two affected users were initially auto-created upon ticket 
creation (many years, many tickets, and many RT versions ago), while the 
other was not.  New users are not affected.  But none of us have any 
custom Search Options configured in the location referred to by Kevin 
below -- we've never touched those things, never gotten to that level of 
RT-fu.


This is RT 3.8.8.  Any help greatly appreciated.

adam

On Tue, Feb 16, 2010 at 11:51:31AM -0500, Ed Santora wrote:
> Hello,
>
> I recently moved our RT instance from a base hostname to a subdirectory
> (i.e. from http://www.example.com/ to http://www.example.com/rt/)
>
> Myself and a few users have updated our SavedSearches to account for that
> change and it works fine. As does almost everything else. However, 
for some

> users, when they click the Queue link from the QuickSearch box all the
> tickets displayed have links without the ending "/rt".
>
> This was a fresh install of the files, Mason cache has been cleared 
and the

> web server restarted. Only the database was carried over.
>
> This behavior is only seen with a handful of users. I am unable to figure
> out why the links are correct for some users and not others. Any ideas on
> where to start looking for the cause?

Check if these users have a custom Format under Preferences -> Search
options with id or Name and an invalid Link item

-kevin

Re: [rt-users] How do I submit a ticket in behalf of a user?

[Don Gourley]

If the user's email isn't found, a user is created.  I have a custom
template used for the OnCreate AutoReply to Requestors scrip which
sets the username and real name based on the format that I know our
users' emails has. This works when a user first submits a ticket via
email, but doesn't work if I submit a ticket on behalf of the user. It
appears that the condition for no password and not priviliged is not
true.

Is there a way for me to identify when a new user is created when a
ticket is submitted on a user's behalf by putting their email in the
requestor field?

thanks, Don

> Message: 1
> Date: Thu, 31 Mar 2011 22:25:08 -0400
> From: Thomas Sibley 
> To: rt-users@lists.bestpractical.com
> Subject: Re: [rt-users] How do I submit a ticket in behalf of a user?
> Message-ID: <4d953784.5010...@bestpractical.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 31 Mar 2011 22:08, Rocel M. Lacida wrote:
>> Hello All,
>> Good Day!
>>
>> It's my first to post a mail to the mailing list so  bear with me. First
>> I am previous user of other ticketing system (Accord Trellis) and I have
>> many problems about it and upon searching on the net about  what is best
>> ticketing system out there I found RT and it really meet my
>> requirements. Been using RT for only a couple of weeks and honestly it
>> was awesome. Though I stumble some difficulties at first it was solve
>> upon searching on the web where lots of solutions are provided. Now the
>> only hindrance right now is this,Sorry  to ask this question though I
>> think there is an easy to answer for this I just don't know where to
>> find it. In my prevoius ticketing system there is a functionality that
>> someone can post a ticket in behalf of that user.Where I can find it on
>> RT? Is there any equivalent functionality that I could duplicate? Hope
>> you could help me about this. Sorry for the long introduction.
>
> Glad to hear you're enjoying RT.  To create a ticket on behalf of a
> user, just put their email address in the Requestor field when creating
> a ticket via the web.
>
> Cheers,
> Thomas
>
>>
>> Regards,
>> Rocel

Re: [rt-users] Create tickets on mails without creating a real user record.

[Kevin Falcone]

On Fri, Apr 01, 2011 at 11:12:13PM +0200, Jan Hugo Prins wrote:
> On 04/01/2011 04:05 PM, Kevin Falcone wrote:
> > RT creates a user record for any email address associated with a
> > ticket.  That is a fundamental part of how RT works.
> >
> > Why are you concerned about this?
> Well, it's not that I'm concerned about it, but we were wandering about
> this during our tests on how to get RT working with creating new
> external users, while also allowing users authenticate that have a LDAP
> account. This doesn't seem to work the way it is supposed to work, at

You've not said how you're doing your LDAP at all, or provided config
details, so it is hard to comment.

> least not yet, and then we thought, can we accept tickets without
> creating the account. Besides that, when your RT installation starts
> receiving spam mail, then you can end up with an enormous user database,
> so allowing external users to autocreate an account is not really an
> option I think.

Users can often end up being a large table, but that isn't generally a
problem provided you're not granting large bunches of rights to
Unprivileged or giving folks passwords automatically.

I routinely deal with 500K users tables without real issues.

-kevin


pgpbPE6RCbJN4.pgp
Description: PGP signature

Re: [rt-users] Create tickets on mails without creating a real user record.

[Kenneth Marshall]

On Fri, Apr 01, 2011 at 11:12:13PM +0200, Jan Hugo Prins wrote:
> On 04/01/2011 04:05 PM, Kevin Falcone wrote:
> > RT creates a user record for any email address associated with a
> > ticket.  That is a fundamental part of how RT works.
> >
> > Why are you concerned about this?
> Well, it's not that I'm concerned about it, but we were wandering about
> this during our tests on how to get RT working with creating new
> external users, while also allowing users authenticate that have a LDAP
> account. This doesn't seem to work the way it is supposed to work, at
> least not yet, and then we thought, can we accept tickets without
> creating the account. Besides that, when your RT installation starts
> receiving spam mail, then you can end up with an enormous user database,
> so allowing external users to autocreate an account is not really an
> option I think.
> 
> Jan Hugo
> 

Putting a reasonable SPAM filter in front of RT greatly minimizes
this problem. We pass all non-authenticated (remote) users through
DSPAM and let the quarantine catch the spam. Authenticated mail
senders zoom right in.

Cheers,
Ken
> 

Re: [rt-users] Create tickets on mails without creating a real user record.

[Jan Hugo Prins]

On 04/01/2011 04:05 PM, Kevin Falcone wrote:
> RT creates a user record for any email address associated with a
> ticket.  That is a fundamental part of how RT works.
>
> Why are you concerned about this?
Well, it's not that I'm concerned about it, but we were wandering about
this during our tests on how to get RT working with creating new
external users, while also allowing users authenticate that have a LDAP
account. This doesn't seem to work the way it is supposed to work, at
least not yet, and then we thought, can we accept tickets without
creating the account. Besides that, when your RT installation starts
receiving spam mail, then you can end up with an enormous user database,
so allowing external users to autocreate an account is not really an
option I think.

Jan Hugo

Re: [rt-users] RT 3.8.8 no attachments over 1mb

[Ruslan Zakirov]

Read FAQ on the wiki.
http://requesttracker.wikia.com/wiki/FAQ#Attachments

On Sat, Apr 2, 2011 at 12:16 AM, Lee, Jeffrey  wrote:
> Hi all,
>
>
>
> I have an instance of 3.8.8 running and any attachment over 1mb does not
> seem to show up in any of the tickets.
>
>
>
> Any advice would be greatly appreciated.
>
>
>
> Best,
>
>
>
> Jeff



-- 
Best regards, Ruslan.

[rt-users] RT 3.8.8 no attachments over 1mb

[Lee, Jeffrey]

Hi all,

I have an instance of 3.8.8 running and any attachment over 1mb does not seem 
to show up in any of the tickets.

Any advice would be greatly appreciated.

Best,

Jeff

Re: [rt-users] recurring requests

[Roedel, Mark]

Well, that's a bit simpler than the script (which, as I said, was already 
pretty simple) - but at least the way we operate it's still an admin task.  
What I'm dreaming of is an addition to the web UI, similar to the dashboard 
subscription interface, that would allow an RT user to configure the scheduling 
info and some basic ticket data.  Guess that's something to add to my 
ever-expanding list of things to work on...



From: Raed El-Hames [mailto:raed.el-ha...@daisygroupplc.com]
Sent: Friday, April 01, 2011 4:19 AM
To: Roedel, Mark; rt-us...@bestpractical.com
Subject: RE: recurring requests

Mark:

Have a look at rt-crontool , I think it may help you.

Roy

From: rt-users-boun...@lists.bestpractical.com 
[mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of Roedel, Mark
Sent: 31 March 2011 21:45
To: rt-us...@bestpractical.com
Subject: [rt-users] recurring requests

Obviously it's pretty simple to write a script against the REST API and launch 
it from a cron job, but has anybody done anything that's more end-user facing 
to allow for the setup of recurring tickets for periodic maintenance and the 
like?

Re: [rt-users] How to add additional e-mail address

[Kenneth Crocker]

Adrian,

I'm not real clear on what it is you're asking; do you want RT to
automatically send a "Cc" to someone? Do you want your original email to RT
to be copied to someone?

If the first is true, RT will send a copy to anyone listed as a "Cc Watcher"
for the Queue, provided you have a notification scrip to do so. OR, you can
configure RT to automatically add any "Cc" from an incoming email to be a
"Cc" on the ticket that is created, OR you can write a scrip to that on a
Queue by Queue basis (we did the last).

Kenn
LBNL

On Fri, Apr 1, 2011 at 2:46 AM, Adrian Stel  wrote:

> Hi All,
>
>
>
> how to add additional e-mail address, when I submitt ticket
> notification are sent only to private e-mail address I would like to
> send copy this e-mail to another address.
>
>
>
>
>
> --
> Best Regards
> Adrian Stelmaszyk
>

[rt-users] Running into problem upgrading 3.6.0 -> 3.8.9

[Lois Bennett]

Hello,

I am upgrading and moving RT to a new Linux server form an old Solaris
server  and I am running into a problem with moving the database.
The  UPGRADING.mysql document says to:  " Backup RT's database. Use
--default-character-set=binary if mysql server is 4.1 or newer. Test
that you can restore from this backup."

old mysql --version
mysql  Ver 14.7 Distrib 4.1.20, for sun-solaris2.9 (sparc) using readline 5.1
new mysql  --version
mysql  Ver 14.12 Distrib 5.0.81, for unknown-linux-gnu (x86_64) using
readline 5.2

But it fails when I attempt to restore the database on the new server.
 It was able to restore the  dump I made without the
--default-character-set=binary option.

The error I get  in trying to restore the database on the new server is:
root # mysql -p < /var/tmp/rt3.sql
Enter password:
PAGER set to stdout
PAGER set to stdout
PAGER set to stdout
PAGER set to stdout
PAGER set to stdout
PAGER set to stdout
PAGER set to stdout
PAGER set to stdout
PAGER set to stdout
ERROR 1064 (42000) at line 395: You have an error in your SQL syntax;
check the manual that corresponds to your MySQL server version for the
right syntax to use near 's Office). I was wondering if Jacques or>
someone could come down and help me se' at line 1

This appears to be in the section  of the dump of the Attachments.

So do I need to use the -default-character-set=binary option?  Maybe I
need to dump some tables separately?

Thanks for  any help you can provide.

Peace,
Lois


-- 
Lois Bennett, MSEE
Senior System Administrator
Channing Laboratory
Brigham & Women's Hospital
A Teaching Affiliate of
Harvard Medical School and
Harvard School of Public Health

Re: [rt-users] Create tickets on mails without creating a real user record.

[Kevin Falcone]

On Fri, Apr 01, 2011 at 04:03:15PM +0200, Jan Hugo Prins wrote:
> I have a question. We are trying to setup RT for our business and it is
> progressing rather good, except for one thing.
> 
> When someone outside or our support organisation send a mail to the noc
> helpdesk address I want the RT system to create a ticket, registering
> the email adres and the name of this user in the ticket and put the
> ticket in some incoming queue. For the rest, I don't want to create a
> user for this ticket. Is this possible?

RT creates a user record for any email address associated with a
ticket.  That is a fundamental part of how RT works.

Why are you concerned about this?

-kevin


pgpsYadAdE8Rf.pgp
Description: PGP signature

[rt-users] Create tickets on mails without creating a real user record.

[Jan Hugo Prins]

Hello,

I have a question. We are trying to setup RT for our business and it is
progressing rather good, except for one thing.

When someone outside or our support organisation send a mail to the noc
helpdesk address I want the RT system to create a ticket, registering
the email adres and the name of this user in the ticket and put the
ticket in some incoming queue. For the rest, I don't want to create a
user for this ticket. Is this possible?

Jan Hugo Prins

Re: [rt-users] How do I submit a ticket in behalf of a user?

[Kenneth Marshall]

On Thu, Mar 31, 2011 at 10:25:08PM -0400, Thomas Sibley wrote:
> On 31 Mar 2011 22:08, Rocel M. Lacida wrote:
> > Hello All,
> > Good Day!
> > 
> > It's my first to post a mail to the mailing list so  bear with me. First
> > I am previous user of other ticketing system (Accord Trellis) and I have
> > many problems about it and upon searching on the net about  what is best
> > ticketing system out there I found RT and it really meet my
> > requirements. Been using RT for only a couple of weeks and honestly it
> > was awesome. Though I stumble some difficulties at first it was solve
> > upon searching on the web where lots of solutions are provided. Now the
> > only hindrance right now is this,Sorry  to ask this question though I
> > think there is an easy to answer for this I just don't know where to
> > find it. In my prevoius ticketing system there is a functionality that
> > someone can post a ticket in behalf of that user.Where I can find it on
> > RT? Is there any equivalent functionality that I could duplicate? Hope
> > you could help me about this. Sorry for the long introduction.
> 
> Glad to hear you're enjoying RT.  To create a ticket on behalf of a
> user, just put their email address in the Requestor field when creating
> a ticket via the web.
> 
> Cheers,
> Thomas
> 

You can also use the CommandByMail extension to set the requestor
via Email.

Cheers,
Ken

[rt-users] Set Transaction CustomField from My Day tool

[Robert Wysocki]

Hi there, 

I would like to set Transaction CustomField values from the My Day tool.
I've got to the point, where I have the Transaction CF's in the My Day
template, I've even figured out how to associate Ticket ID with the CF
(by the means of NamePrefix).

But I'm stuck with setting the value entered by user. I've tried to use
ProcessObjectCustomFieldValues, but it requires Transaction ID to be
present in the name of the input field (and I've got
Object-RT::Transaction--CustomField--Value there instead of
Object-RT::Transaction--CustomField--Value).

What am I missing?

Thanks in advance,
-- 
Robert

[rt-users] How to add additional e-mail address

[Adrian Stel]

Hi All,



how to add additional e-mail address, when I submitt ticket
notification are sent only to private e-mail address I would like to
send copy this e-mail to another address.





-- 
Best Regards
Adrian Stelmaszyk

Re: [rt-users] recurring requests

[Raed El-Hames]

Mark:

Have a look at rt-crontool , I think it may help you.

Roy

From: rt-users-boun...@lists.bestpractical.com 
[mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of Roedel, Mark
Sent: 31 March 2011 21:45
To: rt-us...@bestpractical.com
Subject: [rt-users] recurring requests

Obviously it's pretty simple to write a script against the REST API and launch 
it from a cron job, but has anybody done anything that's more end-user facing 
to allow for the setup of recurring tickets for periodic maintenance and the 
like?

Re: [rt-users] changing priorities "on the fly"

[Gerard FENELON]

In your place, I would look at how Bookmarks work.
Gerard

On 2011-04-01 11:02, Raphaël MOUNEYRES wrote:


Hello,
on a RT3.8.8

We're using Dashboards with tickets order by priorities to see current 
actions.

During meetings we want to change priorities of displayed tickets.
to achieve this we need to : click on the ticket name, go to essential 
view, change priority, validate, and finally clisk a shortcut to the 
dashboard.

this is not very user friendly

What we would like is to be able to change priorities while in the 
dashboard view.

  Either by drag'n'drop (ideal but many UI coding seems necessary)
  or having the priorities being combobxes (drop down list)
  or having +/- buttons next to the priority number
  or having http links in custom fields launching a scrip to update 
the priority (like an Up arrow, and a Down arrow)


the only solution i found is to have the priority number clickable to 
the modify.html page, wich save a few clicks


i tried adding a custom field style combobox to the tickets but the 
dashboard still display the actual value not the combobox.
>> maybe it is possible to modify the ColumnMap to show the combobox 
instead of the value ?


The other solution i'm considering is in the "ticket search" engine
when adding a column to display we can choose a Format:Relation with 
standard transactions actions, and resulting in something like :
'href="__WebPath__/Ticket/Update.html?Action=Respond&id=__id__">__QueueName__'
>> Would it be possible to start a custom Scrip action when clicking 
the link instead of a web page ?

>> or maybe a custom html page ?

Does anyone has made something similar working, with any of these or 
another solution ?


dependeing on your answer, i may add this to the wishlist.

thank you,

Raphaël 

[rt-users] changing priorities "on the fly"

[Raphaël MOUNEYRES]

Hello,
on a RT3.8.8

We're using Dashboards with tickets order by priorities to see current 
actions.
During meetings we want to change priorities of displayed tickets.
to achieve this we need to : click on the ticket name, go to essential 
view, change priority, validate, and finally clisk a shortcut to the 
dashboard.
this is not very user friendly

What we would like is to be able to change priorities while in the 
dashboard view.
  Either by drag'n'drop (ideal but many UI coding seems necessary)
  or having the priorities being combobxes (drop down list)
  or having +/- buttons next to the priority number
  or having http links in custom fields launching a scrip to update the 
priority (like an Up arrow, and a Down arrow)

the only solution i found is to have the priority number clickable to the 
modify.html page, wich save a few clicks

i tried adding a custom field style combobox to the tickets but the 
dashboard still display the actual value not the combobox.
>> maybe it is possible to modify the ColumnMap to show the combobox 
instead of the value ?

The other solution i'm considering is in the "ticket search" engine
when adding a column to display we can choose a Format:Relation with 
standard transactions actions, and resulting in something like :
'__QueueName__'
>> Would it be possible to start a custom Scrip action when clicking the 
link instead of a web page ?
>> or maybe a custom html page ?

Does anyone has made something similar working, with any of these or 
another solution ?

dependeing on your answer, i may add this to the wishlist.

thank you,

Raphaël

#
" Ce courriel et les documents qui lui sont joints peuvent contenir des
informations confidentielles ou ayant un caractère privé. S'ils ne vous sont
pas destinés, nous vous signalons qu'il est strictement interdit de les
divulguer, de les reproduire ou d'en utiliser de quelque manière que ce
soit le contenu. Si ce message vous a été transmis par erreur, merci d'en
informer l'expéditeur et de supprimer immédiatement de votre système
informatique ce courriel ainsi que tous les documents qui y sont attachés."


   **

" This e-mail and any attached documents may contain confidential or
proprietary information. If you are not the intended recipient, you are
notified that any dissemination, copying of this e-mail and any attachments
thereto or use of their contents by any means whatsoever is strictly
prohibited. If you have received this e-mail in error, please advise the
sender immediately and delete this e-mail and all attached documents
from your computer system."
#