Expected behavior of Template AttributeDefinition with inconsistent sources

[Cantor, Scott]

On 7/18/19, 11:59 AM, "users on behalf of Takeshi NISHIMURA" <users-bounces at shibboleth.net on behalf of takeshi at nii.ac.jp> wrote:

> What is the expected behavior of Template AttributeDefinition with inconsistent sources?
> Undefined?

That's an accurate assessment. I explicitly patched 4.0 to detect an input with no values and handle that gracefully by just ignoring it, but that only works if it really has no values. It could have an empty or null value object in place and still break things. The original intent of the plugin was that all value counts had to match.
 
> It seems that the behavior changed between 3.3.1 and 3.4.3.

Many things changed but nothing that I can understand as possibly changing that, I think it still has a throw() sitting in that code path.

But if it was throwing, then the configuration should have been changed. It's never a good idea to leave something "failing" and counting on that failure to prevent bad output. Exceptions that are happening because of data itself is a sign the logic is wrong.

> When uid has one value and mail has no values, 3.3.1 seems to throw an exception and 3.4.3 seems to produce "$mail" 

I think it's possible the data connector itself changed and is suddenly populating mail with a value object that's null or empty, causing the counts to match where they didn't before.

What changed in 3.4 was the SourceAttribute mess and the handling of dependencies, but none of that really changed how value counts got compared that I know of. Unless there was some difference in the way the values were turned into string data for the template and it used to detect the empty/nulls and now doesn't.

-- Scott