[midPoint] DatabaseTable Multi-Value Fields

[Ivan Noris]

Hi Carlos, 
I may be completely wrong, but for a different (custom) connector, we needed to do something like this: 

<attribute> 
<description>We want the connector have ALL values, not only delta</description> 
<ref>ri:roles</ref> 
<readReplaceMode>true</readReplaceMode> 
</attribute> 

(It was maybe half year ago, I don't remember the particular details now, except that the "ri:roles" was a multi-valued attribute, not association). 
Maybe this helps or brings new answers from the other members of this list. 

Regards, 
Ivan 

----- Original Message -----

> From: "Carlos Ferreira" <carlos18619 at gmail.com>
> To: "midPoint General Discussion" <midpoint at lists.evolveum.com>
> Sent: Saturday, October 8, 2016 12:46:59 AM
> Subject: Re: [midPoint] DatabaseTable Multi-Value Fields

> HI,

> This is exactly the same behavior I've been seeing im my case.

> First of all,

> 1. I'm using SCRIPTEDSQL connector and an ORACLE DB;
> 2. I've configured a multi-valued extension attribute - says 'roles' - to
> receive the roles applied to an user;
> 3. Configured a metarole to deal with an association. Something like this:

> <inducement id="3">
> <construction>
> <resourceRef xmlns:tns="
> http://midpoint.evolveum.com/xml/ns/public/common/common-3 "
> oid="ef2bc95b-76e0-48e3-86db-3d4f02d42fff"
> type="tns:ResourceType"><!-- Localhost ScriptedSQL - Oracle --></resourceRef>
> <kind>account</kind>
> <intent>default</intent>
> <association>
> <c:ref>ri:priv</c:ref>
> <outbound>
> <expression>
> <associationFromLink>
> <projectionDiscriminator>
> <kind>entitlement</kind>
> <intent>privilege</intent>
> </projectionDiscriminator>
> </associationFromLink>
> </expression>
> </outbound>
> </association>
> </construction>
> <order>2</order>
> </inducement>

> 4. Made the necessary adjustments on the resource to cope with the
> association. Like this:

> <association>
> <c:ref>ri:priv</c:ref>
> <kind>entitlement</kind>
> <intent>privilege</intent>
> <direction>subjectToObject</direction>
> <associationAttribute>ri:roles</associationAttribute>
> <valueAttribute>icfs:name</valueAttribute>
> </association>

> As to help me understand what goes through the connector, I added some lines
> in the beginning of 'UpdateScript.groovy' script:

> def now = new Date()

> def file1 = new File('/var/opt/midpoint/icf-connectors/oracle/update.log');
> if (file1.exists()) {
> file1.delete()
> }
> file1 << "Update test" << "\n"
> file1 << "Date = $now" << "\n"
> file1 << "objectClass = ${objectClass}"<< "\n"
> file1 << "action = $action" << "\n"
> file1 << "attributes = ${attributes}" << "\n"
> file1 << "options = $options" << "\n"
> file1 << "uid = $uid" << "\n"

> No matter if I update the current role applied to an user or add another one
> (as the attribute is multivalued), the result comes like this:

> Update test
> Date = Fri Oct 07 19:28:07 BRT 2016
> objectClass = __ACCOUNT__
> action = UPDATE
> attributes = [roles:[role1]]
> options = [:]
> uid = 161

> or

> Update test
> Date = Fri Oct 07 19:29:07 BRT 2016
> objectClass = __ACCOUNT__
> action = UPDATE
> attributes = [roles:[role2]]
> options = [:]
> uid = 161

> when, in my opinion, it should be, for example,

> Update test
> Date = Fri Oct 07 19:29:07 BRT 2016
> objectClass = __ACCOUNT__
> action = UPDATE
> attributes = [roles:[role1,role2]]
> options = [:]
> uid = 161

> It seems as the connector treats the "roles" attribute as a single-valued
> one.

> Carlos A. Ferreira
> TRT/MG
> Brasil

> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint

-- 
Ivan Noris 
Senior Identity Engineer 
evolveum.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20161010/e516f447/attachment.htm>