EditPage in Site Actions is disabled (MOSS 2007)

Have you ever tried to edit a page and found that the Edit Page was disabled or wouldn’t even show up under Site Actions.

This may happen due to several reasons:

1. By default all List's "NewForm.aspx", "EditForm.aspx" and "ViewForm.aspx" page's Site Action menu will show Disabled Edit Page menu item.
2. If the page is currently checked-out by another user, it will show Disabled Edit Page menu item
3. A master page customization may have hidden the site actions menu or a custom feature may have hidden the “Edit Page” menu item.

So, how do we edit a page if we can’t see the “Edit Page” menu item and select it.

A quick way to get any page into the Edit Mode is by adding “ToolPaneView=2” to the url.

For e.g.: If you are trying to get the default page at http://mysharepoint.corp.com/default.aspx in edit mode, change the url to: http://mysharepoint.corp.com/default.aspx?ToolPaneView=2. This will show you the same page in edit mode.

Happy editing.

SharePoint Object Model – Users

Have you ever tried listing the users for a site collection from the object model and realized that the list isn’t what you expected? I ran into that recently and realized that there were several ways to get to the users and there are subtle differences in the results. Here is a quick listing:

SPWeb.AllUsers Property (Microsoft.SharePoint)

Gets the collection of user objects that represents all users who are either members of the site or who have browsed to the site as authenticated members of a domain group in the site.

SPWeb.SiteUsers Property (Microsoft.SharePoint)

Gets the collection of all users that belong to the site collection.

SPUtility.GetAllAuthenticatedUsers Method (Microsoft.SharePoint.Utilities)

Returns All authenticated users of a site

SPAlertCollection.GetUniqueUsers Method (Microsoft.SharePoint)

Returns a string array that lists all the users of a site, without listing them more than once, who receive alerts for list items.

Sharepoint 2010 - Meaning of Taxonomy...!

You may not be as familiar with the meaning of ‘taxonomy’. Well be perfectly honest taxonomy is a high visibility buzz-word that is often mis-used and certainly means different things to different people. At its core it is about labeling and indexing of global navigation tabs, links, and content so that people can find what they’re looking for. Taxonomy =The labeling and indexing structure of the application; taxonomy as it pertains to web sites is a library science adaptation of the original biological term describing the naming convention for plant & animal kingdoms AND as it applies to SharePoint, the taxonomy is a combination of UI sitemap and the unique nomenclature ascribed to the data nesting, hierarchy, and metadata of the application.

Strategic Information Architecture Plans for SharePoint 2010

As you plan out the Sitemap and Taxonomy for Your SharePoint deployment, it’s important to remember that establishing a logical over-arching Site Structure for your corporate intranet must take precedence over the temptation to implement the latest trends in in personalization and Social Networking technology. Sure, we’re all excited and impressed by the ways that the latest innovations in the Social Network have impacted the way we communicate and stay connected with one another, but that does not mean that turning the Home page of your corporate intranet into a personalized dashboard replete with Facebook-like activity feeds is right way to display the new technologies available to you. Don’t get me wrong, I do find these cutting edge Social Data fed bulletin boards and personalized employee-2-employee communications tools to be useful and compelling; however, they must be utilized carefully as an integrated part of an overall holistic design that supports both the needs of the business and the design constraints of the software platform; for if we fail to plan the sitemap in such a way that supports both the strong and weak aspects of the MS platform itself, then we fail to provide the usability of the communications tools that we sought to promote in the first place. You should always bear in mind the IA’s motto “IT Depends” which refers to the fact that there are no hard and fast “ten commandments” of good information architecture; instead, there are 15-20 flexible heuristics that by necessity change on a case by case basis depending upon the context of the information in focus.

