Details

    • Type: Bug Fix Bug Fix
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: 2.5.1
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Similar issues:
      KULRICE-12742KRAD Lab: Create a test case for server side validation with addWithDialog
      KULRICE-6012Allow for ajax-ified server side validation
      KULRICE-11183Server side data validation errors don't bubble up on lookup criteria fields
      KULRICE-13382Create Server Side validation tests
      KULRICE-6770Server side required error message from dictionary validation not getting variable replaced
      KULRICE-8109View validation server-side (ViewValidationService) may have problems if fields on other pages have validation issues - untested
      KULRICE-11601Rice Sampleapp Validation Server Side Test Views Required Constrain Html Space in Error Messages
      KULRICE-6903Create Validation Test for new KRAD Validation Server-side test view
      KULRICE-3637Allow EDL to determine users browser type server-side
      KULRICE-13689Fill AFT per-screen item gap: Validation Server-side Test View (old sample app)
    • Rice Team:
      Middleware
    • Sprint:
      Middleware 2.5.1 Sprint 1
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Code Review Status:
      Not Required
    • Include in Release Notes?:
      Yes
    • Story Points:
      5

      Description

      When saving a TravelAuthorizationDocument with either a Trip Begin Date or Trip End Date specified, there are no client-side validation errors while entering, but as soon as you hit Save, you get server-side validation errors for these fields. It appears that even though we are mapped to a java.util.Date, the Spring bean wrapper is interpreting this as a java.sql.Date and when we try to determine its string representation, in ValidCharactersConstraintProcessor, it gives us back a date in the yyyy-mm-dd format, which we don't currently accept.

      Ideally we would format this before validating, but a workaround that seems to work (and fix an odd logic bug) is to do the following:

      ValidCharactersConstraintProcessor.java
      protected ConstraintValidationResult doProcessValidCharConstraint(ValidCharactersConstraint validCharsConstraint, Object value, String parsedAttributeValue) throws AttributeValidationException {
      
        StringBuilder fieldValue = new StringBuilder();
        String validChars = validCharsConstraint.getValue();
      
        if (value instanceof java.sql.Date) {
          fieldValue.append(getDateTimeService().toDateString(Date.valueOf(parsedAttributeValue)));
        } else {
          fieldValue.append(ValidationUtils.getString(parsedAttributeValue));
        }
        
        ...
      }
      

      thus checking the actual type of the value and then manuvering around the problem. Not sure if this is the correct answer but it does fix my problem.

        Issue Links

          Activity

          Hide
          Kristina Taylor (Inactive) added a comment -

          This issue is related to, but not exactly the same problem, as KULRICE-11055.

          Show
          Kristina Taylor (Inactive) added a comment - This issue is related to, but not exactly the same problem, as KULRICE-11055 .
          Hide
          Kristina Taylor (Inactive) added a comment -

          Downgrading to Critical since KULRICE-11055 has solved the immediate problem. However, I still think there are potential for future bugs here. The code segment above is hacky and doesn't make sense in the current context. Object value is always a string, so there is some dead code in there. Also, if you manually set a java.util.Date field on a document, then the business rules will fail because it is set directly and not parsed through the Spring bean wrapper (see TravelAuthorizationDocumentTest where I have had to set certain date fields as java.sql.Date).

          Show
          Kristina Taylor (Inactive) added a comment - Downgrading to Critical since KULRICE-11055 has solved the immediate problem. However, I still think there are potential for future bugs here. The code segment above is hacky and doesn't make sense in the current context. Object value is always a string, so there is some dead code in there. Also, if you manually set a java.util.Date field on a document, then the business rules will fail because it is set directly and not parsed through the Spring bean wrapper (see TravelAuthorizationDocumentTest where I have had to set certain date fields as java.sql.Date ).
          Hide
          Kristina Taylor (Inactive) added a comment -

          Upon further review, I think we generally have to accept that dates will not have a good toString value so that we do have to do additional processing. Date format is highly dependent on the country where the system is working, so it needs some preprocessing to determine the right format. This has been essentially been masked by the fact that we now accept "yyyy-mm-dd" as a format, which is what Date uses as a string value. Other places may not want to allow this, so we should leave this in.

          The other assertion that there is a problem with java.util.Date seems like it has been fixed since I can't find any problem with how TravelAuthorizationDocumentTest is implemented.

          Show
          Kristina Taylor (Inactive) added a comment - Upon further review, I think we generally have to accept that dates will not have a good toString value so that we do have to do additional processing. Date format is highly dependent on the country where the system is working, so it needs some preprocessing to determine the right format. This has been essentially been masked by the fact that we now accept "yyyy-mm-dd" as a format, which is what Date uses as a string value. Other places may not want to allow this, so we should leave this in. The other assertion that there is a problem with java.util.Date seems like it has been fixed since I can't find any problem with how TravelAuthorizationDocumentTest is implemented.
          Hide
          Martin Taylor (Inactive) added a comment -

          Closing 2.5.1 Development

          Show
          Martin Taylor (Inactive) added a comment - Closing 2.5.1 Development

            People

            • Assignee:
              Kristina Taylor (Inactive)
              Reporter:
              Kristina Taylor (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Agile

                  Structure Helper Panel