Uploaded image for project: 'Kuali Rice Development'
  1. Kuali Rice Development
  2. KULRICE-12386

KRAD Lookup with exact date criteria doesn't match records

    Details

    • Type: Bug Fix
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.4
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Rice Module:
      KRAD
    • Sprint:
      2.4.0-rc1 Sprint 8
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Code Review Status:
      Not Required
    • Include in Release Notes?:
      Yes

      Description

      The date of lookup with an exact date criteria field doesn't match existing records.

      • KRAD Demo -> Travel Account Lookup
      • Enter an existing "Date Created" (eg 04/01/2014) and search
        • Notice that no records are returned even though they do exist.

        Attachments

          Issue Links

            Activity

            Hide
            mztaylor Martin Taylor (Inactive) added a comment -

            Tested on env14 and reproduced issue. Checked on local environment manually and using DemoTravelAccountLookUpAft:testTravelAccountLookUp. CREATE_DT is a datetime field in the TRV_ACCT table. Appears the field is being evaluated as datetime comparison and not relaxed date comparison. Found the predicate between evaluated was:

            createDate, 2014-04-08T00:00:00.000-04:00
            

            The date was formatted as such by the CriteriaSupportUtils.determineCriteriaValue

            To confirm it is an exact datetime check, replaced LookupCriteriaGeneratorImpl.addDateRangeCriteria handles of equals to check between beginning of the day and end of the day and worked correctly.

            Show
            mztaylor Martin Taylor (Inactive) added a comment - Tested on env14 and reproduced issue. Checked on local environment manually and using DemoTravelAccountLookUpAft:testTravelAccountLookUp. CREATE_DT is a datetime field in the TRV_ACCT table. Appears the field is being evaluated as datetime comparison and not relaxed date comparison. Found the predicate between evaluated was: createDate, 2014-04-08T00:00:00.000-04:00 The date was formatted as such by the CriteriaSupportUtils.determineCriteriaValue To confirm it is an exact datetime check, replaced LookupCriteriaGeneratorImpl.addDateRangeCriteria handles of equals to check between beginning of the day and end of the day and worked correctly.
            Hide
            mztaylor Martin Taylor (Inactive) added a comment -

            Simplest solution is changing the LookupCriteriaGeneratorImpl to handle single date checks as between date at midnight and date at 11:59pm:

            addBetween(criteria, propertyName, parseDate(LookupUtils.scrubQueryCharacters(propertyValue)), parseDateUpperBound(LookupUtils.scrubQueryCharacters(propertyValue)));
            

            but I have some reservations if this will then affect the use of date with time searches criteria or performance on search results by using a date range over a single value.

            Show
            mztaylor Martin Taylor (Inactive) added a comment - Simplest solution is changing the LookupCriteriaGeneratorImpl to handle single date checks as between date at midnight and date at 11:59pm: addBetween(criteria, propertyName, parseDate(LookupUtils.scrubQueryCharacters(propertyValue)), parseDateUpperBound(LookupUtils.scrubQueryCharacters(propertyValue))); but I have some reservations if this will then affect the use of date with time searches criteria or performance on search results by using a date range over a single value.

              People

              • Assignee:
                mztaylor Martin Taylor (Inactive)
                Reporter:
                cniesen Claus Niesen
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - 6 hours
                  6h
                  Remaining:
                  Remaining Estimate - 0 minutes
                  0m
                  Logged:
                  Time Spent - 6 hours
                  6h