KBA-01535: Using UI Configuration to make a standard field into a lookup

Question:

Can I make a standard text box or sfDBX grid column have a lookup?
Why does my lookup cause the error ‘Unable to resolve Result Key for Validation‘?

Answer:

Yes.  But things have to tie together. In general, it is easier to adjust/replace one lookup with another since most of the time this is done to control a lookup population/subset/filter model for contacts.  But you are still looking up contacts. When a lookup is applied to the field, Spitfire automatically enables VALIDATION so that the value in the field remains one of the possible selections in the lookup. This is accomplished by using the ‘Described Value‘ (DV) feature—the value in the field should return a result when ‘tested‘ against the DV. In the UI Configuration tool, you will need to specify the following.

• In the Lookup field, type the name of the lookup. (Some common lookups are described below; see Common Lookup Names.)
• In the Extended field, type
  • CSS=uiInstantAC
    • This is optional, but you should include if the list of choices is small and a drop down style is your intent.
  • DependsOn=
    • This might be required (see information in Common Lookup Names below).
  • ShowColType=DBLabel
    • This is not required if the column is already a lookup, but should be included for sfDBX grid columns.
  • ValidateAgainst= proper DV-name (See Validation Names below)
    • The DV-name should:
      • have the same “Depends on” requirements as the lookup. It can have a subset of the Depends On, but cannot diverge to its own unique Depends On list.
      • expect the same data that the lookup returns (say a contact GUID or a role name)

Common Lookup Names

• CodeLookup: A list of codes in a Code Set
  • Use DependsOn= to specify the code set name, e.g. DependsOn==CostingMethod
    • Note: if what follows Depends On is a variable, use one =.  If what follows is a constant, use ==.
  • For Validation, use ValidateAgainst=CodeLookup
• CodeLookupDescr:  a list of descriptions in a code set (the code is ignored, the description is stored)
  • Use DependsOn= to specify the code set name, e.g. DependsOn==0MyCodeSet
• SubcodeList: A list of codes from the Subtype code set for a specific Doc type.
  • Use DependsOn==setname,=GUID-for-doctype
  • Use Validation DocTypeSubcode or DocTypeSubcodeSelf (code)
• AtCompanyContactList: Contact At Company.
  • This requires DependsOn=#DocMasterDetail.SourceContact; or similar. This lookup provides a list of contacts that share the same company.
• CompanyContactList: Active Contacts by Company.
• CustomerList: Active Customer Company List (primary).
• CustomerContactList: Active Customer Contacts (primary and secondary).
• FullContactList: Active Contacts.
• PrimaryCompanyContacts: All active company contacts (primary only).
• Project-A: All active projects
• Project-Task: All active project tasks
  • Use DependsOn=#DocMasterDetail.Project ( or other perhaps #DocRevision.ArchProject)
• UserContactList: Active Spitfire Users.
• UserEmployeeContact: Active Spitfire Users that are also employees.
• SubcontractorList: Active Primary Spitfire Vendors Contacts with project purchasing flag
• SubcontractorListWithClass:  [V2018+] Active Primary Spitfire Vendors Contacts with project purchasing flag and DependsOn vendor subtype.
• TeamContactList: Active Contacts on the project team
• VendorContactList: Active Spitfire Vendors Contacts.
• VendorAndEmpContactList: Active Vendors and Employees with Vendor IDs.
  • This is often used for pay request split payees and combined with ValidateAgainst=VendorCompanyOrEmpName.

Lookup Result Validation Names (dvnames)

If you really, truly mean it, you can specify ValidateAgainst=AllValuesAreValid.  AllValuesAreValid is a DV name with a test that literally accepts all values.

Here are some of the most common validation names.  (See xsfLookupResult for a full list)

• AlertNameAlt – accepts any unique alert name
• CodeLookup – accepts any code in the code set
• CodeLookupDescr – accepts any description in the code set (except blank)
• DocTitleAlt – accepts any unique document title
• DocTypeSubcodeAlt– accepts a code, displays the code
• DocTypeSubcode – accepts a code, displays the description
• ExternalCompanyAlt – accepts any unique external company name
• ExternalContactAlt – accepts any unique external (customer/vendor) contact name
• ProgramAlt – accepts any unique project program name
• ReferenceAlt – accepts any unique reference name (see Manage | Reference)
• RegionIdAlt – accepts any unique region
• RoleNameAlt – accepts any unique role name
• RouteNameAlt – accepts any unique predefined route name (see Manage | Routes)
• sfCompanyNameAlt – accepts any unique contact company
• sfEMailAlt  – accepts any unique contact email
• sfUserEMailAlt – accepts any unique user email address
• sfUserLoginAlt – accepts any unique user login id
• sfUserNameAlt – accepts any unique user contact name
• sfVendorNameAlt – accepts any unique vendor company name
• UCFunctionAlt – – accepts any unique capability name
• UCRoleAlt – accepts any unique role name (see System Admin | Roles)

Note: There are only a few fields in the system that reliably store contacts.  The “value” for a contact is a GUID (key) for that contact, but the user interface displays a contact (or company) name. These two part fields (with data-value and display-value) require a second attribute: ValidateTextAgainst.  Most of the DV names suitable for use with ValidateTextAgainst end in ‘alt‘ –

Examples:

• Lookup Name – PJCODE
  • DependsOn==TEPM (if you are looking up credit cards)
  • ValidateAgainst=PJCODE
• Lookup Name – CodeLookupDescr
  • DependsOn==0MyCodeSetName
  • ValidateAgainst=CodeLookupDescr
  • ShowColType=DBLookup
  • CSS=uiInstantAC

Additional Comments

Autocomplete functionality will automatically be included when your lookup is correctly configured.

 

---

KBA-01535; Last updated: August 18, 2022 at 14:08 pm