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?
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.
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.
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?).
On Fri, Nov 04, 2011 at 05:37:25PM +0000, 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.
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.