This question is really for Shon Vella, but if anyone else has some
ideas feel free to respond.

Background: There are a few examples where one can replace the
current-op with something else. As Shon has written earlier, this
allows you to use many of the tokens which *only* operate on the
current-op (and can make for simpler, easier to read code).

However, I've got two questions related to this:

1. Does this affect the temporary caching that is performed during the
current invocation of the policy.
2. Is it better to fake up an entirely new current-op or is it
sufficent to set temporary operation class and source dn, do the
required changes and restore the original operation class and source dn.

For example, you are working with a group object and within the policy
you query (separately) a couple of source-attributes on the group
object. The engine is smart enough to notice this and query for all
(say 3) attributes within the first query, so that the cache is
populated for the other two attributes.

What happens if within a policy, working on group "A" you query one
attribute. Then you switch out the current operation with say, an
object of a different class - for example User B.

The policy then triggers one or more queries against the user object
(say for example a couple of if attribute type queries).

Then you restore the original current-op and query a few more group
attributes.

Does the cache get flushed when you switch out the current-op?
Is the cache linked to some unique identifier (src-dn/assoc/entry id).

Additionally, instead of switching out the whole current-op, I've found
that it's enough to do the following:

1. Save the class name and source-dn from current-op
2. Set new values for class name and source-dn via the built-in tokens
that can do this.
3. Query/add/set source attributes against the temporary source-dn.
4. Restore the saved class name and source-dn to the current-op.

This worked for me, but can it produce problems? Is it better to fake
up an entirely new current-op?

An example of what I'm talking about is the following policy fragment.

<do-set-local-variable name="groupDN" scope="policy">
<arg-string>
<token-src-dn/>
</arg-string>
</do-set-local-variable>
<do-set-op-class-name>
<arg-string>
<token-text xml:space="preserve">User</token-text>
</arg-string>
</do-set-op-class-name>
<do-for-each>
<arg-node-set>
<token-xpath expression="es:unique($addedMembers)"/>
</arg-node-set>
<arg-actions>
<do-set-op-src-dn>
<arg-dn>
<token-local-variable name="current-node"/>
</arg-dn>
</do-set-op-src-dn>
<do-if>
<arg-conditions>
<and>
<if-attr mode="nocase" name="nrfMemberOf" notrace="true"
op="not-equal">$current-role$</if-attr>
</and>
</arg-conditions>
<arg-actions>
<do-remove-src-attr-value class-name="User" name="Group
Membership">
<arg-dn>
<token-src-dn/>
</arg-dn>
<arg-value type="dn">
<token-local-variable name="groupDN"/>
</arg-value>
</do-remove-src-attr-value>
<do-remove-src-attr-value class-name="User" name="Security
Equals">
<arg-dn>
<token-src-dn/>
</arg-dn>
<arg-value type="dn">
<token-local-variable name="groupDN"/>
</arg-value>
</do-remove-src-attr-value>
<do-remove-src-attr-value class-name="Group" name="Member">
<arg-dn>
<token-local-variable name="groupDN"/>
</arg-dn>
<arg-value type="dn">
<token-src-dn/>
</arg-value>
</do-remove-src-attr-value>
<do-remove-src-attr-value class-name="Group" name="Equivalent
To Me">
<arg-dn>
<token-local-variable name="groupDN"/>
</arg-dn>
<arg-value type="dn">
<token-src-dn/>
</arg-value>
</do-remove-src-attr-value>
</arg-actions>
<arg-actions/>
</do-if>
</arg-actions>
</do-for-each>
<do-set-op-src-dn>
<arg-dn>
<token-local-variable name="groupDN"/>
</arg-dn>
</do-set-op-src-dn>
<do-set-op-class-name>
<arg-string>
<token-text xml:space="preserve">Group</token-text>
</arg-string>
</do-set-op-class-name>

--
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...