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

Allow ForceAction to be specified on PeopleFlow

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: 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
    • 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.

        Attachments

          Issue Links

            Activity

            Hide
            kbtaylor 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
            kbtaylor 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
            jawbenne 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
            jawbenne 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
            kbtaylor Kristina Taylor (Inactive) added a comment -

            Looks like the tests are passing now, thanks!

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

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: