[KULRICE-8542] Person, role & group docs should not allow multiple docs editing the same record to be saved at the same time Created: 14/Nov/12  Updated: 14/Feb/13  Resolved: 30/Nov/12

Status: Closed
Project: Kuali Rice Development
Component/s: Development
Affects Version/s: None
Fix Version/s: 2.1.3
Security Level: Public (Public: Anyone can view)

Type: Bug Fix Priority: Major
Reporter: Barb Sutton Assignee: Claus Niesen
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
cloned from KFSOLD-25047 Person, role & group docs should not ... Closed
discovered KULRICE-8622 Fix locking of Agenda Editor View Closed
is duplicated by KFSOLD-22958 Role, Group & Person don't do mainten... Closed
Similar issues:
KULRICE-4575IM Person doc should only allow editing of direct group memberships
KULRICE-4516KimDocumentRoleMemberLookupableHelperServiceImpl confused by multiple docs
KULRICE-7178When editing a role, the app allows you to add the same user multiple times in the assignee section.
KULRICE-8391Screen to edit multiple parameters at the same time
KULRICE-4677Person/Group/Role/Permission/Responsibility update screen Save/Submit enhancements
KULRICE-5924Rice Dev: Person and Group Maintenance documents not saving edits?
KULRICE-5694Under some circumstances lookups can return the same row multiple times
KULRICE-8760CONTRIB: Multiple complete adhoc requests should not be allowed on the same document
KULRICE-1799Figure out how to handle the potential conflict of having two different documents saving to the same join (i.e. group membership)
KULRICE-6858If editing groups or roles, it validates the existence of all members before saving the doc, even those which are "inactive"
Rice Module:
Application Requirement:
KAI Review Status: Not Required
KTI Review Status: Not Required


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.

Comment by Jessica Coltrin (Inactive) [ 15/Nov/12 ]

setting to 2.1.3 for DM review.

Comment by Claus Niesen [ 29/Nov/12 ]

I think there are a few inconsistencies in regards to preventing a document be altered if a saved version exists.

Following behavior has been observed:

KRMS Agenda Editor - last submission overrides
  Edited agenda (changed name), save
  Edited agenda (changed campus), submit
  Open saved agenda, submit
  -> name change presisted, campus was reset to original

KRMS Context - error
  Edited context (changed name), save
  Edited context (changed description), submit
  Open saved context, submit
  -> Error: This document cannot be Saved or Routed because a record with the same primary key already exists.
People Flow - error
  Edited people flow (changed name), save
  Edited people flow (changed description), submit
  Open saved people flow, submit
  -> Error: This document cannot be Saved or Routed because a record with the same primary key already exists.

Campus - error
  Edited campus (changed name), save
  Edited campus (changed short name), submit
  Open saved campus, submit
  -> Error: This document cannot be Saved or Routed because a record with the same primary key already exists.

Person - last submission overrides
  Edited person (changed principal name), save
  Edited person (changed active indicator), blanket approve
  Open saved person, blanket approve
  -> principal name change presisted, active indicator reset to original

Person - both affiliation added
  Added affiliation, save
  Added different affiliation, blanket approve
  Open saved person, blanket approve
  -> both affiliations are added
Person - last submission overrides
  Change affiliation (A) to new affiliation (B), save
  Change affiliation (A) to new affiliation (C), blanket approve
  open saved person, blanket approve
  -> the affiliation (C) overrides (B)

Do we have documentation how multiple separate document changes should be handled?

Comment by Claus Niesen [ 30/Nov/12 ]

The KIM screens are transactional documents. KNS requires custom locking code to be added to transactional documents. Since we will be converting these screens to KRAD Maintenance documents soon (Rice 2.3) we will be addressing the locking issue then.

Generated at Sat Jul 11 19:58:03 CDT 2020 using JIRA 6.1.5#6160-sha1:a61a0fc278117a0da0ec9b89167b8f29b6afdab2.