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

Strange But True: Reading Timesheets

According to the Project 2010 SDK, there's little difference in using TimeSheet.ReadTimesheetByPeriod - "Gets the timesheet header, line items, and timephased data based on the specified period and resource." - or TimeSheet.ReadTimesheet - "Gets the specified timesheet header, line items, and timephased data." - except the number/type of parameters; the first method takes in the resource ID, period ID and "navigation", the second just the timesheet ID.

The fact is i've been getting a different number of timesheet lines by calling one or the other, being TimeSheet.ReadTimesheetByPeriod the one that returns fewer lines. It can't be an issue with the tasks/assignments because they are visible in the Timesheet web form, and even if that was the case, there would still be no explanation why those lines are returned by TimeSheet.ReadTimesheet.

In any case, here's a simple workaround:
  TimesheetDataSet timesheetSet = timesheetClient.ReadTimesheetByPeriod(resourceUID, periodUID, SvcTimeSheet.Navigation.Current);
  timesheetSet = timesheetClient.ReadTimesheet(timesheetSet.Headers[0].TS_UID);

Soundtrack for this finding:
Megadeth - Skin O'My Teeth, Foreclosure Of A Dream