Extra fields and translations for enduser

Hi Tejo,

One of the ways to do this is to have a (base) table that contains some information about Free fields. These Free fields can have a subject, a label and a data type for instance. But to keep it simple, you can create a base table holding the following:

• Tenant
• Label

Then create another table that will hold the configuration:

• Tenant
• Label
• Value

Then create View that will show rows for each Label (set-up Free field). Let this use a Formlist.

• Tenant
• Label
• Value

Code for the View would look similar to this:

select 
    base.tenant_id,
    base.label_text,
    conf.set_value
from free_field base
left join free_field_configuration conf
  on base.tenant_id  = conf.tenant_id
 and base.label_text = conf.label_text

This will then show an X amount of records for the Tenant based on the amount of base Free fields. Any configured values will be shown if given. Using a Handler or Instead-of trigger will allow you to write the inputted values into the configuration table. This configuration table can be hidden as you will only show the view. 

In this example, the Formlist may not be necessary, but once you would like to add complexity in the form of multiple data type support, you'll need a Layout procedure to hide certain fields base on the datatype for example. Then a Formlist is needed.

(label text can be made multi-lingual by adding another table that holds the translation)

Hope this gives some inspiration 😄

Thanks Jasper, I got this working in a form, but in a grid I can’t fix the column-names

Could it be that the Auto-edit setting is turned on for the Subject?

Using Auto-edit and Auto-save for Formlists is usually what is more user-friendly but I can understand that in some cases it should be read-only.

You can use Role rights and/or Layout logic to prevent certain fields from being editable in specific cases.

hi @Jeroen van den Belt , I think that the formlist is a rather complex solution for something that could be easily fixed if the translations for those extra fields could easily be changed for the endproduct in a ISV customers’ environment.

But I guess that is not supported at this time? To change translations in IAM or better still in the endproduct?

What could be interesting is an option to override app translations from IAM for specific apps.

However this would probably be difficult if you want to keep overrides when deploying a newer version. What should happen with them etc...