SPGridView Paging and Filtering

A common issue with SPGridView is to enable paging: the PagerTemplate property of SPGridView needs to be set as null. If the SPGridView is declaratively defined in aspx page, the following code won't enable paging:

<sharepoint:spgridview id="SPGridView1" runat="server" >
<pagertemplate ></pagertemplate>
</SharePoint:SPGridView>

instead the following code works:

protected override void OnLoad(EventArgs e)
{
SPGridView1.PagerTemplate = null;
}

After paging is enabled, another common issue is, filter is off after navigating pages. I know filter is off acturally on every subseqent postback, like sorting. But to some degrees, it makes senses to turn it off since users are given no indication that a filter is on otherwise, which can certainly cause some confusion. But turning filters off on paging is very unsatifactory.

Inspired by the idea in this post, here is what I did to enable filtering across pages (based on .Net 3.5):

first cache filter settings :

protected override void OnPreRender(EventArgs e){

ViewState["FilterExpression"] = ObjectDataSource1.FilterExpression;

base.OnPreRender(e);

}

secondly, set filterexpression when postback is from pagings:

protected override void CreateChildControls() {

arg = (string)req.Form["__EVENTARGUMENT"];
if (arg.StartsWith("Page$") && ViewState["FilterExpression"] != null)

ObjectDataSource1.FilterExpression = ViewState["FilterExpression"].ToString();

}

related reference:

http://geekswithblogs.net/mnf/archive/2005/11/04/59081.aspx (.Net 2.0)

http://forums.asp.net/p/1067215/1067215.aspx (.Net 3.5)

Activating Sharepoint Timer Job

The best pratice to create a custom sharepoint timer job is to create a feature with web application scope and to instantiate a SPJobDefinition there. This is becuase it is application pool id's credentail that is used during feature activation, and only central admin pool id which is farm account has sufficient privilege.

When activating from other web application whose pool id is not farm account (by best practice, it should not), you may see one or both errors as follow:

• In browser, "unknown error" and in window event log, "EXECUTE permission denied on object 'proc_putObject' "

Cause: application pool id doesn;t (and should not) have write permission to config database

Workaround: assign application pool id as db_owner of sharepont config database

After that, you might get anohter error (if the app pool id is not sharepoint server local admin) when you try to activate (with permission on config database, you can now unactivate feature, but not activate)

• In browser, "HTTP 403 error (someone saying 404 error), and in ULS log, "...Microsoft\SharePoint\Config\bd189eb6-92d0-4ca5-87b0-770f542e3f0a\cache.ini' is denied"

Cause: Sharepoint need to cache timer jobs in WFE (so it doesn't need to get them from sql as often as every minute) and app pool id (in WSS_WPG group) doesn't have that file permission. In contrast, farm account in WSS_Admin_WPG has full permission on the folder of "C:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint".

Workaround: assign full control permission to application id for that folder or add app pool id into WSS_ADMIN_WPG group.

But the real solution is to activate timer job feature in the central admin, which means you need to create a feature of web application scope.

SharePoint databases part 2

part 1 outlines sharepoint databases and database backup. This part will focuse on secrity: what sharepoint accounts have access to sharepoint databases and in what roles.

SharePoint_config database:

• install account is its dbo
• farm account (and local admin) in db_owner role
• application pool account in WSS_Content_ApplicationPoolid role

Central_Admin database:

• same as config except that local admin is not in db_owner role

Content database:

• farm account is dbo
• app pool account and ssp service account are in db_owner role

SSP (and SSP Search DB):

• same as content database, plus search service account is in db_owner

Server Roles:

• Install account has dbcreator fixed server role & securityadmin fixed server role.
• Farm account has the same fixed server role, but it is automatically configured.
• other service only has public server role.

Understanding those and sharepoint application pool id (see this) can help to solve a lot sharepoint database permission issues such as :EXECUTE permission denied on object 'proc_putObject' in event log tells that the application pool id doesn't have write permission on configure database.