Updating the ticket Requestor after ticket creation with REST API 2.0


I created an Incident Report (Requestors were not set) using REST API 2.0 and then in the next step I want to update the ticket and set a requestor. Should the following curl invocation work?

curl -X PUT
-H “Content-Type: application/json”
-d ‘{ “Requestors”: [ “newrequestor@somedomain.com” ] }’

PS: I have the authentication done previously and feed in the corresponding cookie but that’s omitted above.

PS2: My setup is RT + RT-IR 5.0.1.

 curl -X PUT -H "Content-Type: application/json"  -u 'root:password' -d '{ "Requestor": "newrequestor@somedomain.com" }' 'http://MyRT/REST/2.0/ticket/1'
["Added newrequestor@somedomain.com as Requestor for this ticket","root is no longer Requestor for this ticket"]%

I use https sessions to communicate with RT + RT::IR over REST API 2 and the above doesn’t work. It’s far fetched but can sessions affect the authentication somehow? Anyway, the following line appears in the rt.log at the end of each attempt to set the requestor:

[4801] [Mon May 24 11:32:49 2021] [error]: Can’t locate object method “Id” via package “0” (perhaps you forgot to load “0”?) at /opt/rt4-dev/sbin/…/lib/RT/REST2/Resource/Record/Writable.pm line 225. (/opt/rt4-dev/sbin/…/lib/RT/REST2/Middleware/Log.pm:62)

Any hints?

Hard to say without being able to duplicate. Does running that curl line just from terminal result in the same error?

It gives :

{ “message”: “Unauthorized” }

which is strange since using the same account and password for plain login succeeds. Concerning the above log line, looking at the code where the error happens, to me it looks like a piece of code that tries to deduce the principal (user) from the request and this fails for some reason.

systemctl status apache2.service says

[4801] Couldn’t get principal for an empty user

More testing: it seems the curl invocation above works in my setup as well. However, there still remains some odd problem with the Session class from python’s requests library: in two consecutive calls to RT via REST API 2, the caller’s identity (authentication cookie) seems to be lost and RT can’t deduce the invoking user.

Even more testing: it seems cookies prevail correctly in two consecutive calls. However, setting a Requestor after ticket creation fails via the REST API 2 in the special case where the Requestor address is also a configured user account in RT. Setting any other Requestor address succeeds.

Is this to be treated as a bug in REST API 2 or a feature?

It appears to be a “feature” since trying to set this user account as a Requestor (well, Correspondent) via the web gui of RT produces the error:

account_here@some.domain is an address where RT receives mail. Adding it as a ‘Requestor’ would create a mail loop

and this makes sense. What makes less sense is the REST API 2 returning an HTTP response 500, Internal server error when confronting the same request. So, please implement an understandable error response for this case in REST API 2.