which country user step here?

Tag Cloud

MOSS (47) SharePoint 2007 (37) SharePoint 2013 (31) SharePoint 2010 (23) MOSS admin (17) PowerShell (17) admin (17) developer (16) List (15) WSS (14) sql query (14) MOSS SP2 (13) end user (11) scripting (11) wss V3 (11) permission (10) sql (9) Moss issue (8) search (8) database (7) RBS (6) Service Pack (6) reportadmin (6) workflow (6) CU (5) Excel (5) Patch (5) client object model (5) Client Code (4) Command (4) Cumulative Updates (4) IIS (4) SharePoint 2019 (4) SharePoint designer (4) office 365 (4) stsadm (4) user porfile (4) ASP.NET (3) Content Database (3) Groove (3) Host Named Site Collections (HNSC) (3) SharePoint 2016 (3) Tutorial (3) alert (3) authentication (3) batch file (3) codeplex (3) domain (3) error (3) incomming email (3) issue (3) restore (3) upload (3) Caching (2) DocAve 6 (2) Folder (2) Index (2) Internet (2) My Site Cleanup Job (2) My Sites (2) News (2) People Picker (2) Share Document (2) SharePoint admin (2) View (2) Web Development with ASP.NET (2) add user (2) audit (2) coding (2) column (2) deploy solution (2) download (2) enumsites (2) exam (2) export (2) june CU (2) load balance (2) mySites (2) network (2) orphan site (2) performance (2) profile (2) project server (2) query (2) security (2) server admin (2) theme (2) timer job (2) training (2) web master (2) web.config (2) wsp (2) 70-346 (1) 70-630 (1) AAM (1) Anonymous (1) Approval (1) AvePoint (1) Cerificate (1) Consultants (1) Content Deployment (1) Content Type (1) DOS (1) Document Library (1) Drive Sapce (1) Excel Services (1) Export to Excel (1) Feature (1) GAC (1) Get-SPContentDatabase (1) Get-WmiObject (1) HTML calculated column (1) ISA2006 (1) IT Knowledge (1) ITIL (1) Install (1) Link (1) MCTS (1) Macro (1) Masking (1) Migration (1) NLBS (1) Nintex (1) Office (1) Open with Explorer (1) ROIScan.vbs (1) Reporting Services (1) SPDisposeCheck.exe (1) SQL Instance name (1) SSRS (1) Sandbox (1) SharePoint Online (1) SharePoint farm (1) Shared Services Administration (1) Site Collection Owner (1) Site template (1) Skype for business (1) Steelhead (1) Teams (1) URLSCAN (1) VLOOKUP (1) WSS SP2 (1) XCOPY (1) abnormal incident (1) admi (1) app (1) application pool (1) aspx (1) availabilty (1) backup (1) binding (1) blob (1) branding sharepoint (1) cache (1) calendar (1) change password (1) connection (1) copy file (1) counter (1) crawl (1) custom list (1) domain security group (1) event (1) excel 2013 (1) facebook (1) filter (1) fun (1) group (1) iis log (1) import (1) import list (1) improment (1) interview (1) keberos (1) licensing (1) log in (1) metada (1) migrate (1) mossrap (1) notepad++ (1) onedrive for business (1) operation (1) owa (1) process (1) publishing feature (1) resource (1) send email (1) size (1) sps2003 (1) sql201 (1) sql2012 (1) sub sites (1) system (1) table (1) task list (1) today date (1) trial (1) vbs (1) video (1) web part (1) web server (1) widget (1) windows 2008 (1) windows 2012 R2 (1) windows Azura (1) windows account (1) windows2012 (1) wmi (1)

Thursday, February 24, 2011

sub sites owner with Full Control unable to add Content Editor Web Part

after so many year at sharepoint , just notice web part also have permission setting.

 

below is the detail from the forum.

 

 

http://www.tek-tips.com/viewthread.cfm?qid=1444650&page=3

 

Background: SharePoint V3 on a hosted server. The user is a "site owner" and "site owners" have "full control" over the site.  "full control" has all the options that can be selected for security.  This is a sub-site to the main SharePoint site and it does not inhearit security from the parent site.  I want site owners to have full control over there individual sites, but not have control over other's sites.  
Problem: When the user goes to add a web part to the "Home" page of the site via selecting "Site Actions" - "Edit Page" the only web parts that are available to them are the "Lists and Libraries" web parts that consist of "Announcements", "Calendar", "Links", "Shared Documents", "Tasks", and "Team Discussion".
When a Site Collection Administrator does the same thing as above, they see all the web parts listed above as well as "Miscellaneous" web parts consisting of "Content Editor Web Part", "Form Web Part", "Image Web Part", "Page Viewer Web Part", "Relevant Documents", "Site Users", "User Tasks", and "XML Web Part".  Is it possible to make these web parts accessible to the owners of sub-sites with out giving them full control over the entire SharePoint site hierarchy?

 

 

