I believe that the KimDocumentRoleMemberLookupableHelperServiceImpl needs to have a talk with its doctor...about idempotence.
From what I can tell, there's likely a requirement for the KIM Role IM doc that it allow members added to the role on the doc to be delegated from as well on the same doc. To deal with that, KimDocumentRoleMemberLookupableHelperServiceImpl takes a Role IM doc from the session (where the KIM Role IM action puts it) and pulls role members from that; if the doc in the session is nulll, it uses the regular lookup.
I first noticed this behavior when I opened a Person IM Role Doc and a Role IM role doc simultaneously. The Person IM Role doc also uses KimDocumentRoleMemberLookupableHelperServiceImpl to find delegates, and what happened was I would get back bogus role members because the lookup was looking at the role doc.
This was during consulting work for UA, and UA forked Rice for a bit. So I fixed it by pulling the doc # and the role id # from the fieldValues passed into KimDocumentRoleMemberLookupableHelperServiceImpl's search method. However, there's still a problem: if I open two Role IM docs at the same time, I think that there could be race conditions here.
Part of the issue is the name of the doc in the session - always KimConstants.KimUIConstants.KIM_ROLE_DOCUMENT_SHORT_KEY. At the very least, the docFormId should be tacked on to that. But I don't know if that's going to solve the issues the lookup presents. Therefore, I was hoping that the experts could take a look.