search cancel

The XOG of a lookup value to update a project does not resolve to the correct value

book

Article ID: 238660

calendar_today

Updated On:

Products

Clarity PPM SaaS

Issue/Introduction

When using XOG to update a custom attribute lookup value where there are similar values, the XOG is performing a close match, not an exact match. For example, if a Lookup list has two close values such as ABC1234 and ABC12345.  XOG will use a 'Like' operator (%) in the query and will find ABC12345 value to update the field, when the XOG file has the ABC1234 value specified. 

Steps to Reproduce:

1. A lookup is defined on the Project object which points to a "client" table

 

3. In the XOG, update the project as follows:

<?xml version="1.0" encoding="UTF-8"?>
<NikuDataBus xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../xsd/nikuxog_read.xsd">
  <Header action="write" externalSource="NIKU" objectType="project" version="15.9.2.910">
<Projects>
 <Project name="Client_ market_ test1_March23rd_2022" projectID="PRJ123456">
  <CustomInformation>
   <ColumnValue name="eu_client_name">CLN-000100<ColumnValue>
  </CustomInformation>
 <Project>
</Projects>
<NikuDataBus>

 

3. The project is updated successfully but with the wrong lookup value. The project was updated with 'CLN-0001000' when it should have been 'CLN-000100'.

 

Expected Results: The XOG update should perform an 'exact match'. 

Actual Results: The XOG update is the wrong value because it is performing a 'Like' operator for a close match. 

Cause

Clarity XOG is adding a wild card to the search "CLN-000100*" and coming back with the first row returned instead of an exact match. 

 

Environment

Release : 16.0.1, 16.0.2

Resolution

DE64713, fixed in 16.0.3 and 16.0.2.1

Workaround: Set the Lookup definition for the Auto Suggest 'Search' configuration to use the 'code' field.  The XOG action will then use the 'exact' match logic. 

 

Additional Information

Attachments