I think You all know what a sitemap is (a diagram depicting the hierarchical relationships between sites, sub-sites, and content nesting structures – sometimes a tree hierarchy \ other times more of an organically evolving hub and spoke model illustrating nodes of data (lists, menus) and their leaves (web pages and applications); however, you may not be as familiar with the meaning of ‘taxonomy’. Well be perfectly honest taxonomy is a high visibility buzz-word that is often mis-used and certainly means different things to different people. At its core it is about labeling and indexing of global navigation tabs, links, and content so that people can find what they’re looking for. Taxonomy =The labeling and indexing structure of the application; taxonomy as it pertains to web sites is a library science adaptation of the original biological term describing the naming convention for plant & animal kingdoms AND as it applies to SharePoint, the taxonomy is a combination of UI sitemap and the unique nomenclature ascribed to the data nesting, hierarchy, and metadata of the application.

IF you are assigned as or have access to an Information Architecture planning resource, THEN You need to understand that MS SharePoint is really 3 applications bundled together on one web delivery platform: Publishing (CMS), Collaboration (Team Sites), and Personalization (My Sites). Some of the enhancements that MS SharePoint 2010 has provided really well are to extend the MOSS ’07 functionality by making enhanced Social Networking features formerly available only within the personalization\ my Sites Sphere now extended to improve employee to employee communications within the Collaboration Sphere (these are tools like ‘ask a question,’ ‘noteboard,’ and ‘people finder’ that originated in the MOSS Personalization sphere and have been observed with greater depth in other best of breed Social Sites like Facebook and Digg out on the larger playing field of public-facing web apps). What SharePoint 2010 still does not do very well (or even at all without extensive custom development) is to extend all of the individual users ‘My Host’ social data across multiple site collections and roll them up to web parts and activity feeds that can be exposed on the top-level Home page.

The architectural reasons for these limitations are 1) that “SharePoint wants the top-level site collection to be an internally public facing publishing site” - this includes the entry level Home page and any additional web-pages contained within that top-level site before linking off into Collaboration and Personalization sites that may be available under global navigation tabs or links off of the home page. And 2) Personalized Content typically displayed on the lower level My Site home pages cannot easily be extended to or exposed upon the top-level (publishing) Home page for every individual User to see differently via dynamic content population via their profile preferences (these functions were designed by MS to take place at a lower level in the system architecture within the separate individual My Sites) or either by redirect to that individual’s My Site home , including web parts like “my favorite links,” “my teams,” “my RSS feeds,” “my News” “my Weather” “People I am following” (my Friends), “Sites I am a member of” (sites I have joined or am following). See the illustrations above for further guidance on the MS application spheres of influence Vis a Vis the MS governance Pyramid (which directly impacts the custom development model).

In My next Blog Post we will take a close look at what the alternatives to these development constraints are and discuss how to best work around the obstacles presented by each opportunity that these challenges present us with. We’ll look at the potential success and possible failure points of each of the logical options such as “Can I make everyone’s individual My Site dashboard the official home page of the Intranet?, and if so, what would that data nesting structure look like with the content that typically resides at the bottom of the pyramid being elevated to the top? “Can I display personalized content on the home page (not by re-directing to the My Site Home for every one of my 50,000 users, but instead by exposing personalized content web parts from the individual employee’s My Sites’ site collections on the overall Publishing home page? – can I then combine that with some feature stapled Internal Marketing web parts that I want everyone to see like “Company News” and “CEO’s Corner - A Message from Our Leadership?), and Lastly, we’ll take a closer look at the opportunities being opened up by third party innovators like Newsgator and bamboo Solutions.

Deployment and security options of custom code in SharePoint 2010

In SharePoint 2010 there are more ways to deploy custom code than in its predecessors, the reason is the introduction of the Sandboxed solutions. There are basically now three different ways to deploy custom assemblies:

• Full trust solutions/ Farm solutions - The assemblies are registered in the GAC and runs under full trust
• Partial trust solutions/ Web Application solutions - The assemblies are deployed to the bin folder of a specific Web Application
• Sandboxed solutions/ User code solutions - The assemblies (solutions) are deployed to the Site Collection gallery

These are the basic variants of how to deploy custom assemblies. There are actually a few variants of them, but more about them later. So which one should I use and when? Let's go through them all and look at the pros and cons.

Sandboxed Solutions

The Sandboxed Solutions runs inside the a special service, called Microsoft SharePoint Foundation Sandboxed Code Service, which is a completely and separate application domain than the SharePoint application pools. The Sandboxed solutions are monitored and if they consume to much resources or fails to many times SharePoint automatically shuts the solution down. The code running in a Sandboxed assembly does not have access to the full SharePoint API, basically it's just the classes from Site Collection level and below. The sandbox is also protected with a very minimal CAS policy which for example prohibits the user code solutions from calling web services, making database calls or accessing the file system.

Sandboxed solutions are deployed into the Solution gallery of a Site Collection and only access that Site Collection. They can be deployed without having any downtime of the farm or web application. Anyone within the Site Collection Administrators group can upload solutions to the gallery and activate them. Farm administrators controls how much resources each Sandbox can use and can also block specific solutions from running at all.

Pros	Cons
Can easily be deployed by Site Collection Administrators	Very limited CAS policy
Resource usage is monitored	* Current uncertainty about the monitoring stability
Secure	Hard to deploy in a farm
Great support in Visual Studio 2010
Only crashes the Sandbox if it blows

Farm Solutions

