Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.4
    • Fix Version/s: 2.5
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Similar issues:
      KULRICE-5650Add ability to specify PeopleFlows on RequestsNode
      KULRICE-7349PeopleFlow: UI allows attempted creation of duplicate PeopleFlows
      KULRICE-9228Allow method to call to not be specified on URL
      KULRICE-8534PeopleFlow Maintenance does not allow for Role selection
      KULRICE-10885Allow for form post mapping to be specified per page
      KULRICE-4578Allow for default frame size to be specified
      KULRICE-7983Allow hidden criteria fields to be specified from quickfinder widget
      KULRICE-11145Allow for container fixed or fluid to be specified at view level
      KULRICE-10200Allow full min file path to be specified when using manual theme configuration
      KULRICE-8156KRMSConfigurer needs the ability to specify a datasource
    • Rice Module:
      KEW
    • Application Requirement:
      KPME
    • Sprint:
      Core 2.5.0-m6 Sprint 2, Core 2.5.0-m7 Sprint 1
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Code Review Status:
      Not Required
    • Include in Release Notes?:
      Yes
    • Story Points:
      3

      Description

      Currently, in PeopleFlowRequestGeneratorImpl.generateRequestForMember, when creating the root action request, ForceAction is always defaulted to Boolean.TRUE. It would be nice if this were allowed to be configured on the PeopleFlow screens.

      Success user story: As a user of peopleflow screens, I would like ForceAction to be configurable on the PeopleFlow screens so that I can set it to false if needed.

        Issue Links

          Activity

          Hide
          Kristina Taylor (Inactive) added a comment - - edited

          In a discussion about version compatibility, James Bennett thought that it might be in error that forceAction, while not required, is a boolean instead of a Boolean, which can be nulled. He is going to attach a unit test which will display this problem to this issue. He also said that this will likely make the ITs fail (which is good since we are detecting the problems).

          Show
          Kristina Taylor (Inactive) added a comment - - edited In a discussion about version compatibility, James Bennett thought that it might be in error that forceAction , while not required, is a boolean instead of a Boolean , which can be nulled. He is going to attach a unit test which will display this problem to this issue. He also said that this will likely make the ITs fail (which is good since we are detecting the problems).
          Hide
          James Bennett added a comment - - edited

          The ITs for version compatibility are already failing due to this change and you can see it here:

          https://ci.kuali.org/view/rice/view/2.5/view/list/job/rice-2.5-test-integration-mysql/242/testReport/junit/org.kuali.rice.vc.kew/KewWsdlCompatibilityTest/compareKewApiWsdls/

          There are several faliures related to DocumentProcessingOptions which were caused by an invalid IU contribution, but there are a few in there related to the PeopleFlowMemberType as well. This fails because when the WSDL type is generated for the PeopleFlowMember class the new property is a primitive boolean. That can't have a null value so even though it isn't required the WSDL still specifies that minOccurs="1" for the property you added. The correct way to handle this would be to use a Boolean object instead since it can be null, and then handle the cases where it is null in the code. I just made this same change for KULRICE-13156 with this commit:

          https://fisheye.kuali.org/viewrep/rice/trunk/rice-middleware/kew/api/src/main/java/org/kuali/rice/kew/api/document/DocumentProcessingOptions.java?r1&r2=48204

          I described why I think my fix is null-safe on that issue and I attached a test case I wrote up to see exactly how JAXB would handle the property in a few different cases. I attached the test here, but it doesn't fail the way I thought it would before I wrote the test. You can use it to see how JAXB handles the unmarshalling from XML if you find it useful though.

          Show
          James Bennett added a comment - - edited The ITs for version compatibility are already failing due to this change and you can see it here: https://ci.kuali.org/view/rice/view/2.5/view/list/job/rice-2.5-test-integration-mysql/242/testReport/junit/org.kuali.rice.vc.kew/KewWsdlCompatibilityTest/compareKewApiWsdls/ There are several faliures related to DocumentProcessingOptions which were caused by an invalid IU contribution, but there are a few in there related to the PeopleFlowMemberType as well. This fails because when the WSDL type is generated for the PeopleFlowMember class the new property is a primitive boolean. That can't have a null value so even though it isn't required the WSDL still specifies that minOccurs="1" for the property you added. The correct way to handle this would be to use a Boolean object instead since it can be null, and then handle the cases where it is null in the code. I just made this same change for KULRICE-13156 with this commit: https://fisheye.kuali.org/viewrep/rice/trunk/rice-middleware/kew/api/src/main/java/org/kuali/rice/kew/api/document/DocumentProcessingOptions.java?r1&r2=48204 I described why I think my fix is null-safe on that issue and I attached a test case I wrote up to see exactly how JAXB would handle the property in a few different cases. I attached the test here, but it doesn't fail the way I thought it would before I wrote the test. You can use it to see how JAXB handles the unmarshalling from XML if you find it useful though.
          Hide
          Kristina Taylor (Inactive) added a comment -

          Looks like the tests are passing now, thanks!

          Show
          Kristina Taylor (Inactive) added a comment - Looks like the tests are passing now, thanks!

            People

            • Assignee:
              Peter Giles (Inactive)
              Reporter:
              Jeremy Hanson
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Agile

                  Structure Helper Panel