Re: [rt-users] RES: Is it possible to specify a different user with RT CLI ?
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 -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] RES: Is it possible to specify a different user with RT CLI ?
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 -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] RES: Is it possible to specify a different user with RT CLI ?
On Mon, Jun 17, 2013 at 6:13 PM, Jean-Christophe Boggio rt-us...@thefreecat.org wrote: 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. -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] RES: Is it possible to specify a different user with RT CLI ?
On Sat, Jun 15, 2013 at 5:04 AM, Jean-Christophe Boggio rt-us...@thefreecat.org wrote: 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. 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. -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] RES: Is it possible to specify a different user with RT CLI ?
On Tue, Jun 11, 2013 at 11:24:54AM +0200, Jean-Christophe Boggio wrote: # 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 pgp08IBASLNda.pgp Description: PGP signature -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] RES: Is it possible to specify a different user with RT CLI ?
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. -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] RES: Is it possible to specify a different user with RT CLI ?
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-us...@thefreecat.org /\\ Independant Consultant and Developer_\_V -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] RES: Is it possible to specify a different user with RT CLI ?
On Fri, Jun 07, 2013 at 01:04:38AM +0200, Jean-Christophe Boggio wrote: 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 pgpebPuXLUi8H.pgp Description: PGP signature -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
[rt-users] RES: Is it possible to specify a different user with RT CLI ?
With env variable RTUSER=john Optional: RTPASSWD=johnubberpassword@ -Mensagem original- De: rt-users-boun...@lists.bestpractical.com [mailto:rt-users-boun...@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-us...@thefreecat.org /\\ Independant Consultant and Developer_\_V -- RT Training in Seattle, June 19-20: http://bestpractical.com/training -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
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) c...@thefreecat.org /\\ Independant Consultant and Developer_\_V -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
