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.
Anyway, for future reference, here are the bugs lists pages:
This week I had another problem with Bamboo Lookup Selector component.
The referenced item had a double pipe in the title (||), and this mad the child item not be able to reference it: during its saving, I got a (not meaningful) error.
The solution has been to rename the parent item.
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.
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 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(“,”);
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.
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:
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:
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:
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 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