Question

Unable to change the locking for child class case type.

Hi Team,

In my Application the case types contain the locking as follows

X (Optimistic locking)

-- Y (Optimistic locking)

------Z(Optimistic locking)

Within Z case type, when assignments are submitted, an error is shown with error “Request has been modified on background – Please Resubmit”, upon resubmit the assignment is submitted without any issues.

Rootcause: I found that the customised error message is displayed only when the Param.ShowConflicts is true.

At backend an OOTB finishassignment is invoked with pzConflicts, this activity checks if the locking type is of optimistic and retrieves the stale instance with

openIfStale(ClipboardPage aInstancePage, boolean aCheckSecurity, boolean aLock, boolean aUnlockOnCommit, StringMap aLockInfo)

then checks if the Updatecounter is equal to the stale instance, when it is, it returns the SYSUPDATE else CONFLICT. Along with determining if it is a ValidAssignment

Attached the tracer for reference.

My observations:

  1. On the first time, the valid assignment sets as true and updatecounter as SYSUPDATE.
  2. On resubmit, the valid assignment sets as false and updatecounter as SYSUPDATE.

So, I tried changing the Z case type locking to Default. but even the locks are inherited from parent.so retains the parent optimistic locking.

What is the solution to this?

***Moderator Edit-Vidyaranjan: Updated Platform Capability***

Correct Answer
December 9, 2019 - 4:37am

As a temporary work around, changed the Locking of parent to Default. 

Con: Though casetype looks like the lock is inherited, during the run time, the lockingmode is still optimistic, so need to manually updated the pydefault casetype rules with default locking at every child level.

 

Comments

Keep up to date on this post and subscribe to comments

December 9, 2019 - 4:37am

As a temporary work around, changed the Locking of parent to Default. 

Con: Though casetype looks like the lock is inherited, during the run time, the lockingmode is still optimistic, so need to manually updated the pydefault casetype rules with default locking at every child level.