I believe I figured out a solution.  So, if your curious, here is how I fixed it.
Logged into the top level SharePoint site as a site collection administrator.
Select "Site Actions" - "Site Settings"
In the "Galleries" Colum, select "Web Parts"
With the Web Part Gallery open, select the "Settings" menu and select "Gallery Settings"
Now you should be in the Customize Web Part Gallery window.  In the "Permissions and Management" column, select "Permissions for this gallery".
In the "Permissions: Web Part Gallery" Select "Actions" - "Edit Permissions"
Select "OK" to the pop up that is displayed warning you that you are about to create unique permissions, and now you can select "New" and add additional users to the Gallery.
This will allow whomever you add to see all the Web Parts available.

Monday, February 21, 2011

Command line method to create large files

wohoo… finally get to this lost time command forget in my mine.~~

 

sometime need to have huge file to upload to SharePoint for testing or network testing or do what ever test need to have huge file.

 

simple command below for you to generate the large dump files!!

 

 

You can easily create dummy file of specific size which do not contain any datausing Fsutil command.

fsutil file createnew <name of file> <size in bytes>

Following is example to create dummy file of 10MB size in ‘temp’ folder of E drive.

 

fsutil file createnew e:temptempfile.txt 10000000

Wednesday, February 16, 2011

Introduction to workflows

Microsoft Office SharePoint Designer 2007 another article from Microsoft

 

Across your enterprise, teams use Microsoft SharePoint sites to collaborate on documents and share information. You want to build a SharePoint application that improves team productivity and efficiency, but you don’t want to write code. Where do you start?

With Microsoft Office SharePoint Designer 2007, you can design workflows that add no-code application logic to your SharePoint sites and applications. Using the Workflow Designer, you create rules that associate conditions and actions with items in SharePoint lists and libraries. Changes to items in lists or libraries trigger actions in the workflow.

For example, suppose that a team's primary responsibilities are writing, revising, and approving contracts. These contracts are stored in document libraries on the team site. With Office SharePoint Designer 2007, you can create a workflow that sends a notification e-mail message to the reviewer when a new contract has been uploaded to the site. At the same time, the workflow creates a task in the Tasks list for the reviewer. When that person reviews the contract and marks the task as complete, different actions are triggered depending on whether the contract is assigned a status of Approved or Rejected.

Team efficiency and productivity improve because the workflow drives the process so that the team can focus on doing the work, rather than on managing the workflow. And no programming is required to build such a solution. By creating rules in the Workflow Designer, you can quickly add interactivity to a SharePoint solution or application.

This article introduces the basics of workflows. When you understand the basic building blocks of a workflow — events, actions, conditions, and steps — you can quickly add application logic to your SharePoint applications.

IMPORTANT   To create a workflow, your SharePoint site must be located on a server running Windows SharePoint Services 3.0.

In this article

What is a workflow?

Your team uses a SharePoint site to collaborate and store valuable business information in SharePoint lists and libraries. With Office SharePoint Designer 2007 , you can now attach application logic to documents or items in these lists and libraries.

With the Workflow Designer, you can attach a sequence of conditions and actions to a list or library — this sequence is a workflow. A workflow is a natural way to organize and run a series of actions that correspond to a work process. This process can control almost any aspect of a list item in Windows SharePoint Services 3.0, including the life cycle of that item. The workflow can include both actions performed by people (or workflow participants) and actions performed by the workflow. Workflow participants can interact with the workflow through the Tasks list, where a workflow can create a task for someone and remain paused until the task is marked complete.

Workflows can be as simple or as complex as your business processes require. You can create a workflow that the user initiates, or a workflow that is initiated automatically based on an event, such as when a list item is created or changed.

In general, when you use Office SharePoint Designer 2007 to design a workflow, you follow these basic steps:

  • Use the Workflow Designer to choose and assemble the conditions and actions that define the steps of the workflow.
  • Have Office SharePoint Designer 2007 automatically generate any ASP.NET forms for workflow initiation or any custom SharePoint task, if necessary.
  • Customize the workflow forms, if necessary.

