A colleague asked me about removing some of the templates/site definitions that are available when creating SharePoint sites. Actually It’s so simple.
To hide a template from users :

1) Open the Webtemp.xml file located in the the 12 hive /template/1033/XML folder.
2) Change the Hidden parameter of the template(s) you want to hide.
3) Run IISRESET

Note also that you can create your own categories by editing the DisplayCategory value

What is SPContext ?
In a nutshell, SPContext object can be used to get a reference to the site or the web from the current context, It Represents the context of an HTTP request in SharePoint .
For instance :
SPList currentList = SPContext.Current.List;
SPWeb currentSite = SPContext.Current.Web;
SPSite currentSiteCollection = SPContext.Current.Site;
SPWebApplication currentWebApplication = SPContext.Current.Site.WebApplication;
SPListItem item = (SPListItem)SPContext.Current.Item;
SPUser user = SPContext.Current.Web.CurrentUser;

What is “Properties” ?
The properties object holds information about an event. You can use it to get references to SPSite, SPWeb, SPList or SPList Item.
for instance :
SPListItem item = properties.ListItem’

However,
Be VERY careful when using properties parameter or SPContext. You CANNOT use the properties command to create your objects or your code will fail! .
You need to use properties or SPContext to locate the items, then use the items IDs to create the object references. You will never get your code to work the way it is above.
You need to get all of the Guid identifiers BEFORE entering the secure block ( RunWithElevatedPriveleges) or Impersonation, then create all the objects you need WITHIN the secure context

Guid SiteId = SPContext.Current.Site.ID;
Guid WebId = SPContext.Current.Web.ID;
Guid ListId = properties.ListId;
Guid UniqueId = properties.ListItem.UniqueId;
SPSecurity.RunWithElevatedPrivileges(delegate()
{
using (SPSite site= new SPSite(SiteId))
{
using (SPWeb web= site.AllWebs[WebId])
{
SPList list= web.Lists[ListId];
SPListItem listItem= list.Items[UniqueId];
// Code..
}
}
});

or to impersonate the system account using SPUserToken ( Recommended )

Guid SiteId = SPContext.Current.Site.ID;
Guid WebId = SPContext.Current.Web.ID;
Guid ListId = properties.ListId;
Guid UniqueId = properties.ListItem.UniqueId;
SPUserToken systemAccountToken = SPContext.Current.Site.SystemAccount.UserToken;
using(SPSite mySite = new SPSite(SiteId, systemAccountToken))
{
using (SPWeb myWeb = mySite.OpenWeb(WebId))
{
SPList list= web.Lists[ListId];
SPListItem listItem= list.Items[UniqueId];
// Code..
}
}

A few days ago, I wrote event handler code that runs in the security context of the logged in user. SharePoint security model makes it easy to programmatically execute code within the current user context But there were some situations when the code needs to be executed with permissions greater than that of the current user (like instantiating a site collection or enumerating list permissions ).

In such situations, the code needs to be executed with elevated permission level or under the context of user with higher permissions i.e. Impersonation.
As the MSDN documentation says, SPSecurity.RunWithElevatedPrivelege “Executes the specified method with Full Control rights even if the user does not otherwise have Full Control.”
In my experience with Using SPSecurity.RunWithElevatedPrieveleges, there are too much tricks that you should take care of.
For Instance : You must create the new SPSite objects inside the delegate because SPSite objects created outside do not have Full Control even when referenced inside the delegate. Use the using keyword to ensure that the object is disposed in the delegate. The next example shows this. SPSecurity.RunWithElevatedPrivileges(delegate()
{
using (SPSite site = new SPSite(web.Site.ID))
{ // Perform elevated actions here
}
});
The problem is that the SPWeb object from the current context is initialized using the current user’s credentials, so even though we run the code snippet with elevated privileges the actual access to the file is still restricted. To resolve this we have to create a new SPSite/SPWeb object within the elevated code, where we run in the context of the elevated user. Then we can perform the restricted action. Since the SPSite/SPWeb objects are created explicitly we have to also dispose of them.
There’s too much overhead, too much chances of introducing obscure bugs, too much potential abuse when it comes to using SPSecurity.RunWithElevatedPrievelges.

That’s why I’d recommend to use SPUserToken to impersonate the SYSTEM and use elevated privileges.

Fortunately, the SystemAccount SPUser is a property of any SPSite object. So instead of using SPSecurity.RunWithElevatedPrivelege, you can use the following code to perform elevated actions:

SPUserToken systemAccountToken = SPContext.Current.Site.SystemAccount.UserToken;
using(SPSite mySite = new SPSite(SPContext.Current.Site.ID, systemAccountToken))
{
using (SPWeb myWeb = mySite.OpenWeb(SPContext.Current.Web.ID))
{
// Perform elevated actions here
}
}

As I have been working to develop an event handler that will be used to mirror a Document Library, I’ve come across an interesting tid bit that was frustrating at first.

It’s worth mentioning that in MOSS 2007, Event Handlers execute in the context of the current user rather than the process user in SharePoint 2003 .

The event handler contained the following piece of code :
using( SPWeb web = SPContext.Current.Site.AllWebs[guid] )
{
// code
}

When running as an administrator, the event handler worked fine. However, if you switch to a non-administrative user that doesn’t have full control of the site, you’ll get a lovely exception. The problem is that you must have full control of the site to be able to use the AllWebs property.

To solve this, try the following code:

using( SPWeb web = SPContext.Current.Site.OpenWeb(guid) )
{
// code
}

Happy SharePoint Coding 😀