I'm curious how xtrf determines what does and does not get included in the APIs.
This is sort of of a loaded question since I've recently ran into a couple of missing items that I was/am totally baffled as to why they aren't available.
One is the inability to get meta information about custom fields. Maybe I'm unique in wanting to use the API in this manner, but when constructing front end tools to interface with xtrf, needing, e.g., information about the options from a select control, or data type from an input, etc., for having the ability to dynamically and confidently render a web application that matches what is actually in xtrf would seem very fundamental. But this is missing entirely. Why?
Today while working from a spec that is requesting a web application to frontend our custom client creation process, one of the fields that was requested to set was the "Individual" option in the standard client data, and is in fact one the few options provided in the xtrf's own "add client" dialog in ui. There is no API support to be able to manipulate this option, so we pulled it and now have to instruct users to go set this field manually if they need this post create, not a great experience.
These are just two recent items, but my question, why is there this disconnect between how the xtrf platform works from the UI vs what's available through the API? It would seem obvious to me that if an option is made available through the UI, it should be added to the API as well as part of the same release version of the xtrf platform.
Am I unique here for how I want to use the xtrf API? I would certainly hope not.
It's as if there's a disconnect between the left and right hands here.
Customer support service by UserEcho