Technical - Lookup Migrations

Extended attributes

The new lookups use LookupAttributeDefinitions and LookupResultAttributeDefinitions instead of lookupFields and resultFields containing FieldDefinitions. Therefore, extended attributes will need to have their FieldDefinitions updated to be LookupAttributeDefinitions and LookupResultAttributeDefinitions.

 A few notes about that:

• LookupAttributeDefinitions and LookupResultAttributeDefinitions are extensions of AttributeDefinition. In a lot of cases, converting a FieldDefinition to a LookupAttributeDefinition or LookupResultAttributeDefinition is as simple as specifying a bean whose parent is the desired AttributeDefinition of the extended attribute.

 <property name="lookupAttributeDefinitions">
     <list>
         <bean class="org.kuali.kfs.krad.datadictionary.LookupAttributeDefinition" parent="BatchFile-path"/>
         …
     </list>
</property>

• Each non-string attribute needs to declare an AttributeDefinition.Type 
• String is assumed default if type is not specified.

<bean id="BatchFile-fileSize-parentBean" abstract="true" parent="AttributeDefinition" p:name="fileSize" p:control-ref="StandardNameTextControl" p:type="INTEGER"/>

• The extended attribute may now need to override the ControlDefinition
• The main example of this is if the ControlDefinition on the AttributeDefinition of the extended attribute specifies a checkbox control but it should render as radio buttons on the lookup form (see active indicator on AccountType for an example).
• In the past, if a checkbox was specified on the AttributeDefinition, it would magically render as radio buttons on the lookup form. This is no longer the case; now you must explicitly specify on LookupAttributeDefinitionwhen a different control type is desired on the lookup form.

<property name="lookupAttributeDefinitions">
    <list>
         <bean class="org.kuali.kfs.krad.datadictionary.LookupAttributeDefinition" parent="AccountType-active" p:control-ref=GenericAttributes-genericBooleanYNBoth-lookupControl"/>
     </list>
</property>

• The LookupResultAttributeDefinition tries to make a best guess on what comparator to use (based on type) but if you want different sort behavior, you can override it using the “comparator” property.
• A point of emphasis here Is dates. By default, date ranges are going to use DateValueComparator.

LookupableHelpers

The new lookups do not use LookupableHelpers. If you have customized a LookupableHelper, please see the LookupSearchService and BusinessObjectAdminService interfaces. You may need to create an implementation of one or both of them. The LookupSearchService for a lookup is injected on the LookupDefinition. The BusinessObjectAdminService is injected on the BusinessObjectEntry.

<bean id="BatchFile-lookupDefinition-parentBean" abstract="true" parent="LookupDefinition" p:title="Batch File Lookup" p:lookupSearchService-ref="batchFileLookupSearchService">

<bean id="BatchFile-parentBean" abstract="true" parent="BusinessObjectEntry" p:businessObjectClass="org.kuali.kfs.sys.batch.BatchFile" p:name="BatchFile" p:businessObjectAdminService-ref="batchFileAdminService”…/>  

Lookup Results and CSV Exports

Previously, the number of results returned were limited by the RESULTS_LIMIT parameter and CSV exports would return the entire search results set returned. With the new lookups, the individual business object restrictions are ignored in favor of a global API result limit set at 250. As a result of this change, CSV exports are no longer an appropriate mechanism to export large sets of data. To access large data sets, it is recommended to utilize your data warehouse solution or alternatively the REST API using the pagination parameters to traverse an entire collection. Documentation on how to utilize these APIs can be found here