Access Custom Drilldown Field


(Tim Klein) #1

Pulling data from a custom field that’s configured as a “drilldown” list returns a numeric value. Is there an API accessible location to get the Text String Value associated with that numeric value?


(John Borelli) #2

Drilldown is the anomaly of the custom field types. The value you are getting is the id value for that element entry within the drilldown options (not the index, not the value of the element but the IS generated id for that element)… There is no way to retrieve that with the api and the only way I have seen to get them is by viewing the source of the page to find the element and look at the id attribute to get the number for each.


(Tim Klein) #3

Thanks John

That’s probably a little easier than the solution I came up with which was to simply save the value to the record then query it to establish that link between the ID and the value.

I assume this is a fixed value in an IS table somewhere. It won’t change based off of position in the list or anything like that?

Thanks again for the reply.


(John Borelli) #4

Drilldowns are “fixed” in the sense that they won’t change until someone in the IS app changes it. When you go to custom fields and see a drilldown, it has a ‘configure’ link next to it that allows you to define the categories and list items. That is when the ids are assigned to each element…at the time it’s saved.

Also, you will find the ‘list’ of category/items on the DataFormField table but they won’t have the Ids with it just an array of the items in the list.


(Tim Klein) #5

Thanks again John,

I did confirm that position doesn’t change the ID but for future reference in case anyone runs into this, editing the values does create a new record and therefore it gets a new ID. I just changed the spelling on an existing value which created a new entry rather than updating the existing entry.

I’d also found the list in the DataFormField but unfortunately, those entries are really nested down an awful lot of levels. Getting down to the correct level to extract and match to my query didn’t seem like a great idea but since changes in spelling are also going to require new configuration in my application, I’m not sure there IS a GOOD way to do it. Looks like I’ll stick with the method I have for now but I’ll really need to think about this one a bit for a longer term flexible solution.

Thanks again for the feedback John.