Geoff Varosky's Blog

Published just today on Microsoft TechNet, are two great interactive technical references for MOSS 2007 and WSS 3.0 STSADM command options. If you use the STSADM utility at all, and ever need a reference, this is an excellent option.

There are two separate versions, one limited to WSS 3.0 commands, and a second for MOSS 2007 only commands available via STSADM.

WSS 3.0: http://technet.microsoft.com/en-us/windowsserver/sharepoint/dd418924.aspx

MOSS 2007: http://technet.microsoft.com/en-us/office/sharepointserver/cc948709.aspx

When I presented my session on Developing Custom Actions within SharePoint at the Boston SharePoint Saturday conference, I had mentioned a link for a listing of SPBasePermissions that is on MSDN, within the WSS 3.0 SDK, for use with the Rights attribute within the CustomAction element. This attribute defines what permissions are required for the Custom Action to be visible to users.

That link can be found here: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spbasepermissions.aspx

For others reference, and my own personal reference, I have a copy of this listing of SPBasePermissions here.

Building out workflows using SharePoint Designer is a great way to create basic, and even complex workflows for SharePoint without having to know C# or VB, or ever having to open Visual Studio. Sure, there are some drawbacks, such as ease of reusability, but, this extends the power of SharePoint down to non-developers to be able to drive business processes in SharePoint.

Like SharePoint itself, SharePoint Designer built Workflows can be extended as well, to create custom actions to do more with SharePoint Designer workflows than what comes out of the box.

The main point of this post is to direct you to two great projects on CodePlex that have done just that:

• iLoveSharePoint SharePoint Designer Actions 1.0: http://www.codeplex.com/iLoveSharePoint/Release/ProjectReleases.aspx?ReleaseId=20898
  
• Useful SharePoint Designer Custom Workflow Activities: http://www.codeplex.com/SPDActivities

Both of these projects fill some of the voids with SharePoint Designer workflow actions, such as the ability to send emails with file attachments or list item attachments, start another workflow.

The following code snippets are from a web part I built for a client, to assist them with generating new sites. There were new sites being created a few times a day, that all needed to follow similar configurations, but, were all based on the blank site template. Security and other things needed to be modified easily from a single, central interface, which only Site Collection Administrators could access. Each site had to follow several different business rules, and almost every one needed to apply a different set of these, so thus, the web part was created to handle this, as creating site definitions for every possible outcome of the business rules, would have required a new site definition for almost every one of the hundreds of sites that were being created.

One of the thing they needed to be able to manage from their initial configuration, is to be able to allow or not allow search visibility into that site.

The following code snippet will allow you to do just that. (web below is a reference to the specific SPWeb object). Some definition, as well as links to the WSS 3.0 SDK are below the code snippet.

   1: web.AllowAutomaticASPXPageIndexing = true;

   2: web.ASPXPageIndexMode =WebASPXPageIndexMode.Always;

   3: web.NoCrawl = false;

   4: web.Update(); 

By setting AllowAutomaticASPXPageIndexing to true, this will allow indexing of the ASPX pages within the site by the search crawler.

ASPXPageIndexMode specifies the type of page indexing that will occur. Check this reference in the WSS 3.0 SDK which specifies all values possible for WebASPXPageIndexMode. By setting this to Always, ASPX page indexing is always enabled.

Setting SPWeb.NoCrawl, if set to false, will allow crawling of the site.

Now, using the combination of the three above, this will allow indexing of everything, including the ASPX pages within the site to be crawled. If you wanted to crawl everything else within the site, however, did not want to crawl the ASPX pages themselves, you would use the following:

   1: web.AllowAutomaticASPXPageIndexing = false;

   2: web.ASPXPageIndexMode =WebASPXPageIndexMode.Never;

   3: web.NoCrawl = false;

   4: web.Update(); 

A common configuration for my clients is to have an external facing site collection, which aggregates project sites for their vendors and customers that they interact with to collaborate on projects, for example: https://partners.company.com. Where each of the sub-sites below the top level site have specific permissions configured to only allow the external users related to a particular project only into those sites, so those users have no idea what other clients, vendors, etc., you are managing sites for.

There are some sites which are extremely customized from a basic project style template, and/or site definition, and for those sites, there may be quite a few sub-sites. In those cases, it usually makes sense to put reusable web parts into the web part gallery for that site collection, to make them easy to access.

For instance, a Content Query Web Part which displays data out from a source list with data that is relevant to all of those sites, or filtered to display some of the content out to different sites. Instead of rebuilding, or exporting/importing the web part each time, dropping it into the web part gallery makes access to it easy.

If you then give control to the external users of that site to add web parts to that site, they can then see those web parts, and even add them to their pages when attempting to add web parts to their sites. If you have these web parts grouped or named based on the client/partner/vendor/project, they will be able to see those names. Unless they have access however, they will not be able to view the content from those sites if the web part is pulling any data from them, thanks to security trimming.

So, if you are using those sorts of naming and grouping conventions with the web part gallery under this type of scenario, you may want to modify the permissions of those web parts in the gallery to only users who should be seeing them.

This can be done by going to the Web Part Gallery at the Site Collection Level, selecting the edit link of the web part, and clicking on the Manage Permissions link within the toolbar at the top of the edit page:

From there, select Edit Permissions from the Actions menu

And you can then add/remove permissions as needed, thus allowing you to limit exposure of clients/partners/vendors to those sites that should be seeing them.