[midPoint] Question about the disputed situation

[Radovan Semancik]

Hi,

Quick answer is that the "disputed" situation is currently not that well 
supported in midPoint. There wasn't much demand amongst midPoint 
subscribers so far.

However, the upside is that there is a plenty of room for improvement :-)

Ad 1: Notification would be just another reaction to a synchronization 
situation. This should not be that difficult to develop. In fact it 
needs to implement action class in 
com.evolveum.midpoint.model.impl.sync.action package, and use existing 
notification framework in midPoint to deliver the notification. As 
always we are open to community contributions ... or new midPoint 
platform subscribers :-)

Ad 2: As you have already discovered there is a way how to do that in 
midPoint GUI - albeit it is not entirely convenient. One of the issues 
here is that we do not store the candidate matches in midPoint 
repository. So, if GUI is supposed to display the candidate matches then 
it has to re-run the correlation query. Which is possible, but it is not 
implemented yet. In fact, few years ago we have went even one step 
further: we have experimented with a recommender for account linking 
(which would be called "machine learning" system now). The idea was for 
a recommender to suggest possible matches during manual linking of 
accounts, even in generic "unmatched" case. The recommender was learning 
based on recommendations that were accepted or refused by system 
operator. This was just a very early prototype, but it produced some 
encouraging results. Unfortunately, we haven't been able to secure the 
funding to fully develop this functionality.

Ad 3: Currently, the confirmation expression is not built for this 
purpose. The idea was to use correlation query to quickly select 
candidates for a match and the use confirmation to filter them one by 
one. It would not be that difficult to implement a variant of the 
expression that will take all the candidates in a single collection. But 
it is not implemented in midPoint now. And as far as I can tell the only 
way to do this now to change midPoint source code.

Your questions suggest a really interesting extension to midPoint 
features. But such functionality is not implemented yet. So, the best 
approach that I can recommend here is to contribute the missing 
functionality or to purchase midPoint platform subscription.

-- 
Radovan Semancik
Software Architect
evolveum.com




On 02/14/2018 01:13 PM, Shilen Patel wrote:
>
> Hi,
>
> I found out how to do (2) in the UI and I’m not too worried about (1) 
> since we can always make our own UI to handle it.  So I’m mainly 
> interested in (3) now.  Let me elaborate on a use case for it.
>
> Say I want my matching logic to be based on first name, middle name, 
> last name, DOB, and a national ID.  Here are the rules (for example):
>
>  1. If first name, middle name, last name, and DOB match exactly to
>     one existing user in MidPoint, then proceed with that match.  If
>     it matches more than one user, then it needs to be looked at
>     manually (e.g. disputed state).
>  2. If the national ID matches one existing user in MidPoint, proceed
>     with that match.
>  3. If first name and last name or middle name and last name match one
>     or more users, then I would consider that a weak match and
>     somebody should evaluate it manually regardless of whether there
>     was only one match or there were multiple matches.
>
> Is this type of behavior possible?
>
> Thanks!
>
> - Shilen
>
> *From: *Shilen Patel <shilen at duke.edu>
> *Date: *Tuesday, February 13, 2018 at 9:59 AM
> *To: *"midpoint at lists.evolveum.com" <midpoint at lists.evolveum.com>
> *Subject: *Question about the disputed situation
>
> Hi folks,
>
> Say if I have an automated connector that brings new users into 
> MidPoint.  And say if my correlation and confirmation expressions are 
> pretty simple and just match using first and last name.  If I have a 
> new entry in the incoming feed that has a name that matches 2 users in 
> MidPoint, the synchronization situation becomes “disputed”.  I have a 
> few questions about that state that I’m hoping folks may have some 
> thoughts on.
>
> 1. Other than manually going through every resource in the MidPoint UI 
> and seeing if any states are “DISPUTED” in the Accounts tab, how do 
> you figure out that entries get into this state?  Is there some place 
> you can go in the UI to view all disputed entries for all resources?  
> Do folks send notifications (e.g. emails) when entries get into that 
> state?
>
> 2. Say if I figure out that an entry is in the disputed state because 
> there are 2 potential matches.  Then I manually look at those 2 
> potential matches and figure out that the 2 users are really different 
> people and that the incoming entry matches with exactly one of them.  
> How do I change that disputed state into a linked state with the match 
> that I manually figured out?
>
> 3.  Also, one more question on a slightly different topic.  For the 
> confirmation step (which occurs after correlation), is it possible to 
> send all the potential matches to some java method where I can 
> evaluate them all together?  For example, if I have 2 potential 
> matches from the correlation step but in the confirmation step, 1 of 
> the 2 is much stronger than the other, I may want to proceed with that 
> match.  However, if both are somewhat weak, I may want it to go into 
> the disputed state so somebody can look at it.  Or do you have to 
> evaluate each potential match without having knowledge on what the 
> other potential matches are?
>
> Thanks, and I appreciate any input or best practices.
>
> Thanks!
>
> - Shilen
>
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180214/865077ba/attachment.htm>