SharePoint: Bamboo Lookup Selector bug lists pages

The Bamboo Lookup Selector is a custom lookup field that has (or: would have...) some nice features, like for example filtered selection.

The problem is that sometimes it doesn't work, because of many bugs in the implementation.

In my case, in particular, in edit form the original value is not set correctly in the control. This causes problems to the client, of course, because he is disappointed, when editing an item, to find the values of field changed (because the control in the edit form is not initialized correctly), and has caused me to write additional JavaScript code, in the edit form, the correctly select the correct item.

Anyway, for future reference, here are the bugs lists pages:

SharePoint: how display related (with lookup) records

Since SharePoint 2010, it is possible to customize the OOTB display form of a list item, to display the related items, i.e. the items that have a lookup field pointing to this item.

And in the end the customization is very simple: customizing the list (or content type) display form, it is possible to add the related list directly (and not a ListView web part). And it is possible to customize this list too, through a view, to customize columns to display, sorting and filtering (in addition to the filtering given by the connection to the main record).

A complete example showing this process is displayed in the blog post Showing Related List Items in List Display Form Sharepoint 2010.

Bamboo Calendar for SharePoint: a problem with permissions...

Today I have worked with Bamboo Calendar for SharePoint.

It is nice, its main features are:

  • possibility to merge 2 or more calendars
  • possibility to give colors based on metadata

It has two main drawbacks:

  • it is slow; not slow, it is really very slow;
  • it is not consistent with permission in the SharePoint object model.

 

About the last point, I explain here: I have an Intranet site where public visitors don't have read access on the site, but only on some lists and/or folders and of course pages.

If I use the OOTB calendar, everything works fine. But with Bamboo Calendar, I need to give read access to the site and read access to the list, even if I want to get data from a folder only.

This is terrible, because it changes all the permission model I had prepared (and that was fitting the reality very well, while now I had to break inheritance in almost all the lists, to protect them) and is less secure because new content will have, by default, public access.

Btw I tought it could be a problem of asynchronous calls (maybe AJAX call when changing month) but nope.

 

My final evaluation is: not so good, and I would avoid using it, unless explicitly requested by the client (as in this case).

SharePoint: iid attribute of a List View web part

SharePoint renders list view web parts giving an attribute iid for each tr in the resulting table.

The structure of this iis is: contextID,itemID,objectType.

I understood alone the itemID, I was not sure about the contextID (even if I've understood that it was the same for all the rows, so useless) and I was not sure about the objectType, if it was instead the versionID.

Anyway the blog post The magical IID attribute in SharePoint List Views has helped me, together with the jQuery selector to retrieve the itemID:

var id = $(“tr.s4-itm-selected”).attr(“iid”).split(“,”)[1];

SharePoint: comments with history

In SharePoint OOTB it is possible, for multi-line text fields (like typically comments and notes) to enable versioning of changes of the field only (without the need to go to the version history of the item).

For this, it is necessary, first of all, to enable versioning in the list itself (from List Settings, Versioning Settings, Item Version History, Yes).

Then, in the multi-line text field, in the Additional Column Settings, set Append Changes to Existing Text to Yes.

 

SharePoint: access denied to the root site even if granted access to the default page

Today I had a problem: even if visitors had access to the site home page, when pointing to the site url directly, they got an Access Denied error, instead of being redirected to the home page.

I have done some research on Internet and it seems that enabling anonymous authentication at the web application level, and then removing it, is able to fix the problem (!).

 

Here some links I have found:

SharePoint: how add web part to DispForm, NewForm, EditForm pages without Designer

I'm working in a environment where SharePoint Designer is not allowed, and above all even server-side development is forbidden.

 

To customize DispForm, NewForm and EditForm pages, I needed to find the following pages helping me:

SharePoint field definition: DisplaceOnUpgrade="TRUE"

When coding SharePoint features to deploy fields and content types, a common problem is that when upgrading the solution, fields are not upgraded too.

The reason is that each field definitions should contain the following line:

DisplaceOnUpgrade="TRUE"

In this way, when upgrading the solution, even if the field is already found, it is upgraded.

 

To upgrade content types, adding or removing fields, SharePoint 2010 introduced the concept of UpgradeActions, as described in my other blog post SharePoint 2010: feature upgrading.

SharePoint: choosing between Custom Web Templates and Custom Site Definitions

SharePoint 2010 introduces the concept Web Templates of SharePoint 2010, that should take over the Site Definitions.

In the article Deciding Between Custom Web Templates and Custom Site Definitions it is described that:

  • the prefered approach is to use now Custom Web Templates instead of Custom Site Definitions;
  • there are a few exceptions when Custom Site Definitions have still to be used.

 

Advantages of Custom Web Templates are:

  • They can be modified without affecting existing sites, while Site Definitions are immutable to maintaining them requires to create new and updated versions, and instruct the users to use the latest version... (not very user friendly);
  • They can be deployed in Sandboxed Solutions and SharePoint Apps too, while Site Definitions require farm solutions.
  • They are easier to upgrade with next versions of SharePoint