DRYD-1989 > Search (New) > Structured date field group is not blank returns all records

[spirosdi]

What does this do?

• For structured dates, it adds converting OP_NULL, OP_NOT_NULL to an nxql condition that checks if all fields are null/not null. Except the scalarvaluescomputed field which is false by default.
• It fixes an already existing correlation issue of group conditions. For repeating groups that contain non repeating groups, correlation doesn't work. In that case the nxql path does not end but still contains a wildcard. F.e: collectionobjects_common:assocDateGroupList/*/assocStructuredDateGroup. This case was ignored before the fix because correlation checked if the nxqlPath ends with wildcard: https://github.com/collectionspace/cspace-ui.js/pull/310/changes#diff-5785c6e3d60833bc1054cff731c6d54a1107c5f56b2f99220f10729f14410418L647 leading to uncorrelated paths (wildcards are not numbered).

Why are we doing this? (with JIRA link)
We want to support is blank/is not blank operators for structured dates. We also should fix the issue of missing correlations: https://collectionspace.atlassian.net/browse/DRYD-1989

How should this be tested? Do these changes have associated tests?

Testing is blank/is not blank operator of structured dates.
Please create a collection object with a structured date. Using the new advanced search, search by that structured date applying the is not blank operator. The object should be included in the results. Then edit the collection object, delete the structured date and search using the is blank operator. Confirm that the object is included in the results.

Testing the correlation fix.

1. Using the new advanced search form, search for a structured date that is inside a repeating group. In core, those are the “Associated date value” and the “Non-textual inscription date”
2. The operator should be one that includes the group operator by default. Such as the "is between"
3. Perform such a search and confirm that the nxql path in the network request is correlated properly. It should include numbered wildcards instead of plain wildcards. Like this:

((collectionobjects_common:assocDateGroupList/*1/assocStructuredDateGroup/dateEarliestScalarValue <= TIMESTAMP "2026-01-17T00:00:00.000Z" 
AND 
collectionobjects_common:assocDateGroupList/*1/assocStructuredDateGroup/dateLatestScalarValue > TIMESTAMP "2026-01-16T00:00:00.000Z"))

instead of this:

((collectionobjects_common:assocDateGroupList/*/assocStructuredDateGroup/dateEarliestScalarValue <= TIMESTAMP "2026-01-17T00:00:00.000Z" 
AND 
collectionobjects_common:assocDateGroupList/*/assocStructuredDateGroup/dateLatestScalarValue > TIMESTAMP "2026-01-16T00:00:00.000Z"))

Dependencies for merging? Releasing to production?
No dependencies

Has the application documentation been updated for these changes?
We will need to update the documentation

Did someone actually run this code to verify it works?
@spirosdi ran it locally.

[mikejritter]

Tested both cases and the ui displayed the expected results.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 0.00%. Comparing base (f25a280) to head (0466aa1).
⚠️ Report is 1 commits behind head on develop.

❌ Your project status has failed because the head coverage (0.00%) is below the target coverage (95.00%). You can increase the head coverage or adjust the target coverage.

Additional details and impacted files

@@      Coverage Diff       @@
##   develop   #310   +/-   ##
==============================
==============================

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.