[midPoint] Basic-radio-button role assignment

[Pavol Mederly]

Hello Oleksandr,

I assume that during normal operation, if bronze, silver or gold role is 
unassigned, midPoint should automatically assign back the bronze role.

Assuming that, three options come to my mind:

 1. Bind the role assignment to some user extension property, let's call
    it e.g. "level". It would have three possible values (bronze,
    silver, gold) - I assume this can be ensured by defining it as a
    custom enum. And there would be two mappings: (1) a weak mapping
    that assigns "bronze" value to "level" if it has no value, (2) a
    strong mapping that creates a bronze/silver/gold assignment based on
    the "level" value. This means that all changes to this assignments
    have to go through the "level" item, not via assignments themselves.
 2. Write a custom scripting hook
    <https://wiki.evolveum.com/display/midPoint/Scripting+Hooks> that
    would evaluate the user after each change, and if it has no
    assignment to bronze/silver/gold role it would assign the bronze role.
 3. Write custom policy rule
    <https://wiki.evolveum.com/display/midPoint/Policy+Rules> that would
    fire if there's no assignment to bronze/silver/gold role.
    Unfortunately, midPoint currently has no way of specifying "do
    something" policy action, except for ugly workaround via custom
    "notify" action.

So I would suggest either (1) or (2).

Hope this helps.

Pavol Mederly
Software developer
evolveum.com

On 28.06.2018 15:18, Oleksandr Nekriach wrote:
> Hello Pavol,
> Yes, and I want that one of this radio-button role also was  a "basic" 
> (initial) role. This basic-radio-button role should be automatically 
> assigned to all new users by HR reconciliation task.
>
> For example:
>
>   *     bronze role is a "basic" role and also radio-button role
>   *     thanks to the HR reconciliation task, every new user will be 
>     assigned to the bronze role as 'basic" role.
>   *     during the user life cycle user can be assigned to another
>     radio-button roles manually  by HelpDesk or by some automatically
>     processes and Midpoint should remember such assignment
>   *     but never the HR reconciliation should fall back to "basic"
>     role assigment  if user has current radio-button assignment 
>     different to "basic" role (has silver or gold role)
>
>
>
> On 28 June 2018 at 12:38, Pavol Mederly <mederly at evolveum.com 
> <mailto:mederly at evolveum.com>> wrote:
>
>     Hello Oleksandr,
>
>     do you mean something like this? E.g. you have radio button roles:
>     bronze - silver - gold and you want to ensure that a user always
>     has exactly one of them assigned? (e.g. bronze if neither silver
>     nor gold)?
>
>     Pavol Mederly
>     Software developer
>     evolveum.com <http://evolveum.com>
>
>     On 22.06.2018 11:24, Oleksandr Nekriach wrote:
>>     Hi guys,
>>
>>     Does Midpoint have elegant solution for basic role assignment
>>     which is also a radio-button role?
>>     I have faced that  the assignment  of basic-radio-button role by
>>     object template mapping (a weak strength) does not work if we
>>     have other assignment mappings  in the same object template (for
>>     example OrgType assignments).
>>
>>     Thank you in advance.
>>
>>     -- 
>>     Best regards,
>>
>>
>>
>>     Oleksandr Nekriach | Identity and access management engineer
>>
>>     Dynatech, Mednieku str. 4a, Riga, LV-1010, Latvia
>>     <https://maps.google.com/?q=Mednieku+str.+4a,+Riga,+LV-1010,+Latvia&entry=gmail&source=g>
>>
>>
>>     +37125314685 <tel:+371%2025%20314%20685>
>>     ,
>>     o.nekriach at dynatech.lv <mailto:o.nekriach at dynatech.lv>
>>     |
>>     www.dynatech.lv <http://www.dynatech.lv>
>>
>>
>>     Stay connected:
>>     <https://www.facebook.com/DynatechLatvia/?ref=br_rs>
>>     <https://www.linkedin.com/company-beta/17893047/>
>>
>>
>>     Confidentiality Notice: This message contains confidential
>>     information and is intended only for the named recipient(s). If
>>     you are not the addressee you may not copy, distribute or perform
>>     any other activities with this information. If you have received
>>     this transmission in error, please notify us by e-mail
>>     immediately. E-mail transmission cannot be guaranteed to be
>>     secure or error-free as information could be intercepted,
>>     corrupted, lost, destroyed, arrive late or incomplete, or contain
>>     viruses.
>>
>>
>>     _______________________________________________
>>     midPoint mailing list
>>     midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>>     http://lists.evolveum.com/mailman/listinfo/midpoint
>>     <http://lists.evolveum.com/mailman/listinfo/midpoint>
>
>
>     _______________________________________________
>     midPoint mailing list
>     midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>     http://lists.evolveum.com/mailman/listinfo/midpoint
>     <http://lists.evolveum.com/mailman/listinfo/midpoint>
>
>
>
>
> -- 
> Best regards,
>
>
>
> Oleksandr Nekriach | Identity and access management engineer
>
> Dynatech, Mednieku str. 4a, Riga, LV-1010, Latvia 
> <https://maps.google.com/?q=Mednieku+str.+4a,+Riga,+LV-1010,+Latvia&entry=gmail&source=g> 
>
>
> +37125314685 <tel:+371%2025%20314%20685>
> ,
> o.nekriach at dynatech.lv <mailto:o.nekriach at dynatech.lv>
> |
> www.dynatech.lv <http://www.dynatech.lv>
>
>
> Stay connected:
> <https://www.facebook.com/DynatechLatvia/?ref=br_rs>
> <https://www.linkedin.com/company-beta/17893047/>
>
>
> Confidentiality Notice: This message contains confidential information 
> and is intended only for the named recipient(s). If you are not the 
> addressee you may not copy, distribute or perform any other activities 
> with this information. If you have received this transmission in 
> error, please notify us by e-mail immediately. E-mail transmission 
> cannot be guaranteed to be secure or error-free as information could 
> be intercepted, corrupted, lost, destroyed, arrive late or incomplete, 
> or contain viruses.
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180702/2224d692/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: o.nekriach at dynatech.lv1520941785292-7770
Type: image/png
Size: 4265 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180702/2224d692/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: o.nekriach at dynatech.lv1520941785292-7771
Type: image/png
Size: 790 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180702/2224d692/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: o.nekriach at dynatech.lv1520941785292-7772
Type: image/png
Size: 786 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180702/2224d692/attachment-0002.png>