Unexpected behaviour – expected taking preferred rank over normal rank

[mzeinstra]

Not sure if this is a feature or a bug :)

When adding multiple last names I expected that the extension would take the first 'preferred rank' instead is taking the first entered statement.

I expected this case to resolve the Label to "M wrong use of last name".

[JeroenDeDauw]

Should be fixed now.

Apparently I got confused when I wrote the docs. I never implemented this for building values. Only for finding matching entities via entity criteria.

[mzeinstra]

Is this deployed on the demo wiki?

If so, not sure it is fixed (or if not part of spec). In the attached screenshot I expected the label to be 'Pjotr Hein' instead of 'Piet Hein', since Piet is the deprecated rank and Pjotr is the preferred rank.

[JeroenDeDauw]

Oh sorry, not deployed yet :)

[JeroenDeDauw]

Should now be deployed on the demo wiki

[mzeinstra]

Not sure if this works as expected.

Do both ranks of First Name and Last Name need to be in sync? In the screenshot below I expect Pjotr Hein, not Pjotr. Also the aliases appear to be missing but present in Q4

[JeroenDeDauw]

I implemented the wrong behavior. The statements where getting filtered on the item level. So as soon as there was on preferred one, all normal ones would be ignored, even if there are no preferred ones for the same property.

Fixed now by filtering on statement group level. Deployment started, will be live in ~5 min.

[mzeinstra]

Verified that this now works as expected.