[midPoint] Basic-radio-button role assignment
Oleksandr Nekriach
o.nekriach at dynatech.lv
Wed Jul 4 13:02:34 CEST 2018
Many thanks, Pavol !!!
On 2 July 2018 at 20:11, Pavol Mederly <mederly at evolveum.com> wrote:
> Hello Oleksandr,
>
> I should not care about the bronze role assigning back because it is only
> initial access.
>
> I see.
>
> I noticed that using normal strength for target assignment in mapping
> doesn't assigning back Bronze role even when emailAddress was changed.
>
> Yes. It is because under the *relative changes* model that midPoint is
> based on, the mapping takes *input change* and converts it into *output
> change*.
>
> Basically, when you create a user (or set - previously empty - email
> address for a user), the input change is "not applicable -> applicable"
> (because the condition says *emailAddress != null*). The output change is
> then *null -> (bronze role assignment)*. So the assignment is created.
> But after you simply change emailAddress from value A to B, the input
> change is *A -> B*, corresponding to output change of *(bronze role
> assignment) -> **(bronze role assignment)*, i.e. in fact, nothing should
> be changed on the output side. Even if bronze role assignment no longer
> exists because it was e.g. deleted by administrator.
>
> After you would erase emailAddress and set it again (in two separate
> operations), the bronze role assignment would appear again.
>
> If this is the way you expect it to work, then OK, you can use it.
> Best regards,
>
> Pavol Mederly
> Software developerevolveum.com
>
> On 02.07.2018 18:04, Oleksandr Nekriach wrote:
>
> 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.
>
>
> _______________________________________________
> 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/20180704/12609466/attachment.htm>
-------------- 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/20180704/12609466/attachment.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/20180704/12609466/attachment-0001.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/20180704/12609466/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/20180704/12609466/attachment-0003.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/20180704/12609466/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/20180704/12609466/attachment-0005.png>
More information about the midPoint
mailing list