multiple emails not supported

[pieterdt]

it's not uncommon to have multiple e-mail adddresses linked to your Active Directory users. It is also in the spec that a user can have multiple mail addresses. I noticed that this situation is not handled very well (creation fails). With a small fix I could make it survive the situation, but it would then always take the last mailaddress from the list of addresses, while one might filter for example the primary, or work address (the spec provides ways to filter on those properties). How could I fix that in the mapping, so that it will only validate the primary address?

[pieterdt]

There seem to be 2 problems for handling multiple mailaddresses. 1) The Collection::getSubNode method does a test by comparing the array key with null with only '==' and not '===', doing so let's the first element of an array slip through, while others don't. I doubt this is on purpose? 2) with the fix for 1, (replacing == with ===) it breaks even more and I can't get any mail address mapped.This is because if (!empty($this->collection) && is_array($this->collection[0]) && array_key_exists($key, $this->collection[0])) { does not have any "else" clause to return the anything, which in turn results in an ->add call on null.

Am I wrong about the == vs ===? or is this intentional @arietimmerman ? If I'm wrong, the solution is probably in better preparing the array during flattening?

[arietimmerman]

@pieterdt , the use of == vs === is not intentional. I should have documented this getNode method, but to me it seems indeed that this method is not built with support for collections consisting of multiple complex value. It supports this for reading, but not for writing. It is for sure possible to introduce this support, but seems like that requires a little effort.

[aligot-cblue]

It seems it's the same issue when a profile has multiple phone number: "phoneNumbers": [ { "primary": false, "type": "mobile", "value": "+xxx" }, { "primary": true, "type": "work", "value": "+xxx" } ],

[arietimmerman]

The code for retrieving multi-valued complex attributes has been rewritten in the latest release. This should solve the problems described here.