Modern UX Lookup not displaying correctly

Products

Clarity PPM SaaS Clarity PPM On Premise Clarity FedRAMP

Issue/Introduction

A Parameterized/Dynamic lookup value does not display correctly in Modern UX (MUX), even though the underlying database value is correct and Classic UX displays it correctly. This can appear in a few different ways:

The value changes back to the first value in the list of values in Modern UX.
The Grid view of Modern UX shows a different value than the value shown on the Details page for the same record.
A value selected in the MUX grid appears momentarily and then disappears — the field shows blank/empty after the save completes and on any subsequent reload, even though Classic UX and the database confirm the value was saved correctly.

Environment

Release : 15.9.x, 16.x

Cause

This symptom has been observed with three distinct causes. All three share the same underlying mechanism: a filter condition in the lookup's NSQL query that is meant to apply only while a user is actively browsing/picking a new value is being incorrectly re-applied when Clarity redisplays a value that has already been saved on the record.

Missing @BROWSE-ONLY: tag around a filtering condition. The lookup query filters on a condition (e.g., active/inactive status, or a role/security constraint) without wrapping it in @BROWSE-ONLY: ... :BROWSE-ONLY@. When MUX redisplays an already-saved value, it re-evaluates the same filter, and if the saved value no longer satisfies that filter, MUX cannot resolve a label for it and the field appears blank or reverts to the first list value.
Non-unique hidden key in the lookup query. If the hidden key column returned by the query is not unique per row, MUX's grid view and details page can resolve two different values for the same underlying record, causing the two views to disagree.
Self-referencing exclusion/uniqueness clause . The lookup query contains a clause that excludes values already used by sibling records under the same parent object, typically written as a NOT EXISTS (or equivalent) subquery against the sub-object's own underlying table, for example:
```
AND NOT EXISTS (
     SELECT 1 FROM <sub_object_table> s
     WHERE s.odf_parent_id = @WHERE:PARAM:USER_DEF:INTEGER:ODF_PARENT_ID@
     AND s.<lookup_column> = l.lookup_code
```

This clause is intended to apply only while browsing — so a value already chosen on one sibling record cannot be chosen again on another. However, once a record itself saves a value, that same record's own row now satisfies the NOT EXISTS check as
"already used" — by itself. When MUX redisplays the record, it re-evaluates this same clause to resolve the display label, the record excludes its own saved value, and the field renders blank. The database value is correct throughout; only the MUX label resolution fails. Classic UX is not affected because it resolves the display label through a different code path that does not re-apply this exclusion clause.

Resolution

For Cause 1 and 3 : Wrap the filtering/exclusion condition — and only that condition — in @BROWSE-ONLY: ... :BROWSE-ONLY@. Leave @FILTER@ and any other required clauses outside the tag. This preserves the exclusion while a user is actively browsing/picking a value, but skips it when Clarity is simply redisplaying an already-saved value

SELECT
 @SELECT:l.lookup_code:code@,
 @SELECT:l.name:name@,
 @SELECT:l.last_updated_date:last_updated_date@,
 @SELECT:C.ID:LANGUAGE_ID@,
 @SELECT:L.LANGUAGE_CODE:LANGUAGE_CODE@
FROM cmn_lookups_v l,
 cmn_languages c
WHERE @FILTER@
AND l.lookup_type = '<LOOKUP_TYPE>'
AND l.language_code = @where:param:language@
AND l.language_code = c.language_code
@BROWSE-ONLY:
AND NOT EXISTS (
  SELECT 1
  FROM <sub_object_table> s
  WHERE s.odf_parent_id =
    @WHERE:PARAM:USER_DEF:INTEGER:ODF_PARENT_ID@
  AND s.<lookup_column> = l.lookup_code
)
:BROWSE-ONLY@

After this change:

Opening the dropdown/picker still correctly hides values already used by sibling records.
Redisplaying an already-saved value on a record skips the exclusion entirely, so a record can never exclude its own value.

For cause 2: Verify the hidden key returned by the query is unique per row. If the display issue persists after confirming uniqueness, contact Broadcom Support for further analysis.