[midPoint] Disable instead of delete

Richard Frovarp richard.frovarp at ndsu.edu
Tue Aug 25 23:50:01 CEST 2020


Done. Don't entirely understand what the short output from the GUI is
telling me. And that's one giant XML document. I have sanitized the
doc, mostly just replacing attributes about me. Also deleted credential
blocks that showed up in there. https://wings.it.ndsu.edu/trace.zip

Setup:

1) Grouper bits from grouper-demo are installed and appear to work,
this involves a function library, user template, org, a metarole, and
an archetype.
2) Grouper group is turned into a midPoint org by grouper connector
3) midPoint org has a inducement on it to a DatabaseTableConnector
resource (was CSV, switching over to something more useful to me,
result is the same)
4) Resource has simulated disable capability and the configuration from
disable instead of delete
5) Add person to Grouper group, they show up in the midPoint org and
with a projection to the resource and in the table enabled.
6) Remove person from Grouper group, they are removed from midPoint org
and show up in the table disabled.
7) Trigger a different resource on that user and they end back up
enabled and not in the midPoint org.

We have one resource that takes people from a different midPoint org
and populates a table using the DatabaseTable connector for use as the
subject table by Grouper. That's the Target - Grouper NDSU Subjects
resource. I stuck the trace bit on the live sync task for that
resource. I suspended that task, updated the last modified on my row in
that table, ran the live sync task, then suspended to generate the
trace.

Maybe this is normal, but I find this odd in what the GUI will spit
out:

Clockwork run with focus '40506'
  Clockwork click: state INITIAL, execution wave 0, projection wave 0
    Focus loaded
    Mapping - TEMPLATE (grouper-template-user): name -> assignment
    Mapping - OUTBOUND (Target - UAMS Test Table): legal ->
shadowExists
    Mapping - OUTBOUND (Target - UAMS Test Table):
activation/effectiveStatus -> activation/administrativeStatus
    Mapping - OUTBOUND (Target - Grouper NDSU Subjects):
$user/extension/username -> attributes/email

It goes from the template, to the disabled resource, then to the
resource triggered in the live sync. I tried adding a trace to the
Grouper Async task, but that didn't yield any log files.

Thanks,
Richard


On Tue, 2020-08-25 at 17:44 +0200, Pavol Mederly wrote:
> This looks OK to me. The "legal" variable should be false if there is
> no 
> assignment creating particular account.
> 
> (Although the code is a bit more complex than this. So there might be
> a 
> bug in midPoint or some strange misconfiguration on your side.)
> 
> If you would create and send us so called trace file (see 
> 
https://wiki.evolveum.com/display/midPoint/Troubleshooting+with+traces,
>  
> in particular the section "Recording traces for background tasks"),
> I 
> would try to find a couple of minutes to analyze it.
> 
> In your particular situation - if the issue emerges during 
> reconciliation of a different resource, then you'd need to include
> XML 
> snipped starting with "mext:tracing" to the reconciliation task for
> that 
> resource. Note that tracing will slow down the processing
> significantly, 
> so you need the reconciliation to execute only a couple (tens at
> most) 
> of records.
> 
> Best regards,
> 
> Pavol Mederly
> Software developer
> evolveum.com
> 
> On 25/08/2020 17:29, Richard Frovarp wrote:
> > I'm copying the
> > 
https://wiki.evolveum.com/display/midPoint/Disable+instead+of+Delete
> > without the extra "Even more" complex logic:
> > 
> > <activation>
> >    <existence>
> >      <outbound>
> >        <strength>weak</strength>
> >        <expression>
> >          <path>$focusExists</path>
> >        </expression>
> >      </outbound>
> >    </existence>
> >    <administrativeStatus>
> >      <outbound>
> >        <strength>strong</strength>
> >        <expression>
> >          <script>
> >            <code>
> >              import
> > com.evolveum.midpoint.xml.ns._public.common.common_3.ActivationStat
> > usTy
> > pe;
> >              if (legal) {
> >                input;
> >              } else {
> >                ActivationStatusType.DISABLED;
> >              }
> >            </code>
> >          </script>
> >        </expression>
> >      </outbound>
> >    </administrativeStatus>
> > </activation>
> > 
> > The disabled bit works. My confusion comes from the other resource
> > reconciling causing this one to go to enabled. Still trying to wrap
> > my
> > head around legal. Guessing under that condition input become
> > enabled.
> > 
> > On Tue, 2020-08-25 at 17:18 +0200, Pavol Mederly wrote:
> > > Hello Richard,
> > > 
> > > I have no particular experience with this disable-instead-of-
> > > delete
> > > configuration but I think it should be doable.
> > > 
> > > Could you, please, share relevant parts of your configuration? I
> > > mean
> > > mainly the activation mappings for your resources.
> > > 
> > > Best regards,
> > > 
> > > Pavol Mederly
> > > Software developer
> > > evolveum.com
> > > 
> > > On 25/08/2020 01:12, Richard Frovarp wrote:
> > > > I'm trying to figure out how to do disable instead of delete on
> > > > a
> > > > single resource. I've read the wiki, and mostly, kinda, sort of
> > > > understand it. In fact, I have it working as I think it is
> > > > intended
> > > > to
> > > > work. Which isn't how I need it to work and I'm getting stuck
> > > > on
> > > > terms
> > > > I think.
> > > > 
> > > > I have a test resource that is an inducement on an org that is
> > > > populated by Grouper. The resource is a CSV file with a
> > > > simulated
> > > > disable capability. I add someone to the Grouper group, the
> > > > async
> > > > handler adds them to the org, and they are added to the CSV.
> > > > Life
> > > > is
> > > > good. I remove them from the Grouper group, they are removed
> > > > from
> > > > the
> > > > org, and the user has a disabled administrative status on their
> > > > shadow
> > > > on the resource. The user has an undefined administrative
> > > > status,
> > > > and
> > > > the other resources which don't have the disabled capability
> > > > are
> > > > however they are.
> > > > 
> > > > However, the next morning an unrelated reconciliation on a
> > > > different
> > > > resource runs and that turns the administrative status for the
> > > > CSV
> > > > resource back to enabled. That's not what I want. I want the
> > > > resource
> > > > to remain in the disabled state. I think this is because it is
> > > > setting
> > > > the user back to enabled, and the example makes it so that the
> > > > resource
> > > > follows the user. That's not what I want in my instance. I may
> > > > be
> > > > disabling a resource because the person is no longer an
> > > > employee
> > > > and is
> > > > only a student. Thus their employee resources are disabled for
> > > > a
> > > > period
> > > > of time before we delete them.
> > > > 
> > > > What am I missing? The other key here is that if they are added
> > > > back to
> > > > the Grouper resource, they should be set back to enabled.
> > > > 
> > > > Thanks,
> > > > Richard
> > > > _______________________________________________
> > > > midPoint mailing list
> > > > midPoint at lists.evolveum.com
> > > > https://lists.evolveum.com/mailman/listinfo/midpoint
> > > 
> > > _______________________________________________
> > > midPoint mailing list
> > > midPoint at lists.evolveum.com
> > > https://lists.evolveum.com/mailman/listinfo/midpoint
> > 
> > _______________________________________________
> > midPoint mailing list
> > midPoint at lists.evolveum.com
> > https://lists.evolveum.com/mailman/listinfo/midpoint
> 
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> https://lists.evolveum.com/mailman/listinfo/midpoint


More information about the midPoint mailing list