I'm trying to write a create rule that says, "If a user being added has the
same first and last name as an existing user, create the user with a
"pendingXXX" CN."  Then, admins can manually determine if the user should
have been matched to a pre-existing record, or if this is indeed just a case
of similar names. (For business reasons too complex to cover, I can't
implement this in a matching rule and we have to leave the manual
reconciliation in place.)

I have a piece of XSLT (see below) that queries the directory to find a
count of existing users who have the same first and last name as a new user
being added.

I'm wondering if there is an easy conversion of this to policy builder...
basically making all of the below into my " Conditions."  If you know of one
could you point me in the right direction?

Thanks,
Rob.

 <xsl:template match="add[@class-name='User']">
  <xsl:variable name="firstName" select="./add-attr[@attr-name='Given
Name']/value"/>
  <xsl:variable name="lastName"
select="./add-attr[@attr-name='Surname']/value"/>
  <!-- query ID tree for any user objects that may match the current
record -->
  <xsl:variable name="query-users">
   <query dest-dn="\PHC_IDENT\users" scope="subtree">
    <search-class class-name="User"/>
    <search-attr attr-name="Given Name">
     <value type="string">
      <xsl:value-of select="$firstName"/>
     </value>
    </search-attr>
    <search-attr attr-name="Surname">
     <value type="string">
      <xsl:value-of select="$lastName"/>
     </value>
    </search-attr>
   </query>
  </xsl:variable>
  <xsl:variable name="query-result"
select="query:query($destQueryProcessor,$query-users)"/>
  <xsl:choose>
   <xsl:when test="count($query-result//instance) > 0">

Currently the only way to query on multiple attributes in Policy Builder 
is to use do-find-matching-object. It doesn't have to be used in a 
matching policy, but it can be used if the current operation is an add. 
The way you would check the result would be to check the association on 
the current operation and then remove the association so it doesn't 
interfere.

--

Father Ramon


Rob wrote:
> I'm trying to write a create rule that says, "If a user being added has the
> same first and last name as an existing user, create the user with a
> "pendingXXX" CN."  Then, admins can manually determine if the user should
> have been matched to a pre-existing record, or if this is indeed just a case
> of similar names. (For business reasons too complex to cover, I can't
> implement this in a matching rule and we have to leave the manual
> reconciliation in place.)
> 
> I have a piece of XSLT (see below) that queries the directory to find a
> count of existing users who have the same first and last name as a new user
> being added.
> 
> I'm wondering if there is an easy conversion of this to policy builder...
> basically making all of the below into my " Conditions."  If you know of one
> could you point me in the right direction?
> 
> Thanks,
> Rob.
> 
>  <xsl:template match="add[@class-name='User']">
>   <xsl:variable name="firstName" select="./add-attr[@attr-name='Given
> Name']/value"/>
>   <xsl:variable name="lastName"
> select="./add-attr[@attr-name='Surname']/value"/>
>   <!-- query ID tree for any user objects that may match the current
> record -->
>   <xsl:variable name="query-users">
>    <query dest-dn="\PHC_IDENT\users" scope="subtree">
>     <search-class class-name="User"/>
>     <search-attr attr-name="Given Name">
>      <value type="string">
>       <xsl:value-of select="$firstName"/>
>      </value>
>     </search-attr>
>     <search-attr attr-name="Surname">
>      <value type="string">
>       <xsl:value-of select="$lastName"/>
>      </value>
>     </search-attr>
>    </query>
>   </xsl:variable>
>   <xsl:variable name="query-result"
> select="query:query($destQueryProcessor,$query-users)"/>
>   <xsl:choose>
>    <xsl:when test="count($query-result//instance) > 0">
> 
> 

On Wed, 17 May 2006 14:18:28 GMT, "Rob" <folboteur.nospam@wi.spamno.rr.com>
wrote:

>I'm trying to write a create rule that says, "If a user being added has the
>same first and last name as an existing user, create the user with a
>"pendingXXX" CN."

Hm. You can build queries in xpath, and store the results in local variables.
Seems like you can probably do this, but not quite exactly the same way.

