Up until today, Feb 6th 2019, in order to update a multi-value Person or Group (aka "multiuser") field, something along these lines -
var ctx = SP.ClientContext.get_current();
var list = ctx.get_web().get_lists().getByTitle('someList');
var u1 = new SP.FieldUserValue();
u1.set_lookupId(1); //1 being a known user ID obtained, for example, from the User Information List
var u2 = new SP.FieldUserValue();
u1.set_lookupId(2); //similar to u1
var itemCreateInfo = new SP.ListItemCreationInformation();
var item = list addItem(itemCreateInfo);
item.set_item('Title', 'My New Item!');
item.set_item('MUser', [u1, u2]); //MUSer being a Person or Group column allowing multiple values
item.update();
ctx.executeQueryAsync(function() { console.log('OK!'); }, function(s, a) { console.log(a.get_message()); });
- worked fine on a classic-experience site, in SPO. But for some reason, it just stopped working, with a.get_message() returning something like "no exact match was found" (or "we couldn't find an exact match"). Oddly enough, this error message, while somewhat cryptical, did provide some indication of what was going wrong. Using the out-of-the-box form, it was still possible to save multiple values to the (MUSer) column, it just didn't work when using CSOM/JSOM. And when the column value was retrieved for a previously created item - using ...getItemById(#) - the resulting SP.FieldUserValue array elements, did have something that u1 and u2, from the example above, (as expected) did not have: the LoginName and Email properties filled.
At this point, it was worth trying to get these filled besides just the Id before executing the request, but both cannot be set for FieldUserValue, as they are private properies. Luckily, SP.FieldUserValue.fromUser([loginame or email here]) was available.
As it turns out, the lack of one of those two properties was the cause of the problem -
var u1 = SP.FieldUserValue.fromUser('john.doe@acme.com') is the workaround - but there is still no explanation to what changed in SharePoint Online that led to this (and why!). Even stranger is the fact the so very few people seem to have noticed it.
P.S.: This is a similar problem, but why is a SharePoint 2007 (on-premise!) issue popping up 10 years later in SharePoint Online, is a question only Microsoft can answer.
Soundtrack for this finding:
Can't say I was inspired by music when I cracked this, but I did listen to "Run To The Hills" (Iron Maiden) in the end, just for kicks.
