User Account gets Locked upon logging into End User Menu
I have a custom workflow that checkout's a user view for provisioning.
Prior to the check out.. I invoke a getLock() and isLocked() on the LockInfo Object returned by getLock(). I suspend my workflow until isLocked() returns false.
isLocked() always returns true if the provisioning workflow was initiated by the user from a custom process off of the End User Menu.
What I found is (via lh console). When a user logs into End User Menu (tested this on both the canned/OOTB End User Menu and my custom End User Menu), IdM automatically sets a 5 min lock on the user. Therefore, if a user initates a provisioning request from my custom end user menu , inherently calling my custom provision workflow, there will always be at least a 5 min delay before the next manual action (e.g. approval or email notification).
Is there a reason for this initial lock ? Can this be disabled or reduced from 5 min?
# 2
Further findings:
I tried recreating this in 2 more vanilla instances of IdM. One is running IdM 6.0 on tomcat 5 and the other is IdM 7.0 on tomcat 5.
This (accounts getting locked upon login to end user menu) does not occur in IdM 6.0. This only happens in IdM 7.0 and my assumption is that it is related to the new "End User Dashboard" in 7.0.
Please advise...
# 5
What I noticed is that, if the custom workflow checks out the view then checks in the view at the end, the user view gets unlocked. My workaround was to add an activity in the workflow that unlocks the view if the flow doesn't end with checkin process. I think the purpose of locking the view during view checkout is to prevent more than one person to update the view at the same time. However, I also find it is annoying that the user gets locked when s/he logs into the end user page, even if s/he didn't launch any self-update/request process yet.
# 6
I think this is more than just an annoyance, I think I agree that this is a bug.
If you think about it, someone doing an upgrade to IdM 7.0 importing their current (maybe developed on IdM 5.5 or 6) code base (WF's, scheduled tasks, etc...) which may not have code to explicitly "break" locks would have to go an update every piece of code that check's out a view to determine if it is locked due to an a new end user session created.
In any case, i have submitted the bug and will keep you all posted in this thread once I hear back from Sun.