Something akin to:

if source attr available "firstname" and if source attr available "lastname"

do set local variable checkfirstname equal to the xpath query for firstname
do set local variable checklastname equal to the xpath query for lastname

(I hope you have firstname and lastname indexed...)

You don't really care how *many* objects there are, you just want to know if
both attribute values are in use by any one object. Right? The xpath queries
should give you back a node set of all matching objects.

Use do-for-each to run through one of the two node-set variables, and check to
see if it compares equal to the other node-set. More xpath required there, but
pretty simple. If you get a positive, do set local variable to report the
collision.

At the end of the do-for-each, either your collision variable is set, or it
isn't.

You can then use the unique-name token to create the pendingXXX CN if the
collision variable is set. Or use your other logic to create the CN for non
colliding users.


---------------------------------------------------------------------------
 David Gersic                                            dgersic_@_niu.edu

 I'm tired of receiving rubbish in my mailbox, so the E-mail address is
 munged to foil the junkmail bots. Humans will figure it out on their own.

I'm not catching your drift.  How can I take action on the results of an
action?

Here's some output of a rule like you suggest.  I assume I have to somehow
act on the status notification that an instance was found.   If not, then I
don't know what you mean when you say to check the association?  There will
be no association on these users.

This is in the create rule, prior to a rule I have that vetoes on missing
mandatory attributes.

Thanks for any clarity you can add to my understanding.

