[midPoint] Delayed Disable after Deleted from Resource

[Ivan Noris]

Hi Jason,

I have just re-tested the

https://jira.evolveum.com/browse/MID-2100 "Can't use object template in
deleted synchronization action - causes removing of user attribute values"

issue and it seems to work with the current master with the setup
described in the issue. It should work also with the 3.1 release as it
was fixed by Pavol a month ago. If you can test it in your environment,
please let me know.

Thanks & regards,
Ivan

On 01/14/2015 02:53 AM, Jason Everling wrote:
> Thanks for the quick reply,
>
> I have been thinking of different ways, the easiest way I think that
> would work is to just remove inactivateFocus from the deleted
> situation and reference to a objectTemplate that sets the
> activation/validTo date which I see you created an issue already for a
> previous question of mine a while back
>
> https://jira.evolveum.com/browse/MID-2100
>
> Anyways, let me know what you find out, no rush. I am looking forward
> to the next release and I am patiently waiting while tinkering with
> all kinds of other useful things midpoint can do for us!
>
> JASON
>
> On Tue, Jan 13, 2015 at 3:28 PM, Ivan Noris <ivan.noris at evolveum.com
> <mailto:ivan.noris at evolveum.com>> wrote:
>
>     Hi,
>
>     as this seems to be quite the opposite case to what I am normally
>     doing, I'm discussing it with the developers and will post a
>     feedback to the list once I get it.
>
>
>     The opposite case I'm referring to is like this: when all roles
>     providing some account are unassigned from the user, midPoint will
>     normally delete the resource account. This can be reconfigured to
>     disable the account, or if you wish, to disable and then delete
>     the account later. This is just for reference, maybe someone on
>     the list will need this:
>     https://wiki.evolveum.com/display/midPoint/Resource+Schema+Handling%3A+Activation
>
>     We use this commonly.
>
>     So for your case I will try to get an answer from the developers
>     and see if it can be configured or if it needs to be implemented.
>     Thank you for understanding. Anyway it seems to be pretty
>     nice/usable feature.
>
>     Regards,
>     Ivan
>
>
>     On 01/12/2015 04:03 PM, Jason Everling wrote:
>>     I know you all are busy getting work done on the next release so
>>     if this requires a lot then it can wait.
>>
>>     I have a situation that I am unsure of how to go about it, I have
>>     seen examples of delayed delete after disabled so this would be
>>     something like that.
>>
>>     Within the main resource, a CSV file, it will contain only active
>>     students/faculty/staff. When a student graduates they will no
>>     longer be in the CSV resource thus I have under situations to
>>     inactivateFocus, works great, disables their accounts.
>>
>>     Now what I would like to do and where I am lost and do not know
>>     where to begin,
>>
>>     Instead of disabling their account immediately, How can I changed
>>     it so that I can add maybe a valid-to date 30 days after being
>>     deleted from the resource instead of disabling their accounts
>>     right a way.
>>
>>     Reason being, graduated students can use their accounts up to 30
>>     days after graduating then we disable them.
>>
>>     JASON
>>
>>
>>
>>     CONFIDENTIALITY NOTICE:
>>     This e-mail together with any attachments is proprietary and
>>     confidential; intended for only the recipient(s) named above and
>>     may contain information that is privileged. You should not
>>     retain, copy or use this e-mail or any attachments for any
>>     purpose, or disclose all or any part of the contents to any
>>     person. Any views or opinions expressed in this e-mail are those
>>     of the author and do not represent those of the Baptist School of
>>     Health Professions. If you have received this e-mail in error, or
>>     are not the named recipient(s), you are hereby notified that any
>>     review, dissemination, distribution or copying of this
>>     communication is prohibited by the sender and to do so might
>>     constitute a violation of the Electronic Communications Privacy
>>     Act, 18 U.S.C. section 2510-2521. Please immediately notify the
>>     sender and delete this e-mail and any attachments from your
>>     computer.
>>
>>
>>     _______________________________________________
>>     midPoint mailing list
>>     midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>>     http://lists.evolveum.com/mailman/listinfo/midpoint
>
>     -- 
>       Ing. Ivan Noris
>       Senior Identity Management Engineer
>       evolveum.com <http://evolveum.com>     evolveum.com/blog/ <http://evolveum.com/blog/>
>       _____________________________________________
>       "Semper Id(e)M Vix."
>
>
>     _______________________________________________
>     midPoint mailing list
>     midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>     http://lists.evolveum.com/mailman/listinfo/midpoint
>
>
>
>
>
> CONFIDENTIALITY NOTICE:
> This e-mail together with any attachments is proprietary and
> confidential; intended for only the recipient(s) named above and may
> contain information that is privileged. You should not retain, copy or
> use this e-mail or any attachments for any purpose, or disclose all or
> any part of the contents to any person. Any views or opinions
> expressed in this e-mail are those of the author and do not represent
> those of the Baptist School of Health Professions. If you have
> received this e-mail in error, or are not the named recipient(s), you
> are hereby notified that any review, dissemination, distribution or
> copying of this communication is prohibited by the sender and to do so
> might constitute a violation of the Electronic Communications Privacy
> Act, 18 U.S.C. section 2510-2521. Please immediately notify the sender
> and delete this e-mail and any attachments from your computer.
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint

-- 
  Ing. Ivan Noris
  Senior Identity Management Engineer & IDM Architect
  evolveum.com                     evolveum.com/blog/
  ___________________________________________________
  "Semper Id(e)M Vix."

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