"No exact match" - the SharePoint Online error that went under the radar

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.

My take on the "Cannot add the specified assembly to the global assembly cache (...)" issue

I got this when updating a WSP, on a SharePoint 2013 server. Tried the suggested IISReset, Timer Service restart... no luck. This however worked like a charm:

[System.EnterpriseServices.Internal.Publish] $publish = new-object System.EnterpriseServices.Internal.Publish
$publish.GacRemove("c:\windows\microsoft.net\assembly\remaining-path-to-trouble.dll")

Publishing content types, 'site could not be retrieved'

"Job: MetadataSubscriberTimerJob skipped processing a site 'http://meSite' which could not be retrieved."

I got this while trying to push published content types, into a site collection that I had previously moved to a different content database, but without performing the necessary IISReset.

Even after the IISReset, I still got the same error ... but a restart of the Timer service goes a long way.

The Ilusive jsGrid (V)

And now something long due: how to display comboboxes/dropdowlists on the jsGrid.

So at a given point in your code you'll have - i hope - something similar to this:

GridSerializer gds = new GridSerializer(SerializeMode.Full,
dataTable,
"key",
new FieldOrderCollection(),
GetGridFields(),
GetGridColumns());

Your GetGridFields() function should resemble this:

protected IList GetGridFields()
{
   List row = new List();
   foreach (DataColumn iterator in dataTable.Columns)
   {
      GridField field = new GridField();
      field = FormatGridField(field, iterator);
      row.Add(field);
   }
   return row;
}

Now let's focus on FormatGridField(gridField, dataColumn). Let's say the column that should display the comboboxes is named "brands". This is what should be included in your FormatGridFields(...) function:
(...)
if (dc.ColumnName == "brands") //our combobox column
{
   gf.PropertyTypeId = "myLookupTable"; //Use whatever name you want here; just be aware that it will be used on the js file where the GridManager is instatiated
   gf.Localizer = (ValueLocalizer)delegate(DataRow row, object toConvert)
   {
      string brandName = (string)row["brandName"];
      return toConvert == null ? "" : brandName;
   };
   gf.SerializeDataValue = true;
   gf.SerializeLocalizedValue = true;
}
(...)

That's all on the server side.

As for the js file where the GridManager is instatiated, you'll have something similar to this:
GridManager = function () {
   this._jsGridControl = null;
   this.Init = function (jsGridControl, initialData, props) {
(...)

Add this inside that same function:
SP.JsGrid.PropertyType.RegisterNewLookupPropType('myLookupTable', brandsArray, SP.JsGrid.DisplayControl.Type.Text, false); //Remember "myLookupTable" from before; it's up to you to get the brandsArray filled with the possible values; i use an hiddenfield, then move the contents into the array.

(a couple of lines below)

jsGridParams.tableViewParams.columns.GetColumnByKey('brands').fnGetEditControlName = function () { return SP.JsGrid.EditControl.Type.ComboBox; } //"brands" is the name of the column
jsGridControl.Init(jsGridParams);

That's all there is to it - (from top to bottom) tell the grid that the EditControl for the column is a ComboBox; also, register the lookup table that contains all the possible values; change the server side code so that the combobox displays previously saved values.

I hope this is useful.

Soundtrack for this finding:
Haven't heard much music lately, but "Bandoliers" by Them Crooked Vultures certainly played a part.

The Ilusive jsGrid (IV)

Here we are again! So, let's say we want to mess around with rows availability: disable this one, enable that one depending on some other cell value...

First stop (not exactly, just sort of): (on GridManager.Init()) jsGridControl.SetDelegate(SP.JsGrid.DelegateType.GetRecordEditMode, myGetRecordEditMode);

This is what myGetRecordEditMode should look like

function myGetRecordEditMode (record) { ... }

Now, let's say our table has a column named 'status', containing integers (that represent different statuses), and that for some statuses (like '0' or 'Draft') the corresponding row should be editable, and for others it should be read-only (like '5' or 'Closed'). It's easy:

function myGetRecordEditMode(record) {
if (record.properties['status'].dataValue == 0) //Draft
return SP.JsGrid.EditMode.ReadWrite;
if (record.properties['status'].dataValue == 5) //Closed
return SP.JsGrid.EditMode.ReadOnly;
return SP.JsGrid.EditMode.ReadOnlyDefer; //All other status
}

The star of the show here is the «SP.JsGrid.EditMode» enum - this is its definition: SP.JsGrid.EditMode={ ReadOnly: 0, ReadWrite: 1, ReadOnlyDefer: 2, ReadWriteDefer: 3, Defer: 4 }; more details here microsoft.sharepoint.jsgrid.editmode (warning: this is the server-side counterpart, but it fits the purpose). It helps making row enabling/disabling quite simple; the real trick - and this is why in the previous code example all other status get the SP.JsGrid.EditMode.ReadOnlyDefer value, and not just SP.JsGrid.EditMode.ReadWrite - is mixing row editability with column editability. I'll provide more details in a future post.

AllowUnsafeUpdates + Workflow = Disaster

Having worked on numerous occasions with custom permissions - adding, removing ... - i've used the SPWeb.AllowUnsafeUpdates property extensively to avoid the "security validation exception, go back" thing. Recently, i had the need to once more deal with custom permissions but for the first time within workflows. So, right away i used AllowUnsafeUpdates to prevent getting the "security validation" exception.

I must say i came very close to tear my own scalp off, because despite having used AllowUnsafeUpdates to the best of my ability, i was still getting slapped with that same exception locking workflow instances with "Failed on Start (retrying)" over and over again.

Moral of the story: the AllowUnsafeUpdates is as useful to the SharePoint workflow runtime, like a shotgun in Chuck Norris's hands. So don't use it.

Soundtrack for this finding:
No music here 'though "Highway to Hell" would've been the perfect choice

Required fields and the check in/out mechanism

This probably very, very basic but i only realized it the hard way: having required fields on a document library, causes all new/uploaded files/items to be checked out automatically, even if the "Require Check Out" list setting is not enabled. Aditionally, no workflow instances will start as expected - lock on "Starting" - until those files/items are checked in.

Soundtrack for this finding:
No music here