Saturday, April 07, 2007

SharePoint Nested Tasks Architecture Draft

I was invited by Lawrence Liu from Microsoft to merge my project for nested sharepoint tasks into the community kit for sharepoint 3 he is working on. I agreed, but I will still be working on the feature seperatly with all the volunteers who contacted me so far (sorry guys - you don't get credit until you actually do something...).

So I had a fine Saturday writing the first draft for the architecture of the solution. Here is is, open for discussion. Sorry about the formatting, but publishing from word is never perfect.


  1. Table of Contents


1.    Table of Contents    2

2.    Table of Figures    2

3.    Project Details    3

3.2.    Purpose    3

3.3.    Project Description – What are "Nested Tasks"    3

3.4.    Why SharePoint?    3

4.    Specifications    4

4.2.    The Built-In SharePoint Tasks List    4

4.3.    Nested Tasks Requirements    4

4.4.    Out of Scope    5

5.    High Level Design    6

5.2.    Solution Architectural Concept    6

5.3.    Components    7

5.3.1.    Customized list definition    7

5.3.2.    Sub Tasks Hierarchy Web Part    7

5.3.3.    An event handler or workflow (pending research)    8

5.3.4.    A SharePoint Feature Definition for Deployment    8



  1. Table of Figures

Figure 1 The built-in SharePoint task item    4

Figure 2 Sample user interface for creating sub tasks from an item's actions drop-down menu    6

Figure 3 Sample user interface to add sub tasks from the item's edit menu    6

Figure 4 Sample sub tasks hierarchy web part user interface    7

Figure 5 Sample user interface for showing the task tree for the current task    8




  1. Project Details

    1. Purpose

    The purpose of this document is to outline the specifications for the SharePoint Nested Tasks project, and supply a breakdown of the project to tasks for developers.

    1. Project Description – What are "Nested Tasks"

    SharePoint Nested Tasks is meant to provide SharePoint users with the ability to create sub tasks in a (potential infinite) hierarchy.

    Currently, tasks in both SharePoint and Outlook do not support sub tasks that branch from a parent, and the need for this tracking of a hierarchy of tasks is apparent.

    For example, a decision maker may assign a task to a team leader, who will in turn assign sub tasks to people in his team. The team leader wants to see the status of the sub tasks aggregated into the view of the task that is assigned to him, and he also wants to make changes to the parent task that will affect the entire tree of tasks.

    1. Why SharePoint?

    Windows SharePoint Services version 3 is a web collaboration tool that supports collaboration throughout the organization, allowing users to quickly create solutions for collaboration using custom lists and easy to define workflows. Since it includes built-in support for item level security (each task's security can be set separately), and allows easy customization of lists, views and environments it is the perfect platform to develop a collaborative solution such as this.


  1. Specifications

    1. The Built-In SharePoint Tasks List

    Windows SharePoint Services 3 comes with a built-in definition for a task list, which allows users to specify data such as Title, Priority, Status, % Completed, Assigned to, Start and Due dates.

    Figure 1 The built-in SharePoint task item

    This structure can then be customized in each site to rename the fields, add additional ones or remove unwanted ones.

    The built-in tasks list also comes with a feature that sends email to the assignee of each task to notify them about the task when it is created.

    This however is not a complete standard tasks workflow to remind the assignee about the task as its due date draws near. It is not part of the scope of this project to answer this need, but we acknowledge the need and if possible to include such a workflow as part of the solution, it may get added.

    1. Nested Tasks Requirements

    In addition to the default tasks functionality in SharePoint are as follows:

  • Each task may have multiple sub tasks.
  • A sub task may not have a due date beyond the due date of its parent, nor have a start date before the start date of its parent.
  • A task cannot be marked as complete before all its children are marked as complete.
  • If a task is deleted, all its children will be deleted as well.
  • It will be possible to assign sub tasks to users with no access (permissions) to the parent task.
  • The user will have a view allowing him to see his tasks in a hierarchical manner, while maintaining security through the hierarchy (if the user is not allowed to see a task, he should not be shown that task).
  • The user will have an easy and intuitive way to create sub tasks, from the parent task.
  • The solution should be built in a manner that will allow administrators to choose if it will replace the built-in tasks functionality on the server, or will allow choosing to activate the solution in a site to live side by side with the built-in tasks list.
  • None of the modifications should break default SharePoint functionality such as list customization, workflows, event handlers, backup, recycle bin and security.
  1. Out of Scope

This iteration will not deal with:

  1. Recycle bin restore for a task with its sub tasks
  2. Roll back of a task with its sub tasks to history versions
  3. Customized email notifications beyond the built-in ones.


  1. High Level Design

    1. Solution Architectural Concept

    A customized list definition will be created to include a field called "Parent Task" that will be a lookup into the same list. This will allow specifying a parent for each task, with root tasks having no parent.

    The field will be hidden from the user in the "Edit Task Form" and "New Task Form", so as not to let users create sub tasks without the customized user interface. This is mainly to avoid confusion, since a task list may contain numerous items, some of them with the same title, and it would be hard for the user to manually pick the parent.

    This means that the only way to create a sub task is to start from the parent. User interface will be developed to allow doing so.

    Figure 2 Sample user interface for creating sub tasks from an item's actions drop-down menu

    Figure 3 Sample user interface to add sub tasks from the item's edit menu

    1. Components

    The solution will be broken into the following components:

    1. Customized list definition

      This list definition will inherit from the built-in tasks list definition, but will include some modifications:

      1. A "Parent Task" lookup field that will look into the same list, into the "title" field.
      2. An embedded web part in the "New", "Edit" and "Display" forms (see hierarchy web part for more details)
      3. A customized view to display the tasks as a hierarchy using the hierarchy web part component.


    2. Sub Tasks Hierarchy Web Part

      This web part will be the user interface to display the tasks list as a hierarchy of tasks and sub tasks.

      The web part should employ techniques such as AJAX to show the user the root tasks and their children without loading the entire list when the page is loaded, in order to avoid slowing down the page.

      The web part must be security-sensitive, showing the user only the tasks he is allowed to see.

      The web part will also allow the site manager to specify which fields it will display, and will have a button to create a new root task, as well as an option for creating sub tasks from an existing task.

      Figure 4 Sample sub tasks hierarchy web part user interface

      The web part will also support a task-centric view, starting from the current task that the user is currently viewing. This is to give the user easy access from the current task to the children tree.

      Figure 5 Sample user interface for showing the task tree for the current task

      Finally, this web part, since it will be embedded in the "New Task Form", will also be in charge of setting the parent task in the hidden "parent task" field.

      Another option for this web part (optional for this iteration) is to provide the user with a button to set status for all tasks in the hierarchy at once. This is to allow a user to close all tasks from one place.

    3. An event handler or workflow (pending research)

      This component will ensure the following:

      1. Prevent the user from creating or modifying sub tasks to have due date later than the parent's due date.
      2. Prevents the user from creating or modifying sub tasks to have start date before the one for the parent.
      3. If a task's changes its due date or start date, makes sure its children values correspond to those values (if the task has a child with a due date that is after the new value, change the due date on the child to be equal to the new due date value of the parent. The same goes for start dates)
      4. Prevent the user from marking the status of a task as complete before all its children are complete.
    4. A SharePoint Feature Definition for Deployment

      The feature will include the list definition, as well as the definitions linking the tasks list definition with the workflow\event handler. Tests should be made to determine and document the best way to replace the built-in SharePoint "TaskList" feature with the Nested Tasks List feature.

No comments: