[midPoint] Discovering Custom objectClasses

[Pavol Mederly]

Hello Matt,

I have almost no experiences with auxiliaryObjectClass use, but it seems 
to me that you should include ri:shadowAccount in the list of classes 
that are imported to resource schema, i.e. in this element:

  <generationConstraints>
<generateObjectClass>ri:person</generateObjectClass>
<generateObjectClass>ri:posixAccount</generateObjectClass>
<generateObjectClass>ri:inetLocalMailRecipient</generateObjectClass>
<generateObjectClass>ri:groupOfUniqueNames</generateObjectClass>
</generationConstraints>

(Actually, this element can be skipped altogether, resulting in all 
object classes being processed into resource schema. However, this would 
lead to a bloated schema for some resources, including common LDAP servers.)

By the way, I've recently fixed MID-3359 
<https://jira.evolveum.com/browse/MID-3359> so the resource wizard now 
supports auxiliary object classes (at least for attribute definition).

Best regards,

Pavol Mederly
Software developer
evolveum.com

On 19.08.2016 21:41, Mencel, Matt wrote:
> So attempting to do a sync results in an error.
>
> 2016-08-19 14:36:13,720 [] [midPointScheduler_Worker-7] ERROR 
> (com.evolveum.midpoint.provisioning.impl.ShadowCache): Schema error: 
> Auxiliary object class 
> {http://midpoint.evolveum.com/xml/ns/public/resource/instance-3}shadowAccount 
> <http://midpoint.evolveum.com/xml/ns/public/resource/instance-3%7DshadowAccount> 
> specified in shadow:null(null) does not exist
>
> I'll put the stacktrace in the gist.
>
> https://gist.github.com/MattMencel/2a3208371a1b0ce422e0b4923df413f7
>
> Matt
>
>
> On Fri, Aug 19, 2016 at 10:47 AM, Radovan Semancik 
> <radovan.semancik at evolveum.com <mailto:radovan.semancik at evolveum.com>> 
> wrote:
>
>     Hi,
>
>     Yes, that should work.
>     Just check that you have correct lowercase/uppercase form for the
>     attribute names. LDAP is (mostly) case insensitive, but midPoint
>     is case sensitive. Look at the <schema> part of the resource
>     definition. That is generated from the resource. Look for your
>     auxiliary object class definition there. And use the same
>     capitalization as you see in the <schema> section.
>
>     -- 
>     Radovan Semancik
>     Software Architect
>     evolveum.com <http://evolveum.com>
>
>
>
>
>     On 08/19/2016 05:23 PM, Mencel, Matt wrote:
>>     Thanks Radovan,
>>
>>     That helps.  Do I declare the auxiliary's attributes in the same
>>     place as the default objectClass then?  I'm getting this error in
>>     the UI...
>>
>>         There is no attribute named
>>         '{http://midpoint.evolveum.com/xml/ns/public/resource/instance-3}wiuId
>>         <http://midpoint.evolveum.com/xml/ns/public/resource/instance-3%7DwiuId>'
>>         in object class
>>         '{http://midpoint.evolveum.com/xml/ns/public/resource/instance-3}person
>>         <http://midpoint.evolveum.com/xml/ns/public/resource/instance-3%7Dperson>'
>>         (defined in schema handling for 'User Account (kind: ACCOUNT,
>>         intent: person)').
>>
>>
>>     https://gist.github.com/MattMencel/2a3208371a1b0ce422e0b4923df413f7
>>     <https://gist.github.com/MattMencel/2a3208371a1b0ce422e0b4923df413f7>
>>
>>     On Fri, Aug 19, 2016 at 9:54 AM, Radovan Semancik
>>     <radovan.semancik at evolveum.com
>>     <mailto:radovan.semancik at evolveum.com>> wrote:
>>
>>         Hi,
>>
>>         On 08/19/2016 04:26 PM, Mencel, Matt wrote:
>>>         I have multiple LDAP objectclasses that contain all the
>>>         attributes that make up a person's identity.  I've
>>>         associated multiple OCs with the same kind/intent in
>>>         midpoint and am getting a warning in the UI.
>>>
>>>             There are multiple schema handling definitions for
>>>             kind/intent: ACCOUNT/person.
>>>
>>>         Should I be doing this another way?
>>>
>>
>>         Yes. Just one of the objectclasses is structural (primary).
>>         Other object classes are auxiliary. MidPoint fully supports
>>         auxiliary object classes, but you need to use a slightly
>>         different approach. Use something like this:
>>
>>         	<schemaHandling>
>>         		<objectType>
>>         			<kind>account</kind>
>>         			<displayName>Normal Account</displayName>
>>         			<default>true</default>
>>         			<objectClass>ri:inetOrgPerson</objectClass>
>>                                  <auxiliaryObjectClass>ri:posixAccount</auxiliaryObjectClass>
>>                                  <auxiliaryObjectClass>ri:foo</auxiliaryObjectClass>
>>                                  <auxiliaryObjectClass>ri:bar</auxiliaryObjectClass>
>>         ...
>>           
>>
>>         -- 
>>         Radovan Semancik
>>         Software Architect
>>         evolveum.com <http://evolveum.com>
>>
>>         _______________________________________________ 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>
>     _______________________________________________ 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
> http://lists.evolveum.com/mailman/listinfo/midpoint
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20160822/5071a19d/attachment.htm>