Skip to main content
Solved

Extra fields and translations for enduser


Tejo van de Bor
Captain
Forum|alt.badge.img+5

hi,

As an ISV we deploy our solution to different customers, and some customers need extra fields in a table to add information. The fields are not part of other processes, just as an extra bit a information on the form.

We created these extra freefields as freefield_01 to 10 and thats working fine. But is it possible to change the translation for these fields, so the enduser can see where the field is for? The translations should be entered in the end solution, and be save during an update of the model.

Sounds like dynamic model, but has anyone done this before?

 

Best answer by Kasper Reijnders

There you go: 

 

View original
Did this topic help you find an answer to your question?
This topic has been closed for comments

11 replies

Mark Jongeling
Administrator
Forum|alt.badge.img+23

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 ๐Ÿ˜„


Jasper
Superhero
  • 678 replies
  • January 17, 2023

Another option would be to add a freelabel_xx expression field with a label control before each of the freefield input fields, that retrieves the value of the label from a configuration table.


Tejo van de Bor
Captain
Forum|alt.badge.img+5
Jasper wrote:

Another option would be to add a freelabel_xx expression field with a label control before each of the freefield input fields, that retrieves the value of the label from a configuration table.

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


Tejo van de Bor
Captain
Forum|alt.badge.img+5

@Mark Jongeling thanks for the inspiration ๐Ÿ˜Š never used formlist before. Is there a reason why a formlist is always editable? The fields should be fixed for some users


Mark Jongeling
Administrator
Forum|alt.badge.img+23
Tejo van de Bor wrote:

@Mark Jongeling thanks for the inspiration ๐Ÿ˜Š never used formlist before. Is there a reason why a formlist is always editable? The fields should be fixed for some users

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.


Jeroen van den Belt
Administrator
Forum|alt.badge.img+9

Hi @Tejo van de Bor, did the answers of Mark and Jasper provide enough inspiration for you to make a good solution?


Tejo van de Bor
Captain
Forum|alt.badge.img+5

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?


Mark Jongeling
Administrator
Forum|alt.badge.img+23

Hi Tejo,

Translations for columns are loaded from the model that is either present in SF or IAM. The way the Windows GUI/Indicium loads the model cannot take into account any end product model overrides.

What Jasper and I suggested is utilizing the Formlist in combination with columns that use a Label control. This will allow you to basically show data (field) as it were a Label like the GUI would supply. The Grid component can only show Labels of columns like how they were specified in the model.

The Formlist is currently the only way of making Free extra fields work.


Kasper Reijnders
Forum|alt.badge.img+5

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...


Mark Jongeling
Administrator
Forum|alt.badge.img+23
Kasper Reijnders wrote:

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...

That sounds like a great Idea to create here on the Community. My vote you'll have ๐Ÿ˜ƒ


Kasper Reijnders
Forum|alt.badge.img+5

There you go: 

 


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings