Configurable Screens - Set fields in layout gets replaced when changing tab order in the UDF field list
Hi,
I noticed that when I did a major rearrangement of tab order among UDF-fields for the Company entity, the fields got replaced in the Screen Designer layouts.
It seems that the identification of fields in the designer layout is based on TabOrder-id and not ProgId.
Is this a known and expected behaviour? This means that ALL layouts for the related entity has to be updated after one have changed the tab order in the UDF-fields list. Seems a bit like laying the bed for unexpected results for the customers not knowing about this behaviour, right?
One practical reason for maybe wanting to change the tab order, might be that if you reset all layouts, you want the fields to be pretty much in the right order, when starting doing a new layout.
I understand that the new screens are using the taborder in which the fields are ordered in the layout, but as the tab-order functionality is still available in the UDF Fields view and could be used for such a use case as stated above, I still find it to be a bad behaviour, as it breaks set configuration. Some kind of identification via the ProgId or UDFFieldId might be a better solution.
Now I at least know about it, so I can take the right precautions if needed.
Would be interesting to know the thought from RnD in this matter.
Regards
Marcus
All Replies (2)
Hi Marcus,
The view in Admin - Fields is showing a preview of all custom fields sorted by rank, both user defined fields and extra fields created in Service.
The preview is basically reflecting what you would see in the More tab if NOT making any changes within the ScreenDesigner.
For customers not having ScreenDesigner due to no Development Tools license, the way to adjust field order is by adjusting "tab-order"/rank as you have done.
The More tab is the same with or without access to ScreenDesigner.
If you have made changes in the ScreenDesigner, we are ensuring re-arrangments from ScreenDesigner is applied in addition to original rank sorting. Which means, if all fields have been moved within the screendesigner, rank change would not decide where the fields ends up.
Also, if you create any new udef fields, these are automatically showing up in the More tab based on what we know about rank.
For customers who has ScreenDesigner available, and would prefer no auto-sorting based on rank, there is a possibility to create another tab replacing the standard More tab.
With the consequence that any new udef/extra fields would not show up automatically, but would need to be added manually to every layout the field is relevant for.
Best regards,
Trude
Ok, I understand all that.
What I find being a bad behaviour is the fact that re-ordering the rank for the UDF Fields, will affect saved layouts in a way that current layouts will show the wrong fields and needs to be re-adjusted.
But, if I understand you correctly, this behaviour is ONLY affecting the original More-tab in a layout. It is a nice feature that the original More-tab automatically adds new UDF-fields/Extra-fields to the view, placing it in rank order per default. But still, only re-ordering the rank for the UDF Fields-entity shouldn't break current layouts so fields gets replaced with other fields. That is just bad behaviour that I think should be fixed.
I assume that the reason for this behaviour is because the layout is using the rank-id to identify which fields that are to be shown in the layout. I would really have preferred if you were using some other kind of identifier, that doesn't make existing layouts to break.
Though, interesting info that this behaviour allegedly could be avoided by creating a custom tab, that seems like a manageable workaround. Thanks for that tip!
If one has deleted the More-tab in a layout and later on wants to add it again, to get the more dynamic behaviour, is this possible? Or, do I have to create a new layout based on a factory reseted base to get the standard objects in the layout again?