[05/22/06 13:39:44.132]: @#@#@# PT: No match found.
[05/22/06 13:39:44.132]: @#@#@# PT: Applying object creation policies.
[05/22/06 13:39:44.132]: @#@#@# PT: Applying policy: %+C%14CDetermine if
PENDING Status required%-C.
[05/22/06 13:39:44.133]: @#@#@# PT:   Applying to add #1.
[05/22/06 13:39:44.133]: @#@#@# PT:     Evaluating selection criteria for
rule 'Find users with Duplicate Given and Sur Names'.
[05/22/06 13:39:44.133]: @#@#@# PT:       (if-class-name equal "User") =
TRUE.
[05/22/06 13:39:44.133]: @#@#@# PT:     Rule selected.
[05/22/06 13:39:44.133]: @#@#@# PT:     Applying rule 'Find users with
Duplicate Given and Sur Names'.
[05/22/06 13:39:44.133]: @#@#@# PT:       Action:
do-find-matching-object(arg-match-attr("Surname"),arg-match-attr("Given
Name")).
[05/22/06 13:39:44.133]: @#@#@# PT:         arg-match-attr("Surname")
[05/22/06 13:39:44.133]: @#@#@# PT:         arg-match-attr("Given Name")
[05/22/06 13:39:44.133]: @#@#@# PT:         Query from policy
[05/22/06 13:39:44.133]: @#@#@# PT:
<nds dtdversion="3.0" ndsversion="8.x">
  <source>
    <product version="3.0.0.20051118 ">DirXML</product>
    <contact>Novell, Inc.</contact>
  </source>
  <input>
    <query class-name="User" scope="subtree">
      <search-class class-name="User"/>
      <search-attr attr-name="Surname">
        <value type="string">Schneider</value>
      </search-attr>
      <search-attr attr-name="Given Name">
        <value type="string">Robert</value>
      </search-attr>
      <read-attr/>
    </query>
  </input>
</nds>
[05/22/06 13:39:44.134]: @#@#@# PT:         Pumping XDS to eDirectory.
[05/22/06 13:39:44.134]: @#@#@# PT:         Performing operation query for .
[05/22/06 13:39:44.136]: @#@#@# PT:         Query from policy result
[05/22/06 13:39:44.136]: @#@#@# PT:
<nds dtdversion="3.0" ndsversion="8.x">
  <source>
    <product version="3.0.0.20051118 ">DirXML</product>
    <contact>Novell, Inc.</contact>
  </source>
  <output>
    <instance class-name="User" event-id="0"
qualified-src-dn="O=Users\CN=u56361" src-dn="\SSO\Users\u56361"
src-entry-id="43113"/>
    <status event-id="0" level="success"></status>
  </output>
</nds>


"Father Ramon" <devforums@novell.com> wrote in message
news:BnIag.34$nw3.0@prv-forum2.provo.novell.com...
> Currently the only way to query on multiple attributes in Policy Builder
> is to use do-find-matching-object. It doesn't have to be used in a
> matching policy, but it can be used if the current operation is an add.
> The way you would check the result would be to check the association on
> the current operation and then remove the association so it doesn't
> interfere.
>
> --
>
> Father Ramon
>
>
> Rob wrote:
> > I'm trying to write a create rule that says, "If a user being added has
the
> > same first and last name as an existing user, create the user with a
> > "pendingXXX" CN."  Then, admins can manually determine if the user
should
> > have been matched to a pre-existing record, or if this is indeed just a
case
> > of similar names. (For business reasons too complex to cover, I can't
> > implement this in a matching rule and we have to leave the manual
> > reconciliation in place.)
> >
> > I have a piece of XSLT (see below) that queries the directory to find a
> > count of existing users who have the same first and last name as a new
user
> > being added.
> >
> > I'm wondering if there is an easy conversion of this to policy
builder...
> > basically making all of the below into my " Conditions."  If you know of
one
> > could you point me in the right direction?
> >
> > Thanks,
> > Rob.
> >
> >  <xsl:template match="add[@class-name='User']">
> >   <xsl:variable name="firstName" select="./add-attr[@attr-name='Given
> > Name']/value"/>
> >   <xsl:variable name="lastName"
> > select="./add-attr[@attr-name='Surname']/value"/>
> >   <!-- query ID tree for any user objects that may match the current
> > record -->
> >   <xsl:variable name="query-users">
> >    <query dest-dn="\PHC_IDENT\users" scope="subtree">
> >     <search-class class-name="User"/>
> >     <search-attr attr-name="Given Name">
> >      <value type="string">
> >       <xsl:value-of select="$firstName"/>
> >      </value>
> >     </search-attr>
> >     <search-attr attr-name="Surname">
> >      <value type="string">
> >       <xsl:value-of select="$lastName"/>
> >      </value>
> >     </search-attr>
> >    </query>
> >   </xsl:variable>
> >   <xsl:variable name="query-result"
> > select="query:query($destQueryProcessor,$query-users)"/>
> >   <xsl:choose>
> >    <xsl:when test="count($query-result//instance) > 0">
> >
> >

Re-read the part of my previous post that begins with "The way you would 
check the result would be to ..."
--

Father Ramon


Rob wrote:
> I'm not catching your drift.  How can I take action on the results of an
> action?
> 
> Here's some output of a rule like you suggest.  I assume I have to somehow
> act on the status notification that an instance was found.   If not, then I
> don't know what you mean when you say to check the association?  There will
> be no association on these users.
> 
> This is in the create rule, prior to a rule I have that vetoes on missing
> mandatory attributes.
> 
> Thanks for any clarity you can add to my understanding.
> 
> [05/22/06 13:39:44.132]: @#@#@# PT: No match found.
> [05/22/06 13:39:44.132]: @#@#@# PT: Applying object creation policies.
> [05/22/06 13:39:44.132]: @#@#@# PT: Applying policy: %+C%14CDetermine if
> PENDING Status required%-C.
> [05/22/06 13:39:44.133]: @#@#@# PT:   Applying to add #1.
> [05/22/06 13:39:44.133]: @#@#@# PT:     Evaluating selection criteria for
> rule 'Find users with Duplicate Given and Sur Names'.
> [05/22/06 13:39:44.133]: @#@#@# PT:       (if-class-name equal "User") =
> TRUE.
> [05/22/06 13:39:44.133]: @#@#@# PT:     Rule selected.
> [05/22/06 13:39:44.133]: @#@#@# PT:     Applying rule 'Find users with
> Duplicate Given and Sur Names'.
> [05/22/06 13:39:44.133]: @#@#@# PT:       Action:
> do-find-matching-object(arg-match-attr("Surname"),arg-match-attr("Given
> Name")).
> [05/22/06 13:39:44.133]: @#@#@# PT:         arg-match-attr("Surname")
> [05/22/06 13:39:44.133]: @#@#@# PT:         arg-match-attr("Given Name")
> [05/22/06 13:39:44.133]: @#@#@# PT:         Query from policy
> [05/22/06 13:39:44.133]: @#@#@# PT:
> <nds dtdversion="3.0" ndsversion="8.x">
>   <source>
>     <product version="3.0.0.20051118 ">DirXML</product>
>     <contact>Novell, Inc.</contact>
>   </source>
>   <input>
>     <query class-name="User" scope="subtree">
>       <search-class class-name="User"/>
>       <search-attr attr-name="Surname">
>         <value type="string">Schneider</value>
>       </search-attr>
>       <search-attr attr-name="Given Name">
>         <value type="string">Robert</value>
>       </search-attr>
>       <read-attr/>
>     </query>
>   </input>
> </nds>
> [05/22/06 13:39:44.134]: @#@#@# PT:         Pumping XDS to eDirectory.
> [05/22/06 13:39:44.134]: @#@#@# PT:         Performing operation query for .
> [05/22/06 13:39:44.136]: @#@#@# PT:         Query from policy result
> [05/22/06 13:39:44.136]: @#@#@# PT:
> <nds dtdversion="3.0" ndsversion="8.x">
>   <source>
>     <product version="3.0.0.20051118 ">DirXML</product>
>     <contact>Novell, Inc.</contact>
>   </source>
>   <output>
>     <instance class-name="User" event-id="0"
> qualified-src-dn="O=Users\CN=u56361" src-dn="\SSO\Users\u56361"
> src-entry-id="43113"/>
>     <status event-id="0" level="success"></status>
>   </output>
> </nds>
> 
> 
> "Father Ramon" <devforums@novell.com> wrote in message
> news:BnIag.34$nw3.0@prv-forum2.provo.novell.com...
>> Currently the only way to query on multiple attributes in Policy Builder
>> is to use do-find-matching-object. It doesn't have to be used in a
>> matching policy, but it can be used if the current operation is an add.
>> The way you would check the result would be to check the association on
>> the current operation and then remove the association so it doesn't
>> interfere.
>>
>> --
>>
>> Father Ramon
>>
>>
>> Rob wrote:
>>> I'm trying to write a create rule that says, "If a user being added has
> the
>>> same first and last name as an existing user, create the user with a
>>> "pendingXXX" CN."  Then, admins can manually determine if the user
> should
>>> have been matched to a pre-existing record, or if this is indeed just a
> case
>>> of similar names. (For business reasons too complex to cover, I can't
>>> implement this in a matching rule and we have to leave the manual
>>> reconciliation in place.)
>>>
>>> I have a piece of XSLT (see below) that queries the directory to find a
>>> count of existing users who have the same first and last name as a new
> user
>>> being added.
>>>
>>> I'm wondering if there is an easy conversion of this to policy
> builder...
>>> basically making all of the below into my " Conditions."  If you know of
> one
>>> could you point me in the right direction?
>>>
>>> Thanks,
>>> Rob.
>>>
>>>  <xsl:template match="add[@class-name='User']">
>>>   <xsl:variable name="firstName" select="./add-attr[@attr-name='Given
>>> Name']/value"/>
>>>   <xsl:variable name="lastName"
>>> select="./add-attr[@attr-name='Surname']/value"/>
>>>   <!-- query ID tree for any user objects that may match the current
>>> record -->
>>>   <xsl:variable name="query-users">
>>>    <query dest-dn="\PHC_IDENT\users" scope="subtree">
>>>     <search-class class-name="User"/>
>>>     <search-attr attr-name="Given Name">
>>>      <value type="string">
>>>       <xsl:value-of select="$firstName"/>
>>>      </value>
>>>     </search-attr>
>>>     <search-attr attr-name="Surname">
>>>      <value type="string">
>>>       <xsl:value-of select="$lastName"/>
>>>      </value>
>>>     </search-attr>
>>>    </query>
>>>   </xsl:variable>
>>>   <xsl:variable name="query-result"
>>> select="query:query($destQueryProcessor,$query-users)"/>
>>>   <xsl:choose>
>>>    <xsl:when test="count($query-result//instance) > 0">
>>>
>>>
> 
> 

I have reread your comment, but am still left with questions of how.

The association before my find-matching-object rule looks like this:

  <input>
    <add class-name="User" event-id="301036"
src-dn="EMPNBR=191222,table=IDM,schema=DIRXML">
      <association>EMPNBR=191222,table=IDM,schema=DIRXML</association>

The find-matching-object returns with the matching instance, and after the
rule the association looks like this...

  <input>
    <add class-name="User" dest-dn="\PHCSSO\Users\u56361"
dest-entry-id="43113" event-id="301036"
src-dn="EMPNBR=191222,table=IDM,schema=DIRXML">
      <association>EMPNBR=191222,table=IDM,schema=DIRXML</association>

The association doesn't change... though I note that there is now a dest-dn.
Could I test this for "If DestDN exists, then there is a match, so therefore
the Dest-DN has to be reformatted, to place the user in the "pending
investigation" container?

I wish it were transparent and obvious to me, but could you elaborate any
further on what you mean, and how it's done?  If it turns out to be
embarrassingly simple and obvious, I'll apologize profusely and take you to
dinner next time I'm in Utah. :-)

Rob.


"Father Ramon" <devforums@novell.com> wrote in message
news:lHEcg.1770$Mr.936@prv-forum2.provo.novell.com...
> Re-read the part of my previous post that begins with "The way you would
> check the result would be to ..."
> --
>
> Father Ramon
>
>
> Rob wrote:
> > I'm not catching your drift.  How can I take action on the results of an
> > action?
> >
> > Here's some output of a rule like you suggest.  I assume I have to
somehow
> > act on the status notification that an instance was found.   If not,
then I
> > don't know what you mean when you say to check the association?  There
will
> > be no association on these users.
> >
> > This is in the create rule, prior to a rule I have that vetoes on
missing
> > mandatory attributes.
> >
> > Thanks for any clarity you can add to my understanding.
> >
> > [05/22/06 13:39:44.132]: @#@#@# PT: No match found.
> > [05/22/06 13:39:44.132]: @#@#@# PT: Applying object creation policies.
> > [05/22/06 13:39:44.132]: @#@#@# PT: Applying policy: %+C%14CDetermine if
> > PENDING Status required%-C.
> > [05/22/06 13:39:44.133]: @#@#@# PT:   Applying to add #1.
> > [05/22/06 13:39:44.133]: @#@#@# PT:     Evaluating selection criteria
for
> > rule 'Find users with Duplicate Given and Sur Names'.
> > [05/22/06 13:39:44.133]: @#@#@# PT:       (if-class-name equal "User") =
> > TRUE.
> > [05/22/06 13:39:44.133]: @#@#@# PT:     Rule selected.
> > [05/22/06 13:39:44.133]: @#@#@# PT:     Applying rule 'Find users with
> > Duplicate Given and Sur Names'.
> > [05/22/06 13:39:44.133]: @#@#@# PT:       Action:
> > do-find-matching-object(arg-match-attr("Surname"),arg-match-attr("Given
> > Name")).
> > [05/22/06 13:39:44.133]: @#@#@# PT:         arg-match-attr("Surname")
> > [05/22/06 13:39:44.133]: @#@#@# PT:         arg-match-attr("Given Name")
> > [05/22/06 13:39:44.133]: @#@#@# PT:         Query from policy
> > [05/22/06 13:39:44.133]: @#@#@# PT:
> > <nds dtdversion="3.0" ndsversion="8.x">
> >   <source>
> >     <product version="3.0.0.20051118 ">DirXML</product>
> >     <contact>Novell, Inc.</contact>
> >   </source>
> >   <input>
> >     <query class-name="User" scope="subtree">
> >       <search-class class-name="User"/>
> >       <search-attr attr-name="Surname">
> >         <value type="string">Schneider</value>
> >       </search-attr>
> >       <search-attr attr-name="Given Name">
> >         <value type="string">Robert</value>
> >       </search-attr>
> >       <read-attr/>
> >     </query>
> >   </input>
> > </nds>
> > [05/22/06 13:39:44.134]: @#@#@# PT:         Pumping XDS to eDirectory.
> > [05/22/06 13:39:44.134]: @#@#@# PT:         Performing operation query
for .
> > [05/22/06 13:39:44.136]: @#@#@# PT:         Query from policy result
> > [05/22/06 13:39:44.136]: @#@#@# PT:
> > <nds dtdversion="3.0" ndsversion="8.x">
> >   <source>
> >     <product version="3.0.0.20051118 ">DirXML</product>
> >     <contact>Novell, Inc.</contact>
> >   </source>
> >   <output>
> >     <instance class-name="User" event-id="0"
> > qualified-src-dn="O=Users\CN=u56361" src-dn="\SSO\Users\u56361"
> > src-entry-id="43113"/>
> >     <status event-id="0" level="success"></status>
> >   </output>
> > </nds>
> >
> >
> > "Father Ramon" <devforums@novell.com> wrote in message
> > news:BnIag.34$nw3.0@prv-forum2.provo.novell.com...
> >> Currently the only way to query on multiple attributes in Policy
Builder
> >> is to use do-find-matching-object. It doesn't have to be used in a
> >> matching policy, but it can be used if the current operation is an add.
> >> The way you would check the result would be to check the association on
> >> the current operation and then remove the association so it doesn't
> >> interfere.
> >>
> >> --
> >>
> >> Father Ramon
> >>
> >>
> >> Rob wrote:
> >>> I'm trying to write a create rule that says, "If a user being added
has
> > the
> >>> same first and last name as an existing user, create the user with a
> >>> "pendingXXX" CN."  Then, admins can manually determine if the user
> > should
> >>> have been matched to a pre-existing record, or if this is indeed just
a
> > case
> >>> of similar names. (For business reasons too complex to cover, I can't
> >>> implement this in a matching rule and we have to leave the manual
> >>> reconciliation in place.)
> >>>
> >>> I have a piece of XSLT (see below) that queries the directory to find
a
> >>> count of existing users who have the same first and last name as a new
> > user
> >>> being added.
> >>>
> >>> I'm wondering if there is an easy conversion of this to policy
> > builder...
> >>> basically making all of the below into my " Conditions."  If you know
of
> > one
> >>> could you point me in the right direction?
> >>>
> >>> Thanks,
> >>> Rob.
> >>>
> >>>  <xsl:template match="add[@class-name='User']">
> >>>   <xsl:variable name="firstName" select="./add-attr[@attr-name='Given
> >>> Name']/value"/>
> >>>   <xsl:variable name="lastName"
> >>> select="./add-attr[@attr-name='Surname']/value"/>
> >>>   <!-- query ID tree for any user objects that may match the current
> >>> record -->
> >>>   <xsl:variable name="query-users">
> >>>    <query dest-dn="\PHC_IDENT\users" scope="subtree">
> >>>     <search-class class-name="User"/>
> >>>     <search-attr attr-name="Given Name">
> >>>      <value type="string">
> >>>       <xsl:value-of select="$firstName"/>
> >>>      </value>
> >>>     </search-attr>
> >>>     <search-attr attr-name="Surname">
> >>>      <value type="string">
> >>>       <xsl:value-of select="$lastName"/>
> >>>      </value>
> >>>     </search-attr>
> >>>    </query>
> >>>   </xsl:variable>
> >>>   <xsl:variable name="query-result"
> >>> select="query:query($destQueryProcessor,$query-users)"/>
> >>>   <xsl:choose>
> >>>    <xsl:when test="count($query-result//instance) > 0">
> >>>
> >>>
> >
> >

I think you've got it. The "results" of the Find Matching Object are 
that the destination-dn or the association key of the current operation 
are changed (or not) depending on the channel you are on and the result 
of the query.

http://www.novell.com/documentation/idm/policy/data/bww6nsy.html#bwwjgo2


--

Father Ramon


Rob wrote:
> I have reread your comment, but am still left with questions of how.
> 
> The association before my find-matching-object rule looks like this:
> 
>   <input>
>     <add class-name="User" event-id="301036"
> src-dn="EMPNBR=191222,table=IDM,schema=DIRXML">
>       <association>EMPNBR=191222,table=IDM,schema=DIRXML</association>
> 
> The find-matching-object returns with the matching instance, and after the
> rule the association looks like this...
> 
>   <input>
>     <add class-name="User" dest-dn="\PHCSSO\Users\u56361"
> dest-entry-id="43113" event-id="301036"
> src-dn="EMPNBR=191222,table=IDM,schema=DIRXML">
>       <association>EMPNBR=191222,table=IDM,schema=DIRXML</association>
> 
> The association doesn't change... though I note that there is now a dest-dn.
> Could I test this for "If DestDN exists, then there is a match, so therefore
> the Dest-DN has to be reformatted, to place the user in the "pending
> investigation" container?
> 
> I wish it were transparent and obvious to me, but could you elaborate any
> further on what you mean, and how it's done?  If it turns out to be
> embarrassingly simple and obvious, I'll apologize profusely and take you to
> dinner next time I'm in Utah. :-)
> 
> Rob.
> 
> 
> "Father Ramon" <devforums@novell.com> wrote in message
> news:lHEcg.1770$Mr.936@prv-forum2.provo.novell.com...
>> Re-read the part of my previous post that begins with "The way you would
>> check the result would be to ..."
>> --
>>
>> Father Ramon
>>
>>
>> Rob wrote:
>>> I'm not catching your drift.  How can I take action on the results of an
>>> action?
>>>
>>> Here's some output of a rule like you suggest.  I assume I have to
> somehow
>>> act on the status notification that an instance was found.   If not,
> then I
>>> don't know what you mean when you say to check the association?  There
> will
>>> be no association on these users.
>>>
>>> This is in the create rule, prior to a rule I have that vetoes on
> missing
>>> mandatory attributes.
>>>
>>> Thanks for any clarity you can add to my understanding.
>>>
>>> [05/22/06 13:39:44.132]: @#@#@# PT: No match found.
>>> [05/22/06 13:39:44.132]: @#@#@# PT: Applying object creation policies.
>>> [05/22/06 13:39:44.132]: @#@#@# PT: Applying policy: %+C%14CDetermine if
>>> PENDING Status required%-C.
>>> [05/22/06 13:39:44.133]: @#@#@# PT:   Applying to add #1.
>>> [05/22/06 13:39:44.133]: @#@#@# PT:     Evaluating selection criteria
> for
>>> rule 'Find users with Duplicate Given and Sur Names'.
>>> [05/22/06 13:39:44.133]: @#@#@# PT:       (if-class-name equal "User") =
>>> TRUE.
>>> [05/22/06 13:39:44.133]: @#@#@# PT:     Rule selected.
>>> [05/22/06 13:39:44.133]: @#@#@# PT:     Applying rule 'Find users with
>>> Duplicate Given and Sur Names'.
>>> [05/22/06 13:39:44.133]: @#@#@# PT:       Action:
>>> do-find-matching-object(arg-match-attr("Surname"),arg-match-attr("Given
>>> Name")).
>>> [05/22/06 13:39:44.133]: @#@#@# PT:         arg-match-attr("Surname")
>>> [05/22/06 13:39:44.133]: @#@#@# PT:         arg-match-attr("Given Name")
>>> [05/22/06 13:39:44.133]: @#@#@# PT:         Query from policy
>>> [05/22/06 13:39:44.133]: @#@#@# PT:
>>> <nds dtdversion="3.0" ndsversion="8.x">
>>>   <source>
>>>     <product version="3.0.0.20051118 ">DirXML</product>
>>>     <contact>Novell, Inc.</contact>
>>>   </source>
>>>   <input>
>>>     <query class-name="User" scope="subtree">
>>>       <search-class class-name="User"/>
>>>       <search-attr attr-name="Surname">
>>>         <value type="string">Schneider</value>
>>>       </search-attr>
>>>       <search-attr attr-name="Given Name">
>>>         <value type="string">Robert</value>
>>>       </search-attr>
>>>       <read-attr/>
>>>     </query>
>>>   </input>
>>> </nds>
>>> [05/22/06 13:39:44.134]: @#@#@# PT:         Pumping XDS to eDirectory.
>>> [05/22/06 13:39:44.134]: @#@#@# PT:         Performing operation query
> for .
>>> [05/22/06 13:39:44.136]: @#@#@# PT:         Query from policy result
>>> [05/22/06 13:39:44.136]: @#@#@# PT:
>>> <nds dtdversion="3.0" ndsversion="8.x">
>>>   <source>
>>>     <product version="3.0.0.20051118 ">DirXML</product>
>>>     <contact>Novell, Inc.</contact>
>>>   </source>
>>>   <output>
>>>     <instance class-name="User" event-id="0"
>>> qualified-src-dn="O=Users\CN=u56361" src-dn="\SSO\Users\u56361"
>>> src-entry-id="43113"/>
>>>     <status event-id="0" level="success"></status>
>>>   </output>
>>> </nds>
>>>
>>>
>>> "Father Ramon" <devforums@novell.com> wrote in message
>>> news:BnIag.34$nw3.0@prv-forum2.provo.novell.com...
>>>> Currently the only way to query on multiple attributes in Policy
> Builder
>>>> is to use do-find-matching-object. It doesn't have to be used in a
>>>> matching policy, but it can be used if the current operation is an add.
>>>> The way you would check the result would be to check the association on
>>>> the current operation and then remove the association so it doesn't
>>>> interfere.
>>>>
>>>> --
>>>>
>>>> Father Ramon
>>>>
>>>>
>>>> Rob wrote:
>>>>> I'm trying to write a create rule that says, "If a user being added
> has
>>> the
>>>>> same first and last name as an existing user, create the user with a
>>>>> "pendingXXX" CN."  Then, admins can manually determine if the user
>>> should
>>>>> have been matched to a pre-existing record, or if this is indeed just
> a
>>> case
>>>>> of similar names. (For business reasons too complex to cover, I can't
>>>>> implement this in a matching rule and we have to leave the manual
>>>>> reconciliation in place.)
>>>>>
>>>>> I have a piece of XSLT (see below) that queries the directory to find
> a
>>>>> count of existing users who have the same first and last name as a new
>>> user
>>>>> being added.
>>>>>
>>>>> I'm wondering if there is an easy conversion of this to policy
>>> builder...
>>>>> basically making all of the below into my " Conditions."  If you know
> of
>>> one
>>>>> could you point me in the right direction?
>>>>>
>>>>> Thanks,
>>>>> Rob.
>>>>>
>>>>>  <xsl:template match="add[@class-name='User']">
>>>>>   <xsl:variable name="firstName" select="./add-attr[@attr-name='Given
>>>>> Name']/value"/>
>>>>>   <xsl:variable name="lastName"
>>>>> select="./add-attr[@attr-name='Surname']/value"/>
>>>>>   <!-- query ID tree for any user objects that may match the current
>>>>> record -->
>>>>>   <xsl:variable name="query-users">
>>>>>    <query dest-dn="\PHC_IDENT\users" scope="subtree">
>>>>>     <search-class class-name="User"/>
>>>>>     <search-attr attr-name="Given Name">
>>>>>      <value type="string">
>>>>>       <xsl:value-of select="$firstName"/>
>>>>>      </value>
>>>>>     </search-attr>
>>>>>     <search-attr attr-name="Surname">
>>>>>      <value type="string">
>>>>>       <xsl:value-of select="$lastName"/>
>>>>>      </value>
>>>>>     </search-attr>
>>>>>    </query>
>>>>>   </xsl:variable>
>>>>>   <xsl:variable name="query-result"
>>>>> select="query:query($destQueryProcessor,$query-users)"/>
>>>>>   <xsl:choose>
>>>>>    <xsl:when test="count($query-result//instance) > 0">
>>>>>
>>>>>
>>>
> 
>