[midPoint] Disable instead of delete

[Pavol Mederly]

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.ActivationStatusTy
> 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