It seems that currently there’s no way to determine if a field (either system or custom) is active or not, using REST API. Maybe not that critical, but this feature is pretty desirable, and the lack of it is now causing me some sadness.
Additionally there’s no way to determine if such system fields as Estimate, Milestone and References are required
Additionally, there’s no way to figure out which date format (e.g. mm/dd/yyyy, or yyyy-mm-dd, or else) is expected for date field. According to the docs, the format is not agnostic but relies on active locale (on per-user basis).
To be honest, I’m not so sure about this design decision. Always expecting dates as e.g. ISO 8601 regardless of site/user preferences would be much more reliable.
[UI Script][Plugin][PoC] TestRail plugins — working demo
Thanks for your posting. You can query custom/system field related details via the get_case_fields and get_result_fields API methods:
The date format depends on the user as you mentioned but you can always add a generic API user (with a standard and well-known date format).
I checked again, and no, the response from
GET index.php?/api/v2/get_case_fields does not include Milestone, Estimate, or References fields. And no, there is no information whether the field is active or hidden. I wouldn’t be reporting the issue if there were.
A generic API user is hardly a workaround. First of all, sometimes it is required that the REST API call is made by a specific user (e.g. via UI script). Besides, having a dedicated API user counts toward licensing costs. I’d really suggest that you put this issue on the list and either:
a) fix the
add_result methods so that they expect specified date format, e.g. ISO 8601 (after all, REST is for machine-to-machine communication);
b) provide endpoint to determine current user’s date format;
c) accept dates both in user’s locale and a standard one (currently validation fails if date submitted not in user locale)
With best regards,
get_case_fields only returns custom fields (to stay compatible with previous versions) but it’s planned to look into providing support for the (now configurable) system fields as well. We will also make sure to look into the date format and I agree that a more deterministic approach would be good to have for the API.
Thanks again for your feedback on this!