The Farm solutions or full trust solutions adds the assembly to the Global Assembly Cache, GAC, which means that they can run without any CAS policies, i.e. under full trust. The assemblies can be accessed from any application in the farm. Full-trust solutions are (was?) the most common way to install solutions since it is easy and requires no knowledge of for instance CAS policies. The code running in a full trust solution has the same access as the application pool account to the local server and can do almost what it want with the server. Deploying Farm solutions should only be done with code that you really trust.

Only farm administrators can upload new farm solutions to the configuration database and most often an application pool recycle is needed, especially when updating solutions.

Pros	Cons
Easy to implement	Only Farm Administrators can add new solutions (can be a pro also :-)
Great support in Visual Studio 2010	Downtime when updating
Runs in full trust	Have to much privileges
	Can crash the whole server

Web Application Solutions

Solutions deployed to the web application bin directory was the way to go in SharePoint 2007 when you wanted/needed to secure you application using CAS. This partial trust option is still valid in SharePoint 2010. Web application deployed solutions by default only have a very minimal CAS policy applied. Using custom CAS policies it is easy to give more privileges to assembly. Installing these solutions also requires a Farm Administrator but they are only applied to specific Web Applications. Updating the assembly does not require an application pool recycle.

Visual Studio 2010 have support for Web Application deployment but not for custom CAS policies. If you need custom CAS policies you need to hack some XML and you cannot use the F5-debugging experience in Visual Studio. Instead you have to install the solution using PowerShell or create your own Visual Studio SharePoint Deployment Steps.

Pros	Cons
Security policies can be configured and kept minimal	Only Farm Administrators can add new solutions (can be a pro also :-)
Minimal downtime when upgrading	No support OOB for custom CAS policies in Visual Studio 2010
Only crashes the web application

Sandboxed Solutions with User Code Proxies

There is actually a fourth option of deployment. And that is to use Sandboxed Solutions in combination with a full-trust User Code Proxy. A User Code Proxy is a special assembly and class that is registered in the GAC and running under full trust. This class exposes an operation that can be called by the Sandboxed code. Since it runs under full trust we can easily create a Proxy Operation that calls a web service or access other protected (from the Sandbox) sources. The proxy has to be registered by a farm administrator and is accessible to the whole farm, which means that all developers who knows about the assembly, class and operation can use the operation.

Since the User Code Proxy runs under full trust you need to be careful about that one. But if you design your application carefully the proxy operations should be kept to a minimum and quite small. This allows you to make the thorough code review on only a fraction of the whole application.

Tip: Make the User Code Proxies as Farm solutions which are registered using Feature activation and unregistered using deactivation of the Feature. Then your farm administrators can enable and disable them easy!

Access denied within SPSecurity.RunWithElevatedPrivileges

Learned something really interesting (and a few lessons) in the last few days. We were doing an operation within a webpart which required higher level of access. Since this was to be executed irrespective of the access of the user logged in, we had the code enclosed within the SPSecurity.RunWithElevatedPrivileges. Surprisingly the code was failing and showing "Error : Access Denied". I remembered having seen this issue earlier on another project. That time we had a workaround which looked elegant and we didn't need to investigate the root cause. But now things were not as good and made me think this was going to be a bummer. Luckily I was able to figure it out in time. Let me explain this with the below code that throws access denied even though it is wrapped within the SPSecurity.RunWithElevatedPrivileges.

The code is part of a webpart that just displayed all the users in the owners group of the current site. This code runs fine with users having Full control or Contribute access. But fails for users having only Read access.

Label labelUsers;

protected override void CreateChildControls() {

labelUsers = new Label();

this.Controls.Add(labelUsers);

SPSecurity.RunWithElevatedPrivileges(delegate() {

SPSite site = SPContext.Current.Site;

SPWeb web = SPContext.Current.Web;

SPGroup group = web.Groups.GetByID(3);//get the owners group

if (group != null) {

StringBuilder users = new StringBuilder();

for (int cnt = 0; cnt <>

users.AppendFormat("{0},", group.Users[cnt]);

}

labelUsers.Text = users.ToString();//display it on the label

}//End of "If" block

});//Close "SPSecurity.RunWithElevatedPrivileges" block

}

This code throws an exception for Read users at the line "for (int cnt = 0; cnt <>This line fails when the Users collection withing the SPGroup it being accessed.

