[midPoint] Basic-radio-button role assignment
Pavol Mederly
mederly at evolveum.com
Mon Jul 2 19:11:11 CEST 2018
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 developer
evolveum.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
> <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
> <mailto: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 developer
> evolveum.com <http://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 <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/92403a7b/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/92403a7b/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/92403a7b/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/92403a7b/attachment-0002.png>
More information about the midPoint
mailing list