You can think of a workflow as a flowchart of actions with a beginning, an end, and a sequential flow from start to finish. Workflows can incorporate parallel branches, but ultimately they progress from the initial action to the final action.

For example, suppose you were to chart the workflow described earlier that routes a document in Windows SharePoint Services 3.0 for approval. When the workflow starts, it automatically notifies the specified reviewer by e-mail that they have a document to review. The reviewer then reviews the document, and changes the status of the document to indicate that they have completed their task, and whether they have approved or rejected the document. Based on the reviewer response, the workflow proceeds down one of two parallel branches. If the reviewer approves the document, the workflow moves the approved document to a specific document library, and then sends an e-mail message to the entire team notifying them of the approved document. If the reviewer rejects the document, the workflow notifies the document author of this. In either case, the workflow then reaches its end and the process is completed.

Workflow process flow chart

Top of Page TOP OF PAGE

What are events, actions, conditions and steps?

These are the building blocks of a workflow. A workflow consists of one or more steps, and each step consists of actions and any associated conditions. Each workflow is initiated by an event.

WHAT ARE EVENTS?

An event is what starts or initiates a workflow. There are exactly three events that can start a workflow:

  • An item is created.
  • An item is changed.
  • A workflow participant clicks a start button on the SharePoint site.

It is important to understand that a workflow created with Office SharePoint Designer 2007 is always attached to exactly one list or library in a SharePoint site. When you design a workflow, you choose which list to attach it to. An event in this list starts the workflow.

You can create a workflow that a participant starts manually, or a workflow that is started automatically when a list item is created or changed. For example, in the document approval workflow, you want to design the workflow so that it starts automatically whenever someone adds a document to the Shared Documents library. On the File menu, point to New, and then click Workflow. In the Workflow Designer, you see the following page.

Define workflow - document approval

When a workflow participant starts a workflow manually, that person first browses to the list or library that the workflow is attached to. Any person with at least the Contribute permission level can initiate a workflow that is designed to start manually. The participant clicks an item, clicks Workflows on the menu, and then chooses a workflow from a page that displays all workflows associated with that item. The participant fills out a workflow initiation form, if necessary, and then initiates the workflow by clicking the start button on the form. Initiating a workflow creates a new instance of that workflow for that specific item.

Workflow command on list item

NOTE   The Workflows command is available only when the item is in a list or library that has at least one workflow attached to it.

For a workflow that is started manually, the initiation form can be as simple as the following.

Example of workflow start button on list item

You can also add custom fields to an initiation form when you design the workflow. Workflow participants can then provide information to the workflow by filling out this form, and those settings are passed to the workflow. A new workflow instance starts, and that workflow can then look up and use the information provided through the form at any point in the workflow.

WHAT ARE ACTIONS?

An action is the most basic unit of work in a workflow. Office SharePoint Designer 2007 provides a set of ready-made, reusable actions for you to incorporate into your workflow. For example, your workflow can:

  • Create, copy, change, or delete list items (including documents).
  • Check items in or out.
  • Send an e-mail message.
  • Create a task for someone on the Tasks list of your team site.
  • Collect data from a participant that can be referenced later in the workflow.
  • Pause or stop the workflow.
  • Log workflow information to a History list to use for repudiation or workflow debugging.
  • Set workflow variables or perform calculations.

A workflow can contain any number of actions. The actions just listed are performed by the workflow, but other actions might be performed by workflow participants. For example, the document approval workflow is comprised of five actions. Four of these actions are performed automatically by the workflow, but one of these actions — actually reviewing the document — is done by a workflow participant. Actions done by a workflow participant are represented by tasks assigned to that person in the Tasks list. The five actions in the example workflow are:

  • Send an e-mail message to notify the reviewer
  • Review the document (a task assigned to a workflow participant)
  • Move the document to the Approved document library
  • Send an e-mail message to notify the team
  • Send an e-mail message to notify the document author

In the most basic sense, when you design a workflow, you identify the necessary sequence of actions, and then you assemble that sequence of actions by using the Workflow Designer. For example, in the document approval workflow, the first action that you want is to send an e-mail message to notify the reviewer.

Flowchart, send e-mail to reviewer

So in the Workflow Designer, you choose that action for the first step in the workflow.

Actions list

WHAT ARE CONDITIONS?