Looks like the SPSecurity class is not behaving correctly here but lt is working perfectly in the way it is supposed to.Though the entire code is enclosed within SPSecurity.RunWithElevatedPrivileges not all code is able to run with the elevated privileges. So the rule is -- The code will not run within elevated privilege if the object accessed was not created within the SPSecurity.RunWithElevatedPrivileges block. If we take a relook at the code we can see that the instances of SPSite (i.e. site object ) and SPWeb (i.e. web object) are retrieved through the current SPContext. The SPContext is created much before our elevated privilege code runs. Accessing the child objects of the SPWeb instance in form of "web.Groups.GetByID(3)" returns a SPGroup object which will also fail to run within the elevated privilege. And once we (with only read access) try to access the Users collection within the SPGroup object Sharepoint rings the bell indicating the information is classified. It throws you out of execution by rasing an exception.

Now that we know the reason for the error, the problem doesn't look too tough and in reality the solution is simple. To run this code successully we need to create the SPSite and SPWeb instances within the SPSecurity.RunWithElevatedPrivileges. So we have the new code below (the changes are highlighted)

Label labelUsers;

protected override void CreateChildControls(){

labelUsers = new Label();

this.Controls.Add(labelUsers);

SPSecurity.RunWithElevatedPrivileges(delegate(){

SPSite site = SPContext.Current.Site;

SPWeb web = SPContext.Current.Web;

using (SPSite newSite = new SPSite(site.ID)) {

using (SPWeb newWeb = newSite.OpenWeb(web.ID)){ //Do not use the site object to create the SPWeb instance else the code will still fail

SPGroup group = newWeb.Groups.GetByID(3); //get the owners group

if (group != null) {

StringBuilder users = new StringBuilder();

for (int cnt = 0; cnt < style="font-family: Consolas; font-size: x-small; ">

users.AppendFormat("{0},", group.Users[cnt]);

}

labelUsers.Text = users.ToString();

//display it on the label

}// End of "If" block

}// End of using for SPWeb

}// End of Using for SPSite

});//End of SPSecurity.RunWithElevatedPrivileges

}

This code now works beautifully.

With some more space to write let me jot down the lessons learned (little bits of wisdom we cannot afford to ignore ;-) )

Lesson 1 - Just putting your code within SPSecurity.RunWithElevatedPrivileges does not guarantee your code to run successfully irrespective of the access of the user logged in. You may want to look at the code carefully when writing it and look back at it again once you have written thinking that it will work fine no matter what.

Lesson 2 - No matter how confident you are with your code, its always better in sharepoint to unit test your code with all three types of user access (i.e. Owner/Full control access, Members/Contribute access and Read/Visitor access). I have made it a point to write my unit tests with all the three types user access in consideration and hopefully will be able to avoid similar mistakes in future.

10 reasons to use Sandboxed Solutions

• Sandboxed solutions are secure.
• Sandboxed solutions can be monitored.
• Sandboxed solutions do not affect other sandboxed solutions, well atleast not in other site collections is what I mean.
• Sandboxed solutions do not touch the file system for the most part
• Sandboxed solutions skip application pool recycles, so debugging is not such a pain.
• Sandboxed solutions allow the site collection administrator to perform deployment and upgrades
• Sandboxed solutions make CAS policies look like the out of style hairstyles of 1980s
• The Solution validation framework for sandboxed solutions is exntensible, simply inherit from the SPSolutionValidator base class.
• Sandboxed solutions remove the need for line by line code reviews
• Sandboxed solutions allow you to offer different level of SLAs to different site collections using Resource Quotas.

What is supported by sandboxed solutions?

Basically it is a narrowed down subset of the SharePoint OM. This is controlled with VS2010 by selecting your Visual Studio project as a sandboxed solution. It will hide any methods/classes that are not available automatically.

The following capabilities and elements are available in sandboxed solutions:

• List definitions
• List instances
• Onet.xml
• WebTemplate Feature element instead of Webtemp.xml
• Content Types/Fields
• Navigation
• Module/files
• Feature callouts
• Web Parts derived from WebPart
• Event receivers
  • SPItemEventReceiver
  • SPListEventReceiver
  • SPWebEventReceiver
• Custom Actions
• Workflows

What is not supported by sandboxed solutions?

The following capabilities and elements are not available in sandboxed solutions (from MSDN):

• Custom Action groups
• HideCustomAction element
• Content Type Binding
• Web Application-scoped Features
• Farm-scoped Features
• CustomPropertyToolPart Class
• programmatic workflow

• Event receivers
  • SPLimitedWebPartManager
• timer jobs
• visual WebParts
• SharePoint mapped folders (e.g. "_layouts", and "images")

The following .NET namespaces are not supported by sandboxed solutions:

• ADO.NET
• System.IO
• System.Security.Cryptography
• System.Web.UI.ClientScriptManager