Scripted attribute dependencies

[Wessel, Keith]

Rod,

Yes, that's correct. And even if there are no values, it still passes the test of not of type undefined and not null. The fact that the attribute is called uid isn't relevant in this case. The issue is that, if accessing a specific value like with getValues().get(0), I have to construct my test for presence of attribute values differently for an attribute from an InputAttributeDefinition than I do for one from an InputDataConnector.

Does that make sense? That's where I felt like, if an attribute from another attribute definition doesn't have any values, it should appear as undefined to a script in another attribute definition that uses it as input.

At any rate, thank you, Scott, for the sanity check on my use of the size() method as a good test.

Keith




-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Rod Widdowson
Sent: Saturday, February 23, 2019 5:48 AM
To: 'Shib Users' <users at shibboleth.net>
Subject: RE: Scripted attribute dependencies

> This doesn't seem consistent to me. I don't mind working around it, but was this intentional?

It wasn't intentional.  

Let me make sure I understand - you have an AttributeDefinition called "uid" (which pulls its values from the dataconnectors) and you provide that attribute as an InputAttributeDefinition to  the scripted attribute?

I could imagine that somewhere down the line something could decide to create an attribute called "GUID" and plug it into the scripted context.  I'd need to check.


> Also, is there a better way to handle my conditionals than checking 
> for a type not of undefined and a list with a size greater
than 0?

I'll let others answer that.

/Rod

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net