Is it possible to specify a different user with RT CLI?

RT Users
1

Hello,

I’m using RT CLI (Command Line Interface) to comment tickets for various
users.

Is there a way, while connecting with the admin (root) account, to
record the comments/corresponds as a different user (impersonating) ?

I can change the transaction’s owner afterwards but the email messages
will originate from “root”. BTW, it would be nice if the success message
was something like :

Message recorded (transaction #12345)

Thanks for your help,

Jean-Christophe Boggio -o)
rt-users@thefreecat.org /\
Independant Consultant and Developer __V

2

With env variable

RTUSER=john

Optional:
RTPASSWD=johnubberpassword@

-----Mensagem original-----De: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] Em nome de Jean-Christophe Boggio
Enviada em: quinta-feira, 6 de junho de 2013 13:31
Para: RT Users
Assunto: [rt-users] Is it possible to specify a different user with RT CLI ?

Hello,

I’m using RT CLI (Command Line Interface) to comment tickets for various users.

Is there a way, while connecting with the admin (root) account, to record the comments/corresponds as a different user (impersonating) ?

I can change the transaction’s owner afterwards but the email messages will originate from “root”. BTW, it would be nice if the success message was something like :

Message recorded (transaction #12345)

Thanks for your help,

Jean-Christophe Boggio -o)
rt-users@thefreecat.org /\
Independant Consultant and Developer __V

RT Training in Seattle, June 19-20: Training — Best Practical Solutions

3

Thanks for your answers but that’s not what I’m looking for. This method
will work if I store the passwords for every user in clear form.

What I want is to only have the root (admin) passwd in a RT Config File
and issue the comment/correpond AS some user. I am making a dedicated
interface to RT.

Is this possible ?

Jean-Christophe Boggio -o)
cat@thefreecat.org /\
Independant Consultant and Developer __V

4

Try rest interface instead of RT CLI.

" Authentication Edit

The REST Interface does not support HTTP-Authentication. So you must get a valid Session-Token and submit the cookie each request. You usually get a Session-Cookie by submitting the default login form. Use variables “user” for login and “pass” for password values. wget doesn’t escape any characters in the --post-data option so make sure you properly escape any special characters in the password."

http://requesttracker.wikia.com/wiki/REST

Diaulas Castro
Consultor Linux / Microsoft
InterSolution Informática
Tel.: ( 55 11 ) 3443-1472
www.intersolution.inf.br
Oracle Certified Partner

-----Mensagem original-----De: Jean-Christophe Boggio [mailto:rt-users@thefreecat.org]
Enviada em: quinta-feira, 6 de junho de 2013 20:05
Para: Landon Stewart
Cc: Diaulas Castro; RT Users
Assunto: Re: [rt-users] RES: Is it possible to specify a different user with RT CLI ?

Thanks for your answers but that’s not what I’m looking for. This method will work if I store the passwords for every user in clear form.

What I want is to only have the root (admin) passwd in a RT Config File and issue the comment/correpond AS some user. I am making a dedicated interface to RT.

Is this possible ?

Jean-Christophe Boggio -o)
cat@thefreecat.org /\
Independant Consultant and Developer __V

5

Le 07/06/2013 13:35, Diaulas Castro a �crit :

Try rest interface instead of RT CLI.

Thanks Diaulas, seems exactly what I’m looking for.

Jean-Christophe Boggio -o)
rt-users@thefreecat.org /\
Independant Consultant and Developer __V

6

Thanks for your answers but that’s not what I’m looking for. This
method will work if I store the passwords for every user in clear
form.

What I want is to only have the root (admin) passwd in a RT Config
File and issue the comment/correpond AS some user. I am making a
dedicated interface to RT.

While the REST interface (which is what the command line client uses)
does not allow you to impersonate a user without knowing passwords or
cookies, you can use RT’s core perl API to load any user and record
actions as that user.

-kevin

7

Le 07/06/2013 18:36, Kevin Falcone a �crit :

While the REST interface (which is what the command line client uses)
does not allow you to impersonate a user without knowing passwords or
cookies, you can use RT’s core perl API to load any user and record
actions as that user.

Thanks for your answer Kevin. In fact, I tried with cookies and it
doesn’t work either (setting the transaction creator with a “Creator:”
field).

So I will have to do it the hard way (hopefully I code in perl but I
didn’t want to install the whole request-tracker just for the libs on
this machine which is only a frontend).

Jean-Christophe Boggio -o)
rt-users@thefreecat.org /\
Independant Consultant and Developer __V

8

Ok, I did it and it seems to work like I want it to. There are still
things that I don’t understand but they might be related to my lack of
Perl knowledge, for example : why can’t I find the declaration for
RT::User->new or RT::Ticket->new ?

For the record I did this :

use lib qw(/usr/share/request-tracker4/lib);

use RT;
use RT::Ticket;
use RT::User;

RT->LoadConfig();
RT->Init();

140 is my test user (the one I’m impersonating)

my $User = RT::User->new();
$User->Load(140);
die “User 140 not found” unless $User->id;

As I understand it, RT’s $TicketObj->new expects a RT::User parameter

which will be the “CurrentUser”

This user must have rights to comment/correspond in the ticket’s queue

Our system does not use queues to determine who can write/comment/…

It is rather based on (recursive) assets (organization/Administrative

entity/Site) so I take care of the ACL by myself.

I chose to give all permissions to all users in RT’s queues.

I probably could have rather used :

$RT::Handle->BeginTransaction();

$Ticket->_RecordNote(%args);

$RT::Handle->Commit();

3 is my test ticket

my $Ticket = RT::Ticket->new( $User );
$Ticket->Load(3);
die “Ticket 3 not found” unless $Ticket->id;

$Ticket->Comment(
Content => “This is a test”
);

As a side note, the RT->Init() is very long, mainly because of
RT::I18N->Init()

Since I don’t need internationalization, I copied what RT::Init does and
commented out the I18N part :

RT::CheckPerlRequirements();
RT::InitPluginPaths();
RT::ConnectToDatabase();
RT::InitSystemObjects();
RT::InitClasses();
RT::InitLogging();
RT::InitPlugins();

RT::I18N->Init;

RT->Config->PostLoadCheck;

Hope this helps. I’d be glad to create a wiki page describing this but
I’m not too confident in my understanding of how RT core works. However,
if someone validates it, I’ll do it.

Thanks again to those who helped.

9

As I understand it, RT’s $TicketObj->new expects a RT::User parameter

which will be the “CurrentUser”

It actually wants an RT::CurrentUser, but RT will do the conversion
for you.

As a side note, the RT->Init() is very long, mainly because of
RT::I18N->Init()

This surprises me, what’s slow and how did you profile it?
You could limit the languages that RT loads, but that may not do what
you want. You may also run into really weird errors depending on what
parts of RT you invoke.

http://bestpractical.com/rt/docs/latest/RT_Config.html#LexiconLanguages

-kevin

10

Le 14/06/2013 20:58, Kevin Falcone a �crit :

It actually wants an RT::CurrentUser, but RT will do the conversion
for you.

Thanks for this info, I’ll see if I can do better. Any hint for the
new() methods ? Where are they declared ?

As a side note, the RT->Init() is very long, mainly because of
RT::I18N->Init()

This surprises me, what’s slow and how did you profile it?

I don’t really know. I replaced my RT::Init() call with every line from
RT::Init() and placed a warn between every line, then I tailed -f
/var/log/apache2/error.log. For RT::I18N->Init() it
took several seconds while the rest was instantaneous. So I commented
out that line.

You could limit the languages that RT loads, but that may not do
what you want. You may also run into really weird errors depending
on what parts of RT you invoke.

I just want to comment/correspond tickets.

Maybe in the future I will use the library to create groups (currently I
create them with RT::CLI and modify them in the DB because I use special
“type” and “instance” values – for “UserDefined” domain only).

JC

11

It actually wants an RT::CurrentUser, but RT will do the conversion

for you.

Thanks for this info, I’ll see if I can do better. Any hint for the new()
methods ? Where are they declared ?

As a side note, the RT->Init() is very long, mainly because of

RT::I18N->Init()

This surprises me, what’s slow and how did you profile it?

I don’t really know. I replaced my RT::Init() call with every line from
RT::Init() and placed a warn between every line, then I tailed -f
/var/log/apache2/error.log. For RT::I18N->Init() it
took several seconds while the rest was instantaneous. So I commented out
that line.

I can believe that. Our po files getting big and loading them takes time. I
have “loading po files on demand” patch on my todo, but not sure when I get
to it.

You could limit the languages that RT loads, but that may not do

what you want. You may also run into really weird errors depending
on what parts of RT you invoke.

I just want to comment/correspond tickets.

Maybe in the future I will use the library to create groups (currently I
create them with RT::CLI and modify them in the DB because I use special
“type” and “instance” values – for “UserDefined” domain only).

Note that Type is going away in RT 4.2, so a group would be Domain, Name
and Instance. I think you should consider using RT::Attribute.

JC

–
RT Training in Seattle, June 19-20: http://bestpractical.com/**traininghttp://bestpractical.com/training

Best regards, Ruslan.

12

Ruslan,

Thanks for your comments.

I can believe that. Our po files getting big and loading them takes
time. I have “loading po files on demand” patch on my todo, but not sure
when I get to it.

No problem for me but sure, it’ll be a good improvement.

Note that Type is going away in RT 4.2, so a group would be Domain, Name
and Instance. I think you should consider using RT::Attribute.

Thanks for the info… I will move this information to the Attributes table.

A few notes though :

I have blacklisted the Attributes table in my mind because of the way
most data is stored in there because you can’t access it in SQL (the
“storable” content-type).

I am about to implement some kind of “bookmarks” function (to keep track
of the last N tickets you’ve been commenting, this is what we currently
use “bookmarks” for) but I need to find the info from SQL :
requirement are :

  • find “open unbookmarked tickets”,
  • find “bookmarked” tickets for every user from a group
  • find who bookmarked one specific ticket.
    (we have 11000+ users)

Here, the “Attributes” table will miss at least one column to implement
multi-instanciation (last 5 bookmarked tickets for a user). Could you
consider adding one extra field for flexibility (integer would do but
varchar might be even more flexible).

Best regards,

JC

13

BTW, while I’m at it, the “links” table also misses such an 'instance’
field :

When we link assets to tickets, we would like to distinguish between
what we consider the “main” asset and the “related” assets.

Examples :

  • “sites” are assets. One ticket is created for a “site” but may concern
    other sites.
  • “servers” are assets. The cause of the problem is one specific server
    but the problem might impact others. We do link all impacted servers to
    the ticket but there is a “main” server.

You could see this as a “subtype”.

Also wanted to mention that the “links” table misses an index on
"target" (some of our queries’ execution times were divided by 7 when
adding this index). We are using Postgres exclusively.

Hope this helps,

JC

14

Ruslan,

Thanks for your comments.

I can believe that. Our po files getting big and loading them takes

time. I have “loading po files on demand” patch on my todo, but not sure
when I get to it.

No problem for me but sure, it’ll be a good improvement.

Note that Type is going away in RT 4.2, so a group would be Domain, Name

and Instance. I think you should consider using RT::Attribute.

Thanks for the info… I will move this information to the Attributes
table.

A few notes though :

I have blacklisted the Attributes table in my mind because of the way most
data is stored in there because you can’t access it in SQL (the “storable”
content-type).

It’s only stored that way if you’re saving data structures. Simple values
are stored as text.

I am about to implement some kind of “bookmarks” function (to keep track
of the last N tickets you’ve been commenting, this is what we currently use
“bookmarks” for) but I need to find the info from SQL : requirement are :

  • find “open unbookmarked tickets”,
  • find “bookmarked” tickets for every user from a group
  • find who bookmarked one specific ticket.

(we have 11000+ users)

Well, it doesn’t explain need to abuse Type and Instance. Above description
unclear on what is “bookmarked ticket”. Last value makes no sense - if user
commented on 20 tickets within last 24 hours then 15 of them are not
“bookmarked”, so 15 tickets are not bookmarked by this user, but he updated
them within 24 hours. I think you should start from more formal spec and
try it on paper first for several cases.

Here, the “Attributes” table will miss at least one column to implement

multi-instanciation (last 5 bookmarked tickets for a user). Could you
consider adding one extra field for flexibility (integer would do but
varchar might be even more flexible).

Best regards,

JC

–
RT Training in Seattle, June 19-20: http://bestpractical.com/**traininghttp://bestpractical.com/training

Best regards, Ruslan.

15

Ruslan,

Well, it doesn’t explain need to abuse Type and Instance. Above
description unclear on what is “bookmarked ticket”. Last value makes no
sense - if user commented on 20 tickets within last 24 hours then 15 of
them are not “bookmarked”, so 15 tickets are not bookmarked by this
user, but he updated them within 24 hours. I think you should start from
more formal spec and try it on paper first for several cases.

Sorry for being unclear. We want to keep track on who is working on what tickets in order to (re)dispatch the tasks :

  • some users will “think” they can manage 10 tickets at a time
  • some tickets are not being taken care of
  • some tickets are being worked on by several users at the same time

So we asked our users to “bookmark” the ones they do work on but it’s tedious and they often forget.

So we want to automate the process : every time someone comments a ticket, we will add this ticket number to his “MRU” (Most Recently Used). We consider that if he comments a ticket, he’s working on it.
We have a maximum number of tickets worked on by one user (say 5 for example). When he comments a ticket and he already has 5, the oldest will become “available” for someone else to take care of it.

Simplified SQL implementation would look like :

  • adding a bookmark (not taking care of working twice on the same ticket) :
    DELETE FROM attributes where name=‘Bookmarks’ AND objectid= AND instance >= 5
    UPDATE attributes SET instance=instance+1 WHERE name=‘Bookmarks’ AND objectid=
    INSERT INTO attributes (name,objectid,instance,content) VALUES (‘Bookmarks’,,1,)
  • find duplicates :
    SELECT ticketid,objectid FROM attributes WHERE name=‘Bookmarks’

Currently, finding “open unbookmarked tickets” means reading all attributes with name “Bookmarks” and parse the values in perl.
Finding tickets “bookmarked” by two users (they work on the same problem at the same time which we want to avoid) requires the same workload.
We have several screens dedicated to displaying these informations in realtime (updated every 10seconds).

I admit this would be made simpler by using the “Owner” field but it is a slightly different approach :

  • they can have more than 5 tickets assigned
  • the assigners sometimes assign tickets to the bad person
  • the priorities do not always fit the scenario : if the helpdesk has the user on the phone, they will try to resolve the problem ASAP.
  • we want the 2 approaches

Hope this helps clarifying the way we work.