Hi,
We are currently using on-premise Jama 8.4.1; the discussion below applies to my knowledge of this specific version of Jama.
It's clear that the Test Run type is a bit of a unique animal in Jama. This makes it a bit of a challenge to work with via REST API. For all other item types, we can programmatically query the item type (via GET /itemtypes/{id}) to determine each field's type (and the associated pick list, as appropriate) as well as other attributes such as required, read only, etc. However, for the Test Run, the ONLY PUT call (PUT /testruns/{id}) is used to "Update the execution results... " which essentially has its own set of "unknowable" settings for the field attributes. For example, name and description fields are Read Only (though the REST call does not return an error when these values are changed). On the other hand, duration and testRunStatus are not Read Only. And assignedTo is Required. None of these match with the field attributes of the Test Run item type retrieved through the GET /itemtypes/{id} call.
I do understand that the intent is to match the functionality of the Test Run as it is executed by a user in the Jama UI. Matching the functionality is not really an issue; rather, the issue is that there is no way to know programmatically which fields are RW/RO, required when executing the test run. Of course we can hard-code the information but that adds overhead as it would be a custom code path just for Test Run and if things change it's something we have to manually update.
Additionally, there is value in being able to update Test Run fields such as the name and description. For example, the test configuration can be pushed into the Test Run description at the time the test is executed via automation.
One possible solution to this would be to use the PUT /testruns/{id} call to allow updating the Test Run in a way that aligns with the ability to "Edit" the Test Run in the UI (and would also provide consistent behavior across all similar REST calls) and then use a new call PUT /testruns/{id}/execute specifically for the execution behavior. It would still be necessary to provide some method to retrieve field attributes which are unique to the test execution behavior. Maybe it could be built into the current item types structure, with "fields" being default ("Edit") behavior and "fields1" through "fieldsx" being alternate behavior?
Of course, it may be too late to change the behavior of the PUT /testruns/{id} call, so another alternative is to allow normal "Edit" behavior through the PUT /items/{id} call for all item types, rather than excluding Test Management types from that call.
If you are already looking at solutions to this kind of problem, I would be interested to hear about it. If not, I would be happy to submit an enhancement request instead.
Thanks,
Mike
------------------------------
Success always occurs in private, and failure in full view. ~Steven Wright
------------------------------