[midPoint] Disable instead of delete
Richard Frovarp
richard.frovarp at ndsu.edu
Wed Aug 26 00:47:52 CEST 2020
The bit I see under Mapping evaluation is:
Mapping - OUTBOUND (Target - UAMS Test Table):
activation/effectiveStatus -> activation/administrativeStatus
| Strength: STRONG
| Input administrativeStatus: (no values)
| Input legal: true
| Input assigned: false
| Input focusExists: true
| Input input: ENABLED
| Condition: true -> true
| Time validity: true
| Output: ENABLED
So legal is true, and input goes to enabled. However, assigned is false
when I am not part of the org that grants the resource. However, when I
am part of the org that grants the resource:
Mapping - OUTBOUND (Target - UAMS Test Table):
activation/effectiveStatus -> activation/administrativeStatus
| Strength: STRONG
| Input administrativeStatus: (no values)
| Input legal: true
| Input assigned: true
| Input focusExists: true
| Input input: ENABLED
| Condition: true -> true
| Time validity: true
| Output: ENABLED
Assigned is true. So assigned appears to follow what I want. It's
slightly confusing to me because:
legality: set to true if the object is legal (based on assignment
evaluation). See Assignment
So I don't quite understand why legal would be true when assigned is
false. But it appears if I change the legal part in the if check to
assigned, I will get the results I want?
On Tue, 2020-08-25 at 21:50 +0000, Richard Frovarp wrote:
> 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.ActivationSt
> > > at
> > > 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
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> https://lists.evolveum.com/mailman/listinfo/midpoint
More information about the midPoint
mailing list