Attribute resolver dependency question/issue

[Chad La Joie]

On Thu, May 3, 2012 at 2:37 PM, Tom Poage <tfpoage at ucdavis.edu> wrote:
> OK. I was under the impression that if the attribute existed (i.e. had a
> value in LDAP), the script would operate on that list of values, the
> 'new' only being there if nothing was pulled from the directory (to
> avoid an exception calling getValues() on a NULL).

No, the result of one plugin is "scoped" to that plugin.  So the data
structure returned by the LDAP data connector has an attribute called
"eduPersonAffiliation" and the data structure returned by the
attribute definition also has one with that name.  You then decide
when to merge them together.  In this case you did so by declaring
both plugins as a dependency of the Scoped attribute definition.  That
definition creates, within its returned data structure, an attribute
called eduPersonAffiliation that contains the values from the
dependencies.

By having everything "scoped" to the plugin that produces the data you
can create some fairly sophisticated data processing pipelines in the
resolver.  One that merge and branch and multiplex data.  Most people
just want merging behavior which is why all the fixed logic plugins
(i.e., not the script ones) that we ship have that behavior.

> Ah, I didn't see them as separate containers that happened to have the
> same identifier. Basically I wanted to add "member" if any value existed
> in the LDAP attribute and remove the internal/legacy value "external",
> leaving other values ("staff", "faculty", "student") intact. More or less:

Right, you can do that but that's not what your code did, it's more
complicated, and I wouldn't recommended it.


-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered