Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-7744

MAINTENANCE: New person record stuck in ENROUTE status

    Details

    • Type: Bug Fix Bug Fix
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Won't Fix
    • Affects Version/s: 2.1.1
    • Fix Version/s: 2.1.1
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Environment:
      Chrome browser
    • Similar issues:
      KULRICE-4573blanket approve a kim person doc gets stuck in enroute status
      KULRICE-12429Editing PeopleFlow Document Stuck in EnRoute Status
      KULRICE-8542Person, role & group docs should not allow multiple docs editing the same record to be saved at the same time
      KULRICE-8644When trying to copy certain permissions, doc gets stuck 'Enroute'
      KULRICE-8673Copy Permission not validating New Copy for duplicate Permission Name
      KULRICE-12128Error creating new Permission
      KULRICE-12129Error creating a new Responsibility
      KULRICE-9051AFT Failure WorkFlow Route Rules Blanket Approval submit status results in Enroute, not Final
      KULRICE-9426Ad Hoc to Person unauthroized to take action on document possible
      KULRICE-12243Stuck Documents Report
    • Rice Module:
      KIM
    • Application Requirement:
      KC
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      1) Completed doc to create new person record (id: brtest)
      2) Clicked Submit
      3) System responded with "Document was successfully submitted."
      4) Returned to System Admin tab / Person search
      5) Attempted to retrieve "brtest" person
      EXPECTED RESULT: Able to view/edit "brtest" person record
      ACTUAL RESULT: Person record not returned in search; checked document status, found it in ENROUTE with nothing pending in the route log.
      FYI: I tried recalling the document and blanket approving, which ended in same result.
      FYI: This was consistent behavior in Wkly, Trunk and Dly environments. The listed document number is in the Wkly environment.

        Activity

        Hide
        Brian Rafferty (Inactive) added a comment -

        UPDATE: As of 7/25, I was able to complete (to Final) new user records in wkly. As of 7/26, new user records still stay in ENROUTE status.

        Show
        Brian Rafferty (Inactive) added a comment - UPDATE: As of 7/25, I was able to complete (to Final) new user records in wkly. As of 7/26, new user records still stay in ENROUTE status.
        Hide
        Brian Rafferty (Inactive) added a comment - - edited

        UPDATE 7/30: After wkly rebuild of 7/27, unable to complete (to FINAL) new person records (build 18549). Same results in dly and trunk.

        Show
        Brian Rafferty (Inactive) added a comment - - edited UPDATE 7/30: After wkly rebuild of 7/27, unable to complete (to FINAL) new person records (build 18549). Same results in dly and trunk.
        Hide
        Peter Giles (Inactive) added a comment -

        I've got KC bundled running on my workstation now and I've successfully reproduced the issue. Now to debug it...

        Show
        Peter Giles (Inactive) added a comment - I've got KC bundled running on my workstation now and I've successfully reproduced the issue. Now to debug it...
        Hide
        Peter Giles (Inactive) added a comment -

        I think I have tracked this one down. It appears that the states of some of the sequences in the dataset are invalid. For example, KRIM_ENTITY_NM_ID_S was giving next values that were duplicates of ENTITY_NM_IDs in KRIM_ENTITY_NM_T. That was causing OptimisticLockExceptions when it tried to insert new ones using those IDs, and failing to do so since there was already a row in there with a version number set.

        Show
        Peter Giles (Inactive) added a comment - I think I have tracked this one down. It appears that the states of some of the sequences in the dataset are invalid. For example, KRIM_ENTITY_NM_ID_S was giving next values that were duplicates of ENTITY_NM_IDs in KRIM_ENTITY_NM_T. That was causing OptimisticLockExceptions when it tried to insert new ones using those IDs, and failing to do so since there was already a row in there with a version number set.
        Hide
        Peter Giles (Inactive) added a comment -

        Another example is KRIM_ENTITY_EMP_ID_S. I can see in the contents of devdb_mysql_500.zip:
        in mysql/kr500stg/sql/schema.sql:

        ALTER TABLE KRIM_ENTITY_EMP_ID_S auto_increment = 10088
        /

        and then in mysql/kc500ci/datasql/KRIM_ENTITY_EMP_INFO_T.sql

        INSERT INTO KRIM_ENTITY_EMP_INFO_T (ACTV_IND,BASE_SLRY_AMT,EMP_ID,EMP_REC_ID,EMP_STAT_CD,EMP_TYP_CD,ENTITY_EMP_ID,ENTITY_ID,LAST_UPDT_DT,OBJ_ID,PRMRY_DEPT_CD,PRMRY_IND,VER_NBR)
          VALUES ('Y',100000,'iacucadmin-card','1','A','P','10094','10094',STR_TO_DATE( '20120807151141', '%Y%m%d%H%i%s' ),'C6B2BF38130724EAE040DC0A1F8A4186','IN-CARD','Y',1)
        /

        It's a bit hard to parse that last one, but the ENTITY_EMP_ID is set to 10094. I'm guessing there are a bunch of similar issues with these tables and sequences.

        Show
        Peter Giles (Inactive) added a comment - Another example is KRIM_ENTITY_EMP_ID_S. I can see in the contents of devdb_mysql_500.zip: in mysql/kr500stg/sql/schema.sql: ALTER TABLE KRIM_ENTITY_EMP_ID_S auto_increment = 10088 / and then in mysql/kc500ci/datasql/KRIM_ENTITY_EMP_INFO_T.sql INSERT INTO KRIM_ENTITY_EMP_INFO_T (ACTV_IND,BASE_SLRY_AMT,EMP_ID,EMP_REC_ID,EMP_STAT_CD,EMP_TYP_CD,ENTITY_EMP_ID,ENTITY_ID,LAST_UPDT_DT,OBJ_ID,PRMRY_DEPT_CD,PRMRY_IND,VER_NBR) VALUES ('Y',100000,'iacucadmin-card','1','A','P','10094','10094',STR_TO_DATE( '20120807151141', '%Y%m%d%H%i%s' ),'C6B2BF38130724EAE040DC0A1F8A4186','IN-CARD','Y',1) / It's a bit hard to parse that last one, but the ENTITY_EMP_ID is set to 10094. I'm guessing there are a bunch of similar issues with these tables and sequences.
        Hide
        Jessica Coltrin (Inactive) added a comment -

        release notes are generated. closing issues.

        Show
        Jessica Coltrin (Inactive) added a comment - release notes are generated. closing issues.

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 4 days
              4d
              Remaining:
              Remaining Estimate - 4 days
              4d
              Logged:
              Time Spent - Not Specified
              Not Specified

                Structure Helper Panel