Reference Field with UI Only Field in Display Template does not display field value on initial displ

When a search field used “Option Source Model” and specifies a Display Template that contains a UI Only Field, on initial display no value is displayed. If you edit the field value and select another value, the display template renders correctly.

This one is a little chicken/eggy because on initial load, Contact row comes from SFDC while subsequent lookups come through the Skuid model. That said, if UI Only Fields are supported when Option Source is model, there must be a way to display the field correct only initial display as well.

Steps to reproduce:

  1. Create page using XML below
  2. Preview page picking a contact

Expected Behavior
Account Id should display “UI Only Field From Account”

Actual Behavior
Account Id displays blank (the Id field does have a value but the UI only field does not)

  1. Change the account Id field to something else

Expected Behavior = Actual Behavior
Account Id displays “UI Only FIeld From Account”

Sample XML

<skuidpage unsavedchangeswarning="yes" personalizationmode="server" showsidebar="true" showheader="true" tabtooverride="Contact">   <models>
      <model id="Account" limit="" query="true" createrowifnonefound="false" adapter="" type="" sobject="Account" doclone="no" processonclient="true">
            <field id="Name"/>
            <field id="Id"/>
            <field id="UIOnlyFieldFromAccount" uionly="true" displaytype="FORMULA" label="UI Only Field From Account" readonly="true" returntype="TEXT">
               <formula>"UI Only Field From Account"</formula>
      <model id="Contact" limit="1" query="true" createrowifnonefound="false" sobject="Contact" adapter="" type="">
            <field id="FirstName"/>
            <field id="LastName"/>
            <field id="CreatedDate"/>
            <field id="UIOnlyFieldFromContact" uionly="true" displaytype="FORMULA" label="UI Only Field From Contact" readonly="true" returntype="TEXT">
               <formula>"UI Only Field From Contact"</formula>
            <field id="AccountId"/>
            <field id="Account.Name"/>
            <condition type="param" enclosevalueinquotes="true" operator="=" field="Id" value="id"/>
      <pagetitle model="Contact" uniqueid="sk-3I6NI6-71">
            <template>{{FirstName}} {{LastName}}</template>
            <action type="delete"/>
            <action type="clone"/>
            <action type="share"/>
            <action type="savecancel" window="self"/>
      <basicfieldeditor showsavecancel="false" showheader="true" model="Contact" mode="read" uniqueid="sk-3I6NI7-72">
            <column width="50%">
                  <section title="Basics" collapsible="no">
                        <field id="FirstName"/>
                        <field id="LastName"/>
                        <field id="AccountId" valuehalign="" type="" optionsource="model" optionmodel="Account" displaytemplate="{{UIOnlyFieldFromAccount}}" searchtemplate="{{UIOnlyFieldFromAccount}}">
            <column width="50%">
                  <section title="System Info">
                        <field id="CreatedDate"/>
      <styleitem type="background" bgtype="none"/>

This is expected behavior. It may be helpful to describe what’s going on in terms of a non-UI Only Field. Let’s use the Account’s Description field.

So, there are two sources of data that we are contending with here:

First, there’s the value we display when the record is sitting at rest, either when the page has first loaded, or after the field has been committed to the database. In those cases, the data used to resolve the merge syntax is actually coming directly from the Contact record via the reference field.

Second, there’s the value we display when the record is actively being edited. In that case, we are using the data coming from the Option Source model (either one created by you, or one automatically created by Skuid’s runtime). When you select a value from the option source, the values in that model are copied over to the Contact model.

Now, if your option source model includes the Description but you haven’t included Account.Description in your Contact model, then your display template won’t render anything when the page loads because there’s no value for “Description”. But, when you begin searching for a record and select one, the Description value is copied from the option source to your Contact model. You get the field value as a “freebie”, even though you didn’t initially query for it. But then, when you commit the field back to the server, Skuid re-queries that record and strips out Description because it’s not really supposed to be there.

Now, this is essentially what’s happening with your UI-Only Field. It exists in the Accounts model, but not in the Contacts model. So, when the page first loads, there’s no field in the Contacts model to resolve that merge variable. But, when you search and select an Account, Skuid is able to resolve your UI-Only field and that value is copied over to the referenced Account in your Contacts model. When you save the Contact, however, the field gets stripped out and your Account field once again appears to be blank.

But, I have good news!

This is actually pretty easy to work around. You can add a UI-Only formula field to your Contacts model and prefix it with “Account.”. This will make it look like it belongs to the referenced Account record rather than the Contact record. You’ll have to duplicate your formula field with the same name in both models, being sure to appropriately prefix your Contact formula’s Account fields with “Account.”, but it should work without an issue.

You can try it with your sample page… just rename the Contact UI-Only Field to “Account.UIOnlyFieldFromAccount” and then reload your page.

JD -

Firstly, thank you for the very thorough explanation, greatly appreciated. The “at rest” vs “edit” scenario is what I was referring to with my “chicken/eggy” situation in the OP so I’m completely with you there.  What I didn’t know was that you can “trick” skuid by using the “dot notation” in the UI Only field name.  My struggle was how to make both models “look” the same but not be the same and the “dot notation” workaround does just that.  Awesome, thank you again!