Obtaining Custom field definition through API

Dear Karl,

I think the only way to achieve this is by creating a macro (or custom column) that returns information about the custom fields.
There seems to be a nice enum com.radzisz.xtrf.model.customFields.CustomFieldScope that has some nice methods:

• byEntityClass()
  
• getCustomFieldsClass()

Maybe these will provide you with what you need?

Hi Dennis,

I guess I really don't have context to what this means (yet) and maybe if I describe what it is I'm trying to do, you can give me an idea on whether this is even possible.

I'm wanting to build out a landing page on a per client basis for requesting document translation projects that interfaces with XTRF.

I'm envisioning upon navigating to our site via a token that identifies this client, we can dynamically build out an order form that can be customized to a client's specifications.

For us, this usually means custom fields (along with defaults) that would need to be rendered within the form for the client to fill in to complete the request transaction.

My hope is, we can have a custom field within a client's profile that be used to define which of these custom fields (say as either a character delimited list or JSON or whatever) they would need, and during the page initialization, enumerating through these fields and rendering via query responses through XTRF API.

Our other option is to maintain this datastore of custom fields ourselves. It would be nice to have them all in one place, but if not possible, something like this would be necessary.

On a side note, I'm pretty sure there is no ability to create custom fields via the API is there? That would be awesome.

thanks,

Karl

Dear Karl,

Great description of your case there!

What you are talking about seems doable, and I think you need to dive into the options that XTRF provide.

First of all you need to understand the customfield structure that XTRF has.
They store custom fields per entity as a CustomFields object. The custom fields object contains a list of 10 fields per type. So you are bound to that as a maximum.

This means that you have a maximum of 10 datefields, 10 multiselect fields, 10 number fields, 10 selectfields, 10 textfields, 10 checkboxfields. This is a fixed constraint and will not be changed by XTRF. You have to take this into consideration when you create your own implementation.  

These are the available entities: Activity, Contact person, Customer, Project, Provider, Quote, Task, User (these can be found on com.radzisz.xtrf.model.customFields.CustomFieldScope 

We don't like the constraint of a maximum of 10 of each field per entity and it makes it impossible for us to create an ever extending framework. That is why we have chosen to mix the XTRF Custom Fields with our own Simply Translate Custom Fields that we store in our own database. 

Your idea of storing JSON in the Custom Field would be great as well, as this is as extendable as you like.

The API provides you with a way to retrieve and update custom fields of an entity. Creation of custom fields can only be done through the Home Portal. Altough there are more options that you could use. I can think of 3 ways:

1. Custom fields are exposed through their parent entity. For instance, custom fields of a clients can be retrieved through the customer endpoint GET /customers/{customerId}

The model that is returned contains a customFields array.

2. You could also create a view on any entity in XTRF and expose the custom field values here and retrieve them through the browser view GET /browser/views/{viewId}  

3. Then there is also the posibility to expose the custom fields through a macro, the macro's can be executed through the API as well. A macro is a small piece of code that can be run in XTRF and where you are able to use all of the underneeth code of XTRF. In order to use this you would need to have the JavaDoc, which XTRF can you provide you. There is also some nice (bit out-of-date) code sharing going on here: https://xtrf.userecho.com/en/communities/8/topics/633-sharing-virtual-column-code