Rest

Hi,

Has anyone used RT’s REST interface? I was just wondering if I’ve
missed something because in REST/1.0/Forms/queue/default, in <%ARGS>,
we have $changes => {}
and in the <%perl> section, we have my %daya = %$changes; and I was
just wondering how to form a uri to this. According to the Mason
documentation, to pass in a hash to args, one does something like:
/my/URL?grades=Alice&grades=92&grades=Bob&grades=87
However, it appears in the example that @grades is given in args
instead of a reference to a hash like $grades.

I hope someone can enlighten me.

thanks,
Shuying

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.

Will they need to be privileged or have passwords to be usable via REST?

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.

Will they need to be privileged

No, but you will need to tell RT that unprivileged users can reach the
REST endpoint using the SelfServiceRegex config

or have passwords to be usable via REST?

Yes - otherwise how would you log in as them?

Also, your mail client appeared to pick a new subject and break
threading.

-kevin