When you design a workflow, you can use the Workflow Designer to create rules that apply conditional logic to SharePoint lists and items. A rule establishes a condition where the workflow performs the associated action only if that condition is true. For example, you can create a rule where the workflow sends a reviewer an e-mail message only if an item is created by a specific person. You can also add clauses to a condition. For example, you can create a rule where a reviewer is sent an e-mail message only if an item is both (1) created by a specific person and (2) the document title contains specific keywords. Finally, you can associate multiple actions with one condition. For example, you can create a rule where if an item is created by a specific person, then (1) the reviewer is sent an e-mail and (2) workflow information is logged to the History list.

Choose conditions and actions

To sum up, a rule is a condition associated with one or more actions: If all clauses in the condition are true, do all the associated actions.

In the previous example, the user specified only one condition. However, you can create multiple conditions for a step in the workflow. Multiple conditions create branches in the workflow: If condition A is true, do one action; if condition B is true, do a different action. To add a branch to a step, click Add 'Else If' Conditional Branch. For example, in the document approval workflow, if the reviewer approves a document, the workflow performs one action (or series of actions); if the reviewer rejects a document, the same workflow performs a different action. This is a conditional branch.

Flowchart example, approver reviews document

In the Workflow Designer, this step has two branches and looks like the following. The green diamond indicates that the step has a conditional branch.

Conditional branch with two conditions

You can also create a branch that has no specific condition. This way, the workflow performs one action if a condition is true and a different action if the condition is false. For example, the following step in a workflow sends a message to the team only if the condition is true; else, the workflow sends a message just to the document author. By adding a branch with no specific conditions, the workflow performs the action in that branch in any case where the condition in the first branch is false.

Conditional branch with no second condition

NOTE   Branching in a workflow cannot extend from one step to another. A set of 'Else If' branches is always contained in a single step.

Office SharePoint Designer 2007 provides several ready-made, reusable conditions for you to incorporate into your workflow. For example, you can specify that the workflow performs the associated actions only if an item:

  • Is created or modified in a specific time span.
  • Is created or modified by a specific person.
  • Has a title field that contains specified keywords.
  • Is a file of a specific type or has a file size in a specific range. (This condition is available only when the workflow is attached to a document library.)

In addition, you can create custom conditions and advanced conditions where you can specify a wide range of parameters. With custom conditions, you can compare a field in the current list with a value. For example, you can create a custom condition where if the Approval Status field equals Approved, do the associated action. With advanced conditions, you can compare one value to another value. This allows you to create a comparison between a field in any list and a value from another list. For example, you can create an advanced condition for the Shared Documents library where if the value of the Status field in the Tasks list equals Pending, do the associated action.

NOTE   An action does not require a condition. For example, the first step of the example document approval workflow sends an e-mail to notify the reviewer. This action does not have a condition associated with it.

PARALLEL VS. SERIAL ACTIONS

When you have more than one action associated with a condition, the actions can be set up to run at the same time (parallel) or one after another (serial).

Run actions in parallel or serial

Serial actions    For example, in the document approval workflow, you can set up two actions so that when a document is approved, a message is sent and then (afterward) the document is copied to the Approved document library. In the Workflow Designer, then indicates that the second action occurs after the first.

Serial action with 'then'

Parallel actions    For example, in the document approval workflow, you can set up two actions so that when a document is approved, a message is sent and (at the same time) the document is copied to the Approved document library. In the Workflow Designer, and indicates that the second action occurs at the same time as the first.

NOTE   Parallel actions are not absolutely simultaneous; the exact order cannot be specified and may vary each time the workflow runs.

Parallel action with 'and'

NOTES

  • In any given rule (conditions and actions), all actions must be either serial or parallel.
  • A set of serial or parallel actions must be contained within a single step.
WHAT ARE STEPS?

A workflow is comprised of one or more steps. Each step can contain any number of actions and associated conditions. You can think of steps simply as pages in the Workflow Designer. For example, the document approval workflow has two steps, as shown in the Workflow Designer.

Workflow steps, add a step

Steps allow you to group conditions and actions so that one set of rules (conditions and actions) can be evaluated and performed before a second set.

One step or many? Some workflows can be designed either as a sequence of actions within one step, or as a sequence of steps.

For example, the following three actions could be Step 1 of a basic one-step workflow.

Multiple actions in one step

The same three actions could be separated into several steps.

Multiple actions in many steps

How you structure your workflow into steps depends on what you want each step to accomplish. The rules in one step are processed to conclusion before going on to the next step, so you want to group in the same step any rules necessary to effect the specific action or actions that you want.

More specifically, each step can hold one set of 'Else If' conditional branches, where the actions in each branch are performed only when the associated condition is satisfied. In this case, additional steps are needed only when:

  • Multiple sets of 'Else If' conditional branches need to be evaluated.
  • You need to separate a branched statement from a non-branched statement.

You can also use steps simply as a way to organize your workflow. For example, a workflow might have many actions in a step that doesn't use conditions. In this case, you might want to separate the actions into steps just to better organize them.

Top of Page TOP OF PAGE

What are workflow forms?

To make your workflow more dynamic and flexible, you can add a form to the workflow. With a form, you can collect information from workflow participants at predefined times in the workflow, and make it possible for participants to interact with the tasks for that workflow.

With Office SharePoint Designer 2007, you can create two types of workflow forms:

  • An initiation form gathers information from the workflow participant when they start the workflow. Initiation forms are displayed to users when they manually start a workflow on a given SharePoint item. With an initiation form, users can specify additional parameters or information about the workflow as it applies to the given SharePoint item. For example, you might use an initiation form to ask who should review a document and by when the review should be completed. Not all workflows need initiation forms. If you do need one, Office SharePoint Designer 2007 automatically generates an ASP.NET initiation form according to your initiation specifications.
  • A custom task form allows workflow participants to interact with tasks in the Tasks list on a SharePoint site. With the Custom Task Wizard, you can easily create custom form fields and add them to a custom task form. When you finish designing the workflow, Office SharePoint Designer 2007 automatically generates the ASP.NET forms for your custom tasks. Then, when the workflow runs and tasks are created, the user browses to the Tasks list on the SharePoint site, marks the task as completed, and enters any optional or required information specific to the workflow. The workflow can then respond to those changes as specified in the workflow, or look up and evaluate that information in later steps of the workflow.

After Office SharePoint Designer 2007 automatically generates the ASP.NET forms, you can customize them. Workflow forms are ASP.NET pages with a Data Form Web Part and a master page applied to it. These .aspx files are stored on the SharePoint site with the workflow source files. You can open and customize these forms as you would any other .aspx file.

Top of Page TOP OF PAGE

Where are workflows stored?

Workflows are stored in a site-level document library called Workflows. This document library is created automatically by Office SharePoint Designer 2007. In the Folder List, the Workflows document library displays the workflow icon instead of the usual list or document library icon. By default, the Workflows document library is hidden from the browser and has no List Views, such as AllItems.aspx or EditForm.aspx. This document library contains a folder for each workflow created with Office SharePoint Designer 2007. The folder contains all the source files necessary for the workflow, including:

  • The workflow markup (.xoml) file (needed only when the workflow uses conditions).
  • The workflow rules file.
  • The workflow configuration file.
  • Any .aspx forms needed, such as initiation forms (for workflows that are started manually) or custom task forms.

To modify an existing workflow, you can either click Open Workflow on the Filemenu or double-click the .xoml file in the Folder List. This opens the workflow to its first step in the Workflow Designer. If you click Back to view the initiation settings of the workflow, you see that you cannot change which list or library the workflow is attached to. After a workflow is attached to a list or library by using Office SharePoint Designer 2007, this association cannot be changed.

Workflows in folder list

The Workflow Designer provides an action called Log to History List. You might use this action when you want to keep a record of the workflow history for investigating errors or for tracking and repudiation purposes. When you create a workflow that uses the action Log to History List, Office SharePoint Designer 2007 automatically creates a list called Workflow History. This list has columns for such information as user ID, date, event, and error description. Like the Workflows document library, by default the History list is hidden from the browser but can be seen in the Folder List.

Workflow history in folder list

The Workflow Designer provides three actions that interact with the Tasks list: Assign a To-Do Item, Collect Data from a User, and Assign a Group Survey. When you create a workflow that uses any of these three actions, Office SharePoint Designer 2007 automatically creates the .aspx form, the content type for the task, and the Tasks list, if necessary. By default, the Tasks list can be viewed in the browser, unlike the Workflows document library and Workflow History list.

Tasks list in folder list

Top of Page TOP OF PAGE

Where can I check the status of a workflow?

You can easily view the progress of workflows on a selected item through the browser. The All Items view of a list or document library displays the current status of workflows running on an item. In addition, each item has a Workflows page where you can view the following information:

  • All workflows currently running on that item.
  • All workflows that have run on the item in the past.
  • All the available workflows for that item.

Workflows page for an item

To view the Workflows page for an item, click the item in the list, and then clickWorkflows on the menu.

NOTE   The Workflows command is available only when the item is in a list or library that has at least one workflow attached to it.

When a user starts a workflow on an item, Windows SharePoint Services 3.0 adds a new column to that item. By default, the column name matches the name of the workflow. This read-only column displays the current status of the item within that workflow. This status column is added automatically for each workflow the first time it is run.

Columns display workflow status

In each column, the workflow status is a link. When you click In Progress, for example, you see the Workflow Status page for that instance of the workflow.

Workflow status page

A workflow created in Office SharePoint Designer 2007 cannot be deployed to multiple lists. It is only valid for the list for which it was created. However, multiple workflows can be attached to one list and may be available for a given item. Multiple workflows can run simultaneously on the same list item, but only one instance of a specific workflow can run on a specific item at any given time. For example, you might have two workflows, Workflow A and Workflow B, available for a specific list. Although both workflows can run simultaneously on a specific item in the list, you cannot have two instances of Workflow A or Workflow B running on the same item at the same time.

Introduction to customizing pages by using Web Parts

WSS list is so useful for business user, can do something simple system by the simple list and filter :D. i am start thinking should i be business personnel rather then SharePoint engineer? ha ha ha , ok, just keep tract this article from Microsoft , i am sure one day i will consult user to user this :D

 

 

This article is intended for Web page owners and administrators. It provides an overview of Web Parts and Web Part Pages and explains how you can customize a page by adding, changing, or deleting Web Parts.

Overview of Web Parts and Web Part Pages

A Web Part is a modular unit of information that forms the basic building block of a Web Part Page. You can add Web Parts to Web Part zones in a Web Part Page and then customize the individual Web Parts to create a unique page for your site users.

The following example uses the Image Web Part to describe the basic features of a Web Part.


Sample Image Web Part

Callout 1 The Web Part title bar contains the heading for the Web Part.

Callout 2 The Web Part menu contains functions that enable you to minimize or close the Web Part, edit the Web Part, or get Help for a specific Web Part. When the page is in edit mode, you can also use this menu to delete the Web Part or connect it to other Web Parts, depending on the type of Web Part that you are using.

Callout 3 The body of the Web Part contains the content that you specified for the type of Web Part that is being used. In this example, the Web Part is an Image Web Part, which displays an image.


A Web Part Page is a special type of Web page in which you can use Web Parts to consolidate data, such as lists and charts, and Web content, such as text and images, into a dynamic information portal that is built around a common task or special interest.

Your site home page is one example of a Web Part Page. When you create a new site or workspace site, you are creating a Web Part Page. You can also create a Web Part Page by selecting one of the available site templates, or you can use a Web design program that is compatible with Microsoft Windows SharePoint Services, such as Microsoft Office SharePoint Designer 2007, to create a Web Part Page from scratch.

You can use a Web Part Page to present a variety of structured and unstructured information in an organized, useful, and convenient way. Web Part Pages often contain several Web Parts that are connected so that you can dynamically display data and content to see the results that you want.

For example, you can create a Web Part Page called Customer Orders that you frequently use to display critical information. You get a call from a customer who has a question about an order, does not remember the order ID number, but does remember the date when the order was placed. You can use a Web Part Page to do the following.


Customer Orders Web Part Page with several Web Parts

Callout 1 Look up an order by order ID number or, in this case, the order date.

Callout 2 Display all orders by date.

Callout 3 Select the correct order, based on the customer's name, and look up the order details as well as the customer details.

Callout 4 Select a line item in the order (in this case, the lamp), and display a product picture to confirm the customer's question.

Callout 5 Scan for late-breaking business news that is pertinent to the customer's order.


WEB PART PROPERTIES

Each Web Part shares a set of common properties (also called base class properties) that are organized into sections in the tool pane and that control the Web Part's appearance (such as the title, height, and width), layout (such as the Web Part order in the zone and the direction of the content), and advanced characteristics (such as the image icon and description).

Many Web Parts also have custom properties that are unique to the Web Part. These are usually displayed either above or below the common Web Part properties in the tool pane. For example, the Image Web Part has additional custom properties, including the image link, its horizontal and vertical alignment, and background color.

NOTE   Depending on how the Web Part was created, a Web Part custom property may be displayed in a default Miscellaneous section below the common properties in the tool pane.

WEB PART VIEWS

You can customize a Web Part in one of two views:

  • Shared view    You can add a Web Part to a Web Part Page and then edit the Web Part Page in a shared view. Shared Web Parts are available to all users of a Web Part Page who have the appropriate permission.
  • Personal view    You can add a shared Web Part to your own personal view and then edit your view of the Web Part. The changes that you make to a Web Part while you are in a personal view are available only to you. Other users who did not make changes in a personal view continue to see the shared view of the Web Part.

The view of the Web Part that you are working with can be important because:

  • You may have permission to edit only some Web Parts on certain Web Part Pages but not on other Web Part Pages.
  • You may be able to connect to certain Web Parts on a Web Part Page but not to other Web Parts on the same Web Part Page.
WEB PARTS AND WEB PART CONNECTIONS

An additional feature of Web Parts is the ability to easily connect them by passing data between them and synchronizing their behavior. By connecting Web Parts, you can manage data in dynamic and interesting ways. In many products and technologies, the task of connecting sets of data from different data sources is not easy and often requires programming skill. But with Web Parts, making data connections is as simple as using menu commands. By connecting Web Parts, you can, for example, present data from two Web Parts in alternate views, perform related calculations between two Web Parts, and filter a Web Part by using values from another Web Part — all on one Web Part Page.

WEB PART ZONES AND THEIR PROPERTIES

Web Part zones are containers of Web Parts that are used to group and organize Web Parts on a Web Part Page. Web Part zones also have a set of properties that serve a dual purpose. You can use one subset of properties to organize the layout and format of Web Parts on the Web Part Page. You can use another subset of properties to provide an additional level of protection from modification (or "lock down") of the Web Parts within the zone.

The Web Part zone properties each have default settings or behaviors. As you add Web Parts to the Web Part Page, some of these property values are automatically set. These property values are not designed to be edited in the browser, but you can edit them by using a Web design program that is compatible with Windows SharePoint Services, such as Office SharePoint Designer 2007.

For more information about Web Part zone properties, see the Windows SharePoint Services 3.0 SDK, which is available from the Windows SharePoint Services Developer Center on MSDN.

Top of Page TOP OF PAGE

Types of Web Parts

Windows SharePoint Services provides several Web Parts that are ready to use with your site. You can use these built-in Web Parts, customize them to suit your needs, or create new Web Parts and upload them for use throughout your site.

DEFAULT WEB PARTS

The following Web Parts are included by default in any site and can be customized to suit the needs of your team. Many of these Web Parts can also be connected to each other to create a variety of unique solutions:

  • Content Editor Web Part    You can use the Content Editor Web Part to add formatted text, tables, hyperlinks, and images to a Web Part Page.
  • Form Web Part    You can use the Form Web Part to connect to and filter a column of data in another Web Part. Both Web Parts must run on the same server.
  • Image Web Part    You can use the Image Web Part to add a picture or graphic to a Web Part Page. To more easily coordinate the image with other Web Parts on the page, you can control the vertical alignment, horizontal alignment, and background color of the image inside the Image Web Part by editing its custom properties in a shared view.
  • List View Web Part    You can use the List View Web Part to display and edit list or library data on your site and to connect to other Web Parts, including other List View Web Parts. Lists are information that you share with team members and often display in tabular format. List views display this information in different ways for different purposes, such as filtering, sorting, or selecting specific columns.

NOTE   There is no Web Part called List View. When you create a list on your site, a List View Web Part is automatically created and named after the list. For example, if you create a list called Boats, a Web Part called Boats will be available in the Site Name gallery. The Web Part automatically displays the data contained in the list that you created.

  • Page Viewer Web Part    You can use the Page Viewer Web Part to display a Web page, file, or folder on a Web Part Page. You enter a hyperlink, file path, or folder name to link to the content.
  • Site Users Web Part    You can use the Site Users Web Part to display a list of users and groups who have permission to use a site. The Site Users Web Part automatically appears on the home page of a Document Workspace site. You can also add the Site Users Web Part to any Web Part Page.

NOTE   In sites that are running on Microsoft Windows SharePoint Services 2.0 and earlier, the Site Users Web Part was called the Members Web Part.

  • XML Web Part    You can use the XML Web Part to display Extensible Markup Language (XML) and apply Extensible Stylesheet Language Transformations (XSLT) to the XML before the content is displayed. For example, you might have an XML file that contains a list of boats, prices, and links to images of the boats. You can use the XSLT to transform the data to display a list of boats and prices and make the boat name a hyperlink to display the image in a separate window.
PRECONFIGURED LIST VIEW WEB PARTS

The following Web Parts are built into the Windows SharePoint Services team site template and are automatically configured and ready to use on a Web Part Page when you create a new team site. Different combinations of these Web Parts are included when you create a team site or workspace site, depending on which site template you select.

NOTE   These Web Parts are derived from the List View Web Part and use preconfigured Web Part templates to create their unique layout and design. To add data to these lists, on the Quick Launch, click View All Site Content, and then clickLists. On the All Site Content page, click the name of the list for which you want to add data.

  • Announcements    Use the Announcements Web Part to post news, status, and other short bits of information that you want to share with team members.
  • Calendar    Use the Calendar Web Part to display upcoming events or team schedules.
  • Links    Use the Links Web Part to post hyperlinks to Web pages that interest your team.
  • Shared Documents    Use the Shared Documents Web Part to share files from the default document library with site users.
  • Tasks    Use the Tasks Web Part to assign a task to a member of your team, specify its due date and priority, and indicate its status and progress.
  • Team Discussion    Use the Team Discussion Web Part to provide a forum for talking about topics that interest your team.
CUSTOM WEB PARTS

By using a programming environment that is compatible with Windows SharePoint Services, such as Microsoft Visual Studio, developers can exploit the full feature set of Microsoft ASP.NET to create custom Web Parts. A Web Part Page is an ASP.NET file (.aspx), and Web Parts are derived from Web Form Controls. To further enhance Web Part Pages, developers can create their own Web Parts that provide new functionality. Developers can also add custom properties to the Web Parts, add custom builders in the tool pane for specialized user interfaces, and connect to other Web Parts by using Web Part connections. For more information about creating and deploying Web Parts, see the Windows SharePoint Services 3.0 SDK, which is available from the Windows SharePoint Services Developer Center on MSDN.

You can also use Web Parts that other people or companies have created. You must have appropriate permissions to add a third-party Web Part to your Web Part Page or site. Some Web Parts may need to be deployed directly to the server. If you are unable to add a third-party Web Part to your Web Part Page or site, contact your administrator for assistance.

Top of Page TOP OF PAGE

Ways to use Web Parts and Web Part Pages

You can use Web Part Pages in the following ways:

  • Consolidate data from different data sources.
  • Report and summarize critical data.
  • Analyze and aggregate data (for example, sums, totals, or counts).
  • Summarize key information that you want to see at the beginning of each day.
  • Prioritize and highlight project or customer data to help you make effective decisions.
  • Display an up-to-date work schedule and meeting information to quickly plan your day.
  • Get quick access to business news, local weather, and your favorite Web sites to focus your Web browsing.
WAYS TO CREATE AND CUSTOMIZE A WEB PART PAGE

There are several ways to create and customize a Web Part Page:

  • The New Web Part Page form    The most common way to create a Web Part Page is through the New Web Part Page form. On the Site Actionsmenu Site Actions menu, click Create, and then click Web Part Page to open the New Web Part Page form. After using this form to create a page, you can begin designing the page right away in the browser. When you want to browse through the page, just close the tool pane.
  • A Web design program    By using a Web design program that is compatible with Windows SharePoint Services, such as Microsoft Office SharePoint Designer 2007, you can make advanced customizations to a Web Part Page, including the following:
    • Customize the theme of a Web Part Page that uses the site theme by default.
    • Edit a Web Part Page template or create a new one.
    • Customize the page layout.
    • Edit zone properties.
    • Add HTML code or Web controls.
    • Change the way Web Parts are ordered inside a zone.
    • Add Web Parts outside a zone, or add a Web Part to a Web page that is not a Web Part Page.
    • Create connections between Web Parts on different Web Part Pages.
    • Publish a Web Part Page to a Web site that is running Windows SharePoint Services.
    • Customize the Form Web Part and use the Data View Web Part.

Top of Page TOP OF PAGE

Web browser support for Web Part Pages

Web browser support for Web Part Pages can be categorized into two levels:

  • Level 1 support is the highest level of visual and functional support. Browsers that provide level 1 support include recent versions of Microsoft Internet Explorer for Microsoft Windows.
  • At level 2 support, a few visual and functional features are not available to some browsers, and some other features are compromised and behave differently from the way they behave in level 1 browsers. However, the majority of features are still available to users. Browsers that provide level 2 support include Firefox 1.5 and later for Windows and Netscape Navigator 8.0 and later for Windows. Level 2 browsers are not supported for Windows SharePoint Services 3.0 Central Administration.

NOTE   Level 2 browsers do not support the creation of connections between Web Parts.