[midPoint] New notification, need to verify my code

[Jason Everling]

It's OK, It was working either way so I just went with it. I am using it in
user notifications combined with the other snippet I posted a few days back
about adding a class to user notifications. When a person gets an email we
found it easier to let them know what their current status is because they
would ask us about it and so this way when they get an email they will know
exactly if their account was disabled/enabled.

I had to make a few adjustments from the last batch of notifications to new
users and to graduating users but all in all it has been a wonderful new
addition! I find myself not writing any more emails regarding account
status changes or additions and a lower volume of account related support
tickets.

Thanks!
JASON

JASON

On Mon, Jan 25, 2016 at 10:10 AM, Pavol Mederly <mederly at evolveum.com>
wrote:

> Hello Jason,
>
> I'm sorry, this mail slipped out of my view.
>
> As for your question about ordering of notifications: generally yes,
> notifications are sent after changes were made. There are two kinds of
> notifications that might be of interest here:
> - "focal object" (model-level) notifications
> - resource object (provisioning-level) notifications
>
> The former are related to changes in focal objects - users, roles, and
> orgs. They are invoked by model, among model hooks, in the FINAL stage -
> i.e. after all the changes were made.
> The latter are related to changes in resource objects. They are invoked by
> the provisioning module. Again, they are invoked after operation attempt
> has been carried out - either successfully, unsuccessfully, or
> unsuccessfully with the hope of eventual sucess. You can differentiate
> between these states by looking at operationStatus field: it is either
> SUCCESS, FAILURE, or IN_PROGRESS, respectively.
>
> Back to your code. Requestee is the focal object that the operation deals
> with (typically, the user). Your expression returns the current
> administrative status of this user.
>
> If it's used within the context of a focal object notification, it
> displays the new status of the object (an exception is the DELETE
> operation, where it would show the original status).
>
> But if it's used within the context of a resource object notification, it
> displays the status of the user object just after the resource object
> (account) operation was carried out. So it is *not* the final state.
> Imagine e.g. that there would be a "disable account" operation, followed by
> inbound mapping of newly changed value of account's administrativeStatus to
> user's administrativeStatus. In this case, the notification would show the
> original vlaue of the user's administrativeStatus. (But, this example is
> perhaps too artificial to be present in real life.)
>
> Hope this helps (at least a bit...)
> Pavol
>
> ------------------------------
> *From: *"Jason Everling" <jeverling at bshp.edu>
> *To: *"midPoint General Discussion" <midpoint at lists.evolveum.com>
> *Sent: *Tuesday, November 10, 2015 8:17:46 PM
> *Subject: *[midPoint] New notification, need to verify my code
>
>
> I tested the below code and it seems to work but I just wanted to verify I
> am using it correctly. Also, notification are the last item to process
> correct, after all changes have been made to the account?
>
> Snippet from body expression code:
>
> "Status: " + requestee?.getActivation()?.getAdministrativeStatus() + " \n"
> +
>
> Thanks!
> 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
> http://lists.evolveum.com/mailman/listinfo/midpoint
>
>
> _______________________________________________
> midPoint mailing list
> 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. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20160125/775e14a7/attachment.htm>