adfemg
  1. adfemg
  2. ADFEMG-25

Unique Key Validator and List of Value Inconsistent User Feedback on Validation Failure

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Labels:
      None
    • Environment:

      JDeveloper 11.1.1.4.0 & 11.1.2.1.0; Windows 7 64bit.

      Description

      Summary

      No feedback is given when validation fails a on an attribute with a an Unique Key validator and an user has manually captured or selected a value from a list of values.

      When using a Unique Key Validator on an attribute on which an alternate key has been created, the behavior of user feedback when validation fails is not consistent. There is numerous references to this issue on My Oracle Support both as bugs and enhancement requests with the conclusion being that the behavior encountered is "expected".

      This already caused a lot of discussions - see the following bugs/ER:

      Bug 8255921 - ENTITY LEVEL UNIQUE KEY VALIDATION ERROR MESSAGE DOES
      NOT PROPAGATE TO UI
      Bug 8895465 - LOV CHOICE LIST ON UNIQUE KEY ATTRIBUTE NOT SHOWING
      SELECTED VALUE IN UI.
      Bug 9851604 - UNIQUE KEY VALIDATION ERROR MESSAGE IS NOT PROPAGATING TO
      UI IN COMBO BOX LOV.
      ...
      ER Bug 9583723 - ERROR MSG NOT SHOWN WHEN VALIDATION THAT USES LOV
      ATTRIBUTES FAILS

      I do not agree with this as not informing a user of a validation error is not an acceptable when measuring the quality of product we develop for our clients. Below is an explanation of what we have experienced.

      Steps to Reproduce
      1. On EO A, create a Alternate Key on attribute B.
      2. Add Unique Key validator to EO A at Entity level.
      3. Create LOV to populate attribute B. Data for LOV is from a lookup table and is not the same table referenced by EO A.
      4. Run VO A from AM.
      a. With attribute B Auto Submit = False or True.
      b. Create new record.
      c. Manually capture or select value from LOV that is a duplicate value.
      d. In both cases validation fails and an error message is displayed.
      5. Run page with VO as a form.
      a. Input Text item AutoSubmit = False
      i. Capture duplicate value manually.
      1.Click on Commit.
      2. Validation fails and error message is displayed.
      ii. Select duplicate value from LOV.
      1. Dismiss LOV.
      2. Selected value is cleared from Input Text item and no error message is displayed.
      b. Input Text item AutoSubmit = True
      i. Capture duplicate value manually.
      1. Navigate away from the Input Text item.
      2. Captured value is cleared from Input Text item and no error message is displayed.
      ii. Select duplicate value from LOV.
      1. Dismiss LOV.
      2. Selected value is cleared from Input Text item and no error message is displayed.

      Conclusion

      The fact that the captured value is cleared without providing visual feedback to a duplicate captured value is not consistent behavior when handling validation errors. Our users report this behavior as bugs and do not accept that this is expected behavior.

        Activity

        Hide
        chriscmuir added a comment -

        Thanks Leon.

        At this stage I'll keep this issue open until I've resolved the need for the documentation ER, then I'll close the issue. We can always re open it.

        Thanks for using this service, I hope you can see its value & will participate again.

        CM.

        Show
        chriscmuir added a comment - Thanks Leon. At this stage I'll keep this issue open until I've resolved the need for the documentation ER, then I'll close the issue. We can always re open it. Thanks for using this service, I hope you can see its value & will participate again. CM.
        Hide
        chriscmuir added a comment -

        Raised doc bug 14155612 seeking we add a clarification on the LOV "valid list of values" requirement to the Fusion Dev Guide 11.1.2.0.0 section 5.12.

        CM.

        Show
        chriscmuir added a comment - Raised doc bug 14155612 seeking we add a clarification on the LOV "valid list of values" requirement to the Fusion Dev Guide 11.1.2.0.0 section 5.12. CM.
        Hide
        mkoniotakis added a comment -

        about:
        >>However with regards the more generic LOV problem as described in the bugs and by Michael's blog, let me play devil's advocate. Having researched the issue Oracle's argument is that you should not provide invalid choices in the LOV which will fail validation in the first place. The LOVs assume they only have valid values in the LOV list. (this reminds me of Oracle Forms, it worked similar in nature, you had to provide a valid list of values).<<

        In oracle forms there was a property Validate From List (true/false) that you could override this behavior and create your custom validation.
        This was common practice for performance for large LOVs and for complex business logic.
        This gave also the option to have in the list, rows that would fail validation, or not to have in the list values that could be accepted.

        The issue with Entity attribute validation is that Entity is reusable in many view objects where in one view object it might be an LOV and in an other, not.

        So it is a little inconsistent the validations to be on entity level yet the LOV validation is done in view object level.

        So i would see as an enhancement related to issue ADFEMG-14 the choice, Not to validate LOV attribute value from the List so that the entity attribute validation to be fired.

        Thanks

        Show
        mkoniotakis added a comment - about: >>However with regards the more generic LOV problem as described in the bugs and by Michael's blog, let me play devil's advocate. Having researched the issue Oracle's argument is that you should not provide invalid choices in the LOV which will fail validation in the first place. The LOVs assume they only have valid values in the LOV list. (this reminds me of Oracle Forms, it worked similar in nature, you had to provide a valid list of values).<< In oracle forms there was a property Validate From List (true/false) that you could override this behavior and create your custom validation. This was common practice for performance for large LOVs and for complex business logic. This gave also the option to have in the list, rows that would fail validation, or not to have in the list values that could be accepted. The issue with Entity attribute validation is that Entity is reusable in many view objects where in one view object it might be an LOV and in an other, not. So it is a little inconsistent the validations to be on entity level yet the LOV validation is done in view object level. So i would see as an enhancement related to issue ADFEMG-14 the choice, Not to validate LOV attribute value from the List so that the entity attribute validation to be fired. Thanks
        Hide
        chriscmuir added a comment -

        Doc bug 14155612 has been addressed in the 12.1.2 release of the documentation (when it becomes publicly available).

        At this stage if there's not further comment to this issue I'll close it next time I review the issue list.

        CM.

        Show
        chriscmuir added a comment - Doc bug 14155612 has been addressed in the 12.1.2 release of the documentation (when it becomes publicly available). At this stage if there's not further comment to this issue I'll close it next time I review the issue list. CM.
        Hide
        chriscmuir added a comment -

        As per last comment, issue closed.

        CM.

        Show
        chriscmuir added a comment - As per last comment, issue closed. CM.

          People

          • Assignee:
            leond
            Reporter:
            leond
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: