Uploaded image for project: 'KFS Archive'
  1. KFS Archive
  2. KFSOLD-25047

Person, role & group docs should not allow multiple docs editing the same record to be saved at the same time

    Details

    • Type: Bug Fix
    • Status: Closed
    • Priority: Major
    • Resolution: Incomplete
    • Affects Version/s: None
    • Fix Version/s: N/A
    • Labels:
      None
    • Sub-Committee:
      SYS
    • Impacted Modules:
      System
    • Rice Change Required?:
      No
    • Rice Data:
      No Change
    • API Changes?:
      No
    • Data Structures:
      No Change
    • KFS Data:
      No Change
    • Configuration Properties:
      No Change

      Description

      KFS maintenance docs don't allow you to have more than one doc affecting a record saved our enroute. Rice docs should have the same locking mechanism in place. The person doc allows multiple docs to be in saved status affecting the same person.

        Attachments

          Issue Links

            Activity

            Hide
            bsutton Barb Sutton added a comment -

            I did verify this in KTD. I was able to create two person docs for the same user and save them both. I then edited one and added an affiliation & submitted. It went to final status. I then edited the other doc to change the privacy preferences and submitted. It went to final status. Both changes were recorded in the person record.

            Maybe this is by design since the person doc does not route and goes directly to final status, but it seems problematic if you're editing a person record and save your doc to complete later, someone else could come along and make a change to that person record while your doc is saved. You would not be aware of the other change.

            Show
            bsutton Barb Sutton added a comment - I did verify this in KTD. I was able to create two person docs for the same user and save them both. I then edited one and added an affiliation & submitted. It went to final status. I then edited the other doc to change the privacy preferences and submitted. It went to final status. Both changes were recorded in the person record. Maybe this is by design since the person doc does not route and goes directly to final status, but it seems problematic if you're editing a person record and save your doc to complete later, someone else could come along and make a change to that person record while your doc is saved. You would not be aware of the other change.
            Hide
            jkeller Jonathan Keller added a comment -

            Yea - Person is a strange document. There is also the other wrinkle that roles/groups can be changed on the document. So, should it block editing of the person information if all someone else is doing is assigning them to a role.

            (I thought the edit lock happens on submit. The maintenance lock was released when the document went to FINAL, so it would not have been triggered. What would have happened on a "normal" maintenance document would have been an optimistic locking exception. But, with the abstraction of the KIM data being processed through API calls, this does not necessarily happen.)

            Show
            jkeller Jonathan Keller added a comment - Yea - Person is a strange document. There is also the other wrinkle that roles/groups can be changed on the document. So, should it block editing of the person information if all someone else is doing is assigning them to a role. (I thought the edit lock happens on submit. The maintenance lock was released when the document went to FINAL, so it would not have been triggered. What would have happened on a "normal" maintenance document would have been an optimistic locking exception. But, with the abstraction of the KIM data being processed through API calls, this does not necessarily happen.)
            Hide
            bsutton Barb Sutton added a comment -

            It seems like it should block all actions, but that's just my opinion. Apparently it has been this way all along, so maybe it shouldn't be changed. I'd welcome comments from others

            Show
            bsutton Barb Sutton added a comment - It seems like it should block all actions, but that's just my opinion. Apparently it has been this way all along, so maybe it shouldn't be changed. I'd welcome comments from others
            Hide
            bsutton Barb Sutton added a comment -

            expanded this to include role & group per issue Damon reported today.

            Show
            bsutton Barb Sutton added a comment - expanded this to include role & group per issue Damon reported today.
            Hide
            hstaplet Heather Elyea added a comment -

            per conversation between Ailish, Damon and Shannon - moving IU required release to Impl-Important (instead of Blocker)

            Show
            hstaplet Heather Elyea added a comment - per conversation between Ailish, Damon and Shannon - moving IU required release to Impl-Important (instead of Blocker)
            Hide
            kkronenb Kevin Kronenbitter added a comment -

            This is a Rice issue and should be reported in the KULRICE queue.

            Show
            kkronenb Kevin Kronenbitter added a comment - This is a Rice issue and should be reported in the KULRICE queue.

              People

              • Assignee:
                Unassigned
                Reporter:
                hstaplet Heather Elyea
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: