[rt-users] REST + user without e-mail address = no requestor
Hello,
Is it possible to create a ticket through REST with a user which has no e-mail
address ?
This doesn't work :
#!/usr/bin/env perl
use strict;
use RT::Client::REST;
my $rt = RT::Client::REST-new( server = 'http://myrtserver'
);$rt-login(username = 'user', password = 'password' );
$rt-create( type = 'ticket', set = {requestor = 'rt_user', # user
with no e-mail addressqueue = 'test',subject = 'test' }, text = '1
2 1 2 this is a test');
# the ticket is created without any requestor...
Re: [rt-users] REST + user without e-mail address = no requestor
Try id instead of name, but I wouldn't be surprised if it doesn't work.
Ruslan from phone.
29.03.2012 13:54 пользователь Arthur Rance arthur_ra...@hotmail.com
написал:
Hello,
Is it possible to create a ticket through REST with a user which has no
e-mail address ?
This doesn't work :
#!/usr/bin/env perl
use strict;
use RT::Client::REST;
my $rt = RT::Client::REST-new( server = 'http://myrtserver' );
$rt-login(username = 'user', password = 'password' );
$rt-create
(
type = 'ticket',
set =
{
requestor = 'rt_user', # user with no e-mail address
queue = 'test',
subject = 'test'
},
text = '1 2 1 2 this is a test'
);
# the ticket is created without any requestor...
Re: [rt-users] REST user
On Sat, Nov 05, 2011 at 03:50:03PM +, Ram Moskovitz wrote: On Fri, Nov 04, 2011 at 05:37:25PM +, Ram Moskovitz wrote: I'm using the REST interface as a gateway between my web-app and RT. It's pretty close to done - the one thing I'm having a problem with is assuming the requestor's identity when adding correspondence. By way of example: 1 User logs in to web-app and fills out a support request form 2 web-app uses REST account to create ticket OBO of user (set's the requestor to be the actual customer's email addres) all the normal RT mails go out to the requestor 3 Any time the user comes to check on the status of their ticket(s) the web-app uses the REST account to query RT and provide a subset of the ticket info back 4 User may then 'add-correspondence' to the ticket via the web-app in which ase the app uses the REST account to add the correspondence to the ticket. The problem is that the correspondence shows that it was added by the REST user - is there a reasonable way around this? Not unless you can log in as the user via the REST interface. The Perl API allows you to load the ticket as a user and Correspond as them. I assume our SelfService interface wasn't sufficient for your needs? So far you've listed features it has, and it handles Correspondence correctly. -kevin I can have the web-app login as the user via the REST interface in theory. Currently the users are auto-created and unprivileged - does that have to change? You just have to ensure that they have sufficient rights, probably by granting them to the Requestors role. As for using the native RT self-service web interface - I don't want to frame it with-in my app and I don't want to swizzle my app through RT. pgpvppV5sbPHy.pgp Description: PGP signature RT Training Sessions (http://bestpractical.com/services/training.html) * Barcelona, Spain November 28 29, 2011
Re: [rt-users] REST user
Hi, Apart from the user creating the actual ticket, isn't it enough to have the person creating the ticket on your web portal to be listed as the requestor? The only difference is the history log showing that your REST user did the actual registration but all other content should be normal + if the user wrote down his/her e-mail correctly then they'd also receive the AutoReply e-mail. Though that's all about how you want to view the history log, if having the actual username/e-mail as actioning user for the ticket creating is important then you could try to make all users privileged (imho, not a nice situation if it isn't needed/required), or have your web-app send an e-mail to RT with the requestors e-mail adres in the from field. But with the last part you'd lose the ability to assign CF's or other values. I'm not much of a developer but I'd say those are pretty much your options, where I'd either accept the fact that the REST user created a ticket (with all other values/fields perfectly filled, inc. requestor) or make an interface that sends an e-mail (and maybe combine that with the command by mail function?). -- Bart 2011/11/5 Ram Moskovitz ram0...@gmail.com On Fri, Nov 04, 2011 at 05:37:25PM +, Ram Moskovitz wrote: I'm using the REST interface as a gateway between my web-app and RT. It's pretty close to done - the one thing I'm having a problem with is assuming the requestor's identity when adding correspondence. By way of example: 1 User logs in to web-app and fills out a support request form 2 web-app uses REST account to create ticket OBO of user (set's the requestor to be the actual customer's email addres) all the normal RT mails go out to the requestor 3 Any time the user comes to check on the status of their ticket(s) the web-app uses the REST account to query RT and provide a subset of the ticket info back 4 User may then 'add-correspondence' to the ticket via the web-app in which ase the app uses the REST account to add the correspondence to the ticket. The problem is that the correspondence shows that it was added by the REST user - is there a reasonable way around this? Not unless you can log in as the user via the REST interface. The Perl API allows you to load the ticket as a user and Correspond as them. I assume our SelfService interface wasn't sufficient for your needs? So far you've listed features it has, and it handles Correspondence correctly. -kevin I can have the web-app login as the user via the REST interface in theory. Currently the users are auto-created and unprivileged - does that have to change? As for using the native RT self-service web interface - I don't want to frame it with-in my app and I don't want to swizzle my app through RT. RT Training Sessions (http://bestpractical.com/services/training.html) * Barcelona, Spain November 28 29, 2011 RT Training Sessions (http://bestpractical.com/services/training.html) * Barcelona, Spain November 28 29, 2011
[rt-users] REST user
On Fri, Nov 04, 2011 at 05:37:25PM +, Ram Moskovitz wrote: I'm using the REST interface as a gateway between my web-app and RT. It's pretty close to done - the one thing I'm having a problem with is assuming the requestor's identity when adding correspondence. By way of example: 1 User logs in to web-app and fills out a support request form 2 web-app uses REST account to create ticket OBO of user (set's the requestor to be the actual customer's email addres) all the normal RT mails go out to the requestor 3 Any time the user comes to check on the status of their ticket(s) the web-app uses the REST account to query RT and provide a subset of the ticket info back 4 User may then 'add-correspondence' to the ticket via the web-app in which ase the app uses the REST account to add the correspondence to the ticket. The problem is that the correspondence shows that it was added by the REST user - is there a reasonable way around this? Not unless you can log in as the user via the REST interface. The Perl API allows you to load the ticket as a user and Correspond as them. I assume our SelfService interface wasn't sufficient for your needs? So far you've listed features it has, and it handles Correspondence correctly. -kevin I can have the web-app login as the user via the REST interface in theory. Currently the users are auto-created and unprivileged - does that have to change? As for using the native RT self-service web interface - I don't want to frame it with-in my app and I don't want to swizzle my app through RT. RT Training Sessions (http://bestpractical.com/services/training.html) * Barcelona, Spain November 28 29, 2011
[rt-users] REST user
Hi all, I'm using the REST interface as a gateway between my web-app and RT. It's pretty close to done - the one thing I'm having a problem with is assuming the requestor's identity when adding correspondence. By way of example: 1 User logs in to web-app and fills out a support request form 2 web-app uses REST account to create ticket OBO of user (set's the requestor to be the actual customer's email addres) all the normal RT mails go out to the requestor 3 Any time the user comes to check on the status of their ticket(s) the web-app uses the REST account to query RT and provide a subset of the ticket info back 4 User may then 'add-correspondence' to the ticket via the web-app in which ase the app uses the REST account to add the correspondence to the ticket. The problem is that the correspondence shows that it was added by the REST user - is there a reasonable way around this? thanks ram RT Training Sessions (http://bestpractical.com/services/training.html) * Barcelona, Spain November 28 29, 2011
Re: [rt-users] REST user
On Fri, Nov 04, 2011 at 05:37:25PM +, Ram Moskovitz wrote: I'm using the REST interface as a gateway between my web-app and RT. It's pretty close to done - the one thing I'm having a problem with is assuming the requestor's identity when adding correspondence. By way of example: 1 User logs in to web-app and fills out a support request form 2 web-app uses REST account to create ticket OBO of user (set's the requestor to be the actual customer's email addres) all the normal RT mails go out to the requestor 3 Any time the user comes to check on the status of their ticket(s) the web-app uses the REST account to query RT and provide a subset of the ticket info back 4 User may then 'add-correspondence' to the ticket via the web-app in which ase the app uses the REST account to add the correspondence to the ticket. The problem is that the correspondence shows that it was added by the REST user - is there a reasonable way around this? Not unless you can log in as the user via the REST interface. The Perl API allows you to load the ticket as a user and Correspond as them. I assume our SelfService interface wasn't sufficient for your needs? So far you've listed features it has, and it handles Correspondence correctly. -kevin pgpZS01HFpEOP.pgp Description: PGP signature RT Training Sessions (http://bestpractical.com/services/training.html) * Barcelona, Spain November 28 29, 2011
