[midPoint] Basic-radio-button role assignment

Mon Jul 2 18:04:02 CEST 2018

Oh,  Pavol you explained me this in the clear way. Thank you.

I have a little bit different requirements and approach to solve this.
I should not care about the bronze role assigning back because it is only
initial access.
I used  next approach
In object template I use mapping with assignment with normal strength (see
below).
I noticed that using normal strength  for target assignment in mapping
doesn't assigning back Bronze role even when emailAddress was changed.

Am I correct and I can use such an approach or I something missed?

<mapping id>
      <description>Assigment to Mantis Basic role</description>
      <strength>normal</strength>
      <source>
         <name>emailAddress</name>
         <c:path>$user/emailAddress</c:path>
      </source>
      <expression>
         <value>
            <targetRef oid="f0cf82d0-fe50-4e89-a628-2e5a936de379"
type="c:RoleType"/><!--Bronze role-->
         </value>
      </expression>
      <target>
         <c:path>assignment</c:path>
      </target>
      <condition>
         <script xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                 xsi:type="c:ScriptExpressionEvaluatorType">
            <code>
emailAddress != null
                    </code>
         </script>
      </condition>
   </mapping>

On 2 July 2018 at 11:16, Pavol Mederly <mederly at evolveum.com> wrote:

> 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 developerevolveum.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> 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 developerevolveum.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 <+371%2025%20314%20685>
>> ,
>> o.nekriach at dynatech.lv
>> |
>> 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 listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>>
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com
>> 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 <+371%2025%20314%20685>
> ,
> o.nekriach at dynatech.lv
> |
> 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 listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> 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 <+371%2025%20314%20685>
,
o.nekriach at dynatech.lv
|
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180702/f16798d6/attachment.htm>
-------------- 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/f16798d6/attachment.png>
-------------- 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/f16798d6/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/f16798d6/attachment-0002.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/f16798d6/attachment-0003.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/f16798d6/attachment-0004.png>
-------------- 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/f16798d6/attachment-0005.png>