Using People Editor Control in SharePoint

People Editor or People Picker is SharePoint control which represents a PeopleEditor object in a PeoplePicker control. Would like to discuss the usage of this control in a SharePoint custom page as well as programming with this control.

First you need to add Microsoft.SharePoint reference to your project and then add following line in register tag section

<%@ Register TagPrefix="wss" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

Once we add a reference to the namespace containing People Editor control, it is ready to use. It can be added as below

<wss:PeopleEditor id="peopleEditorTest" runat="server" MultiSelect="false" ValidatorEnabled="true" />

I am not discussing all the attributes/members of the control which can be read from the msdn article http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.webcontrols.peopleeditor.aspx

Now let us see how this can be used through SharePoint object model. Add an object in the cs page to work with the control

using Microsoft.SharePoint.WebControls;

…

protected PeopleEditor peopleEditorTest;

…

Below code can be used wherever you want to save the value of the people editor control such as updating list item, etc

string strValue = string.Empty;

if (peopleEditorTest!= null)
  {
    if (!string.IsNullOrEmpty(peopleEditorTest.CommaSeparatedAccounts))

strValue = peopleEditorTest.CommaSeparatedAccounts;
}

You can get other values such as user name, description, etc by type casting it to Picker Entity.

PickerEntity pe = (PickerEntity)peopleEditorTest.Entities[0]; //gets first user in list
string username = pe.Description;

That’s it.

 

Regards,

Sudhakar Bulli.

Deploying List Definition as a Feature

In this blog post, I am going to talk about how to develop a custom list definition and deploying it as a feature in SharePoint.

Typically a custom list definition contains three xml files

• Feature.xml
• ElementsManifest.xml
• Schema.xml

Now I’ll try to elaborate about each xml file:

Feature.XML This file registers the list template. This file specifies title, ID, scope of the feature and location of elementsmanifest file.

Typically a feature.xml file will be like this.

ElementsManifest.xml This file adds the list template to the Create Page file that identifies the list template and specifies information to display on the Create Page. This file need not be with the same name. Whatever name you give, the same has to be mentioned in the feature.xml file. Give it a Type value that is above 10000 and different from any other custom list definitions used in your deployment and can be like this.

Schema.xml This file defines the list schema, which includes content type associations, field and view definitions, and form and toolbar references. This file has to be in a sub folder under which list definition is created and the name of the sub folder has to be the same name as that assigned to the list template in the previous step, for example, SimpleList. Schema.xml is the file where we can mention, column details, views, etc.

I am not giving screen shot for schema.xml because recommended approach for creating a schema.xml file is take a copy of schema.xml from SharePoint 12 hive folder and customize it per your needs. This can be located at

12\TEMPLATE\FEATURES\CustomList\CustList

All IDs has to be GUIDs which you can create using a GUID builder such as one provided in Visual Studio.

Now all set to deploy a List definition feature. To deploy this, you can use a 3rd party utility which copies all these files in feature folder or you can do it manually. I’ve used codeplex tool WSP Builder to make the list definition and deploy. This can be downloaded from http://www.codeplex.com/wspbuilder . I’ll mention steps to deploy list definition manually.

Copy the entire folder in features folder of SharePoint. Typically this folder can be located in “12\TEMPLATE\ “. Once folder is copied run following command from BIn folder of SharePoint (12\BIN).

stsadm –o installfeature –name <name of the folder>

Once this command is successful, feature is ready in all the sites and ready to activate. You can browse to site settings of a site in which you want to activate the feature or execute the below command

stsadm -o activatefeature -name <name of the feature> -url <site URL>

That’s it.

Summary:

In this blog post, we have learned how to create a custom list definition, deploying it as a feature.

Viewers are welcome with questions.

 

Regards,

Sudhakar Bulli

Scopes in MOSS Search

In this post, I am going to discuss about how to create search scopes and limit search results to that scope.

To create a new Search Scope navigate to your Shared Service Provider web site and click on Search Settings. Scroll down and you will see the Search Scopes section. Click on "View Scopes" and click "New Scope" at the top.

Here we will create a new Scope and call it Team Tasks. We'll use the default results page.

From here we can add rules that will define our Scope. In my case I want the scope to be limited to a specific list so I choose web address and in the folder section I paste the URL of my list, excluding any aspx pages. I choose to Include any item that meets this criteria, i.e. any item that is in this list. Click "Ok" and that is it.

Your new Scope will be ready for use once it is complied which usually happens every 15 minutes or so. You can force the compile by going to Search Setting and clicking "Update Now" under the Search Scopes section. Now the question is how you use it.

To use your newly created Search Scope navigate to the Top Level Site Settings and click on "Search Scopes" under "Site Collection Administration".

From there you can see that your new scope is listed under the "Unused Scopes" section. We need to move it to the "Advanced Search" display group. Do this by clicking on that group name and enable it by clicking its check box.

You can now see that the Scope is in the right grouping.

The final step here is to enable the Scopes section of our Advanced Search page. The results are as follows:

Configure Search On MOSS 2007

The following procedures step you through the process of configuring Office SharePoint Server 2007 search services, creating a Web application for the SSP, creating the SSP, and configuring indexing settings.

Start and configure the Search service

1. On the SharePoint Central Administration home page, click the Operations tab on the top navigation bar.
2. On the Operations page, in Topology and Services, click Servers in farm.
3. On the Servers in Farm page, click the server on which you want to configure the search service.
4. Click Start next to Office SharePoint Server Search.
5. On the Office SharePoint Server Search Settings page, in the Query and Indexing section, make sure that the Use this server for indexing content and Use this server for serving search queries check boxes are selected.
6. In the Default Catalog Location section, type a path to a physical folder to store the index files, or use the default location that is specified.
7. In the Contact E-Mail Address section, specify a valid e-mail address.
8. In the Service Account section, click Configurable, and in User name and Password, type the user name and password for the user account under which you want the Search service to run. The user account must be a member of the Administrators group on the computer that is running the Search service. If you want to use the principle of least privilege and select a unique user account that does not have administrative rights on your front-end servers or on your back-end database servers, see the Known Issues/Readme for Office SharePoint Server 2007 Beta 2. The user name must be in the format DOMAIN\username.
9. In the Web Front End And Crawling section, do one of the following:
   • If you are configuring the search service on a server that provides Web services and renders Web content, click No dedicated Web front-end computer for crawling
   • If you are configuring the search service on a server that is a standalone search server that does not provide Web services and render Web content, click Use a dedicated web front end computer for crawling, and then, in Select a web front end computer, click the computer you want to use for crawling.
10. Click Start.

Start the Windows SharePoint Services Web Application service

You must start the Windows SharePoint Services Web Application service on every computer that you want to act as a Web server and was set up using the Complete option during Setup. This service is started by default on servers that were set up using the Web Front End option. To enhance security, you can leave this service turned off on application servers that do not provide Web content to client computers. Also, you do not need to turn this service on to use SharePoint Central Administration on a server.

1. On the SharePoint Central Administration home page, click the Operations tab on the top navigation bar.
2. On the Operations page, in Topology and Services, click Servers in farm.
3. On the Servers in Farm page, click the server on which you want to start the Windows SharePoint Services Web Application service.
4. Click Start next to Window SharePoint Services Web Application.

Create the Shared Services Provider

1. On the SharePoint Central Administration home page, click the Application Management tab on the top navigation bar.
2. On the Application Management page, in the Office SharePoint Server Shared Services section, click Create or configure this farm's shared services.
3. On the Manage this Farm's Shared Services page, click New SSP.  Important: If you have not created a Web application for the SSP administration site, you need to create one before you create the SSP. If you have already created a Web application for the SSP administration site, skip to step 14.
4. On the New Shared Services Provider page, click Create a new Web application.
5. On the Create New Web Application page, in the IIS Web Site section, click Create a new IIS web site, and do not modify the default settings in this section.
6. In the Security Configuration section, under Authentication provider, select the appropriate option for your environment, and do not modify the default settings in the remainder of this section.
7. In the Load Balanced URL section, do not modify the default settings.
8. In the Application Pool section, click Create new application pool.
9. In Application pool name, enter the name of your application pool or use the default name.
10. Click Configurable, and in User name and Password, type the user name and password for the user account under which you want the application pool to run. The user account does not have to be a member of any particular security group. It is recommended that you use the principle of least privilege and select a unique user account that does not have administrative rights on your front-end servers or on your back-end database servers. You can use the user account that you specified as the Office SharePoint Server 2007 service account; however, if that user account is a member of a security group that has administrative rights on your front-end servers or your back-end database servers, you will not be following the principle of least privilege. The user name must be in the format DOMAIN\username.
11. In the Database Name and Authentication section, verify the database information and make sure that Windows Authentication (recommended)is selected.
12. In the Search Server section, do not modify the default settings.
13. Click OK. Upon successful creation of the Web application, the New Shared Services Provider page appears.
14. In the SSP Name section, in Web Application, select the Web application that you created for the SSP, and do not modify any of the default settings in this section.
15. In the My Site Location section, do not modify any of the default settings.
16. In the SSP Service Credentials section, in User name and Password, type the user name and password for the user account under which you want the SSP to run. The user account does not have to be a member of any particular security group. It is recommended that you use the principle of least privilege and select a unique user account that does not have administrative rights on your front-end servers or on your back-end database servers. You can use the user account that you specified as the Office SharePoint Server 2007 service account; however, if that user account is a member of a security group that has administrative rights on your front-end servers or your back-end database servers, you will not be following the principle of least privilege. The user name must be in the format DOMAIN\username.
17. In the SSP Database section, you can either accept the default settings (recommended), or specify your own settings for the database server, the database name, or the SQL authentication credentials.
18. In the Search Database section, you can either accept the default settings (recommended), or specify your own settings for the search database server, the database name, or the SQL Server authentication credentials.
19. In the Index Server section, in Index Server, click the server on which you configured the Search service.  Note: If there is no index server listed in the Index Server section, then no server in your farm has been assigned the index server role. To assign the index server role to a server in your farm, follow the instructions in the "Configure the Search service" section earlier in this topic.
20. In the SSL for Web Services section, click No.
21. Click OK. Upon successful creation of the SSP, the Success page appears.
22. On the Success page, click OK to return to the Manage this Farm's Core Services page.

Configure indexing settings

1. On the SharePoint Central Administration home page, click the Application Management tab on the navigation bar.
2. On the Application Management page, in the Office SharePoint Server Shared Services section, click Create or configure this farm's shared services.
3. On the Manage this Farm's Shared Services page, click SharedServices1.
4. On the Shared Services Administration page, in Search, click Search Settings.
5. On the Configure Search Settings page, in the Crawl Settings section, click Default content access account.
6. In the Default content access account section, in Account, Password, and Confirm Password, type the user name and password for the user account that you want to use to crawl content on your sites. This account must be a domain user account. It is recommended that you use the principle of least privilege and select a unique user account that cannot modify content and does not have administrative rights on your front-end servers or on your back-end database servers. You can use the user account that you specified as the Office SharePoint Server 2007 service account; however, if that user account is a member of a security group that has administrative rights on your front-end servers or your back-end database servers, you will not be following the principle of least privilege. The user account that you specify will be added to the Web application Full Read policy for your farm. The user name must be in the format DOMAIN\username.
7. Click OK.
8. In the Crawl Settings section, click Content sources.
9. On the Manage Content Sources page, click Local Office SharePoint Server sites.
10. On the Edit Content Source page, in the Crawl Schedules section, under Full Crawl, click Create schedule.
11. In the Manage Schedules dialog box, configure schedule settings for full crawls of your content, and then click OK.
12. In the Crawl Schedules section, under Incremental Crawl, click Create schedule.
13. In the Manage Schedules dialog box, configure schedule settings for incremental crawls of your content, and then click OK.
14. In the Start Full Crawl section, select the Start full crawl of this content source check box, and then click OK.

You are done!

Include Web Parts in Custom Site Definition through ONET.xml

When you install Windows SharePoint Services 3.0, six Onet.xml files are placed within the setup directory, one in \Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\GLOBAL\XML that applies globally to the deployment, and five in different folders within ...\TEMPLATE\SiteTemplates that apply to each of the five site definitions that ship with Windows SharePoint Services 3.0. They are Blog sites, the central administration site, Wiki sites, Meeting Workspace sites, and team SharePoint sites.

The global Onet.xml file defines list templates for hidden lists, list base types, a default definition configuration, and modules that apply globally to the deployment. The five Onet.xml files in the \SiteTemplates directory define navigational areas, list templates, document templates, configurations, modules, components, and server e-mail footer sections used in the five site definitions.

Functions of Onet.xml

Depending on its particular use, an Onet.xml file can serve multiple functions, such as the following:

• Define the top and side navigation areas that appear on the home page and in list views for a site definition.
• Specify the list definitions that are used in each site definition and whether they are available for creating lists on the Create page.
• Specify document templates that are available in the site definition for creating document library lists on the New page, and specify the files used in the document templates.
• Define the base list types from which default Windows SharePoint Services lists are derived. (Only the global Onet.xml file serves this function.)
• Specify the configurations of lists and modules that are used within each site definition.
• Specify Windows SharePoint Services components.
• Define the footer section used in server e-mail.

Web Site Definition Tasks with Onet.xml

The following kinds of tasks can be performed in a custom Onet.xml to create a custom site definition:

• Specify an alternate cascading style sheet (CSS) file, JavaScript file, or ASPX header file for a site definition.
• Modify navigation areas for the home page and list pages.
• Add a list definition as an option to the Create page.
• Add a document template for creating document libraries.
• Define one or more configurations for the site definition, specifying the lists, modules, files, and Web Parts that are included when a site definition configuration is instantiated.

Include web parts in ONET.xml

We can include web parts in ONET.xml so that they are available on default page of the site when created with site template.

I am not going in detail about different sections of ONET file. Assuming you are aware of this. J . You can always get back to me on this.

First I’ll discuss about how to put a OOTB web part such as shared documents, Announcements, etc. on home page. Here I am discussion about how to put shared documents web part.

· You need to include feature ID of shared documents in ONET file in <Lists> section which will be activated upon creation of site collection and list will get created. You need not change feature ID of shared documents. You can check it from 12 hive\TEMPLATE\FEATURES\DocumentLibrary\Feature.xml.

· Put the following line under Lists section of configuration ID 0

· <List FeatureId="00BFEA71-E717-4E80-AA17-D0C71B360101" Type="101" Title="$Resources:core,shareddocuments_Title;" Url="$Resources:core,shareddocuments_Folder;" QuickLaunchUrl="$Resources:core,shareddocuments_Folder;/Forms/AllItems.aspx" />

· It should be as below.

<Configurations>

<Configuration ID="-1" Name="NewWeb" />

<Configuration ID="0" Name="Default">

<Lists>

<List FeatureId="00BFEA71-E717-4E80-AA17-D0C71B360101" Type="101" Title="$Resources:core,shareddocuments_Title;" Url="$Resources:core,shareddocuments_Folder;" QuickLaunchUrl="$Resources:core,shareddocuments_Folder;/Forms/AllItems.aspx" />

· Now put below line under Module. Here we can mention where the web part should be placed and the order.

· <View List="$Resources:core,shareddocuments_Folder;" BaseViewID="0"

WebPartZoneID="Left"

WebPartOrder="2" />

· It should be as below

<Modules>

<Module Name="Default" Url="" Path="">

<File Url="default.aspx" NavBarHome="True">

<View List="$Resources:core,shareddocuments_Folder;" BaseViewID="0"

WebPartZoneID="Left"

WebPartOrder="2" />

That’s it. Create site collection with custom site template. You should be able to see Shared Documents web part in Left zone on top.