Fixing the Lookup fields in List Definition Schema

[Update 24/04/07]
I tried Donal's solution and it didn't work for me. Did it work for anyone else?.
Also, I should mention that this is for WSS3 (2007)

[Update 14/04/07]
A commenter by the name of Donal McWeeney updates me that it is possible to refer to other lists by using the relative path in the "List" attribute in the schema. That will make most of the code below unnessecary - which is good. but will not solve the List="Self" problem (when we want the lookup to look into the list we are creating), because we want the user to be able to create many lists with different relative paths. So my code is still useful, but please read the comment by Donal before starting. If his method solves your problem you should use it!
[End Update 14/04/07]

Here is the first output out of the nested tasks project - a solution for the challange of createing list definitions with lookups.

The Problem
If you want to create a feature that will deploy two (or more) lists, with a lookup field connecting them, you are in trouble.
The schema for defining a lookup field requires you to put the ID (Guid) for the list you are referancing. This is a problem since you don't know the ID - this is randomly generated when the list is created.

The Solution

1. Define the lookup list as you would:
   
   <Field Type="Lookup" DisplayName="Parent Task" Required="FALSE" List="Self" ShowField="Title" UnlimitedLengthInDocumentLibrary="FALSE" ID="{94f89715-e097-4e8b-ba79-ea02aa8b7abc}" SourceID="http://schemas.microsoft.com/sharepoint/v3" StaticName="ParentTask" Name="ParentTask" ColName="int3" RowOrdinal="0" />
   
2. Install my "LookupFixer" web control. Here is the Source code (I will create this as a download as part of the Nested Tasks project when I can):
   using System;
   using System.Collections;
   using System.Collections.Generic;
   using System.Xml;
   using System.Text;
   using System.Web;
   using System.Web.UI.WebControls;
   using System.Xml.Serialization;
   using Microsoft.SharePoint;
   using Microsoft.SharePoint.WebControls;
   
   
   
   namespace SharePointTips.SharePoint.WebControls
   {
       public class LookupFixer : WebControl
       {
           private string lookupFieldName = "";        
           public string LookupFieldName
           {
               get
               {
                   return lookupFieldName;
               }
               set
               {
                   lookupFieldName = value;
               }
           }
           private string targetListName = "";
           public string TargetListName
           {
               get
               {
                   return targetListName;
               }
               set
               {
                   targetListName = value;
               }
           }
           
           protected override void OnLoad(EventArgs e)
           {
               SPList currentList = SPContext.Current.List;
               FixLookUps(currentList);
               base.OnLoad(e);
           }
           public void FixLookUps(SPList list)
           {
               string fieldName = this.LookupFieldName;
               
               if (list.Fields.ContainsField(fieldName))
               {
                   list.ParentWeb.AllowUnsafeUpdates=true;                
                   SPFieldLookup field = (SPFieldLookup)list.Fields[fieldName];
                   SPList targetList = GetTargetList();
                   //check if the field link to the list is broken. 
                   if (field.SourceId != targetList.ID.ToString())
                   {
                       //create the new lookup field from the old field
                       string newFieldXml = field.SchemaXml;
                       string title = field.Title;
                       list.Fields.Delete(field.InternalName);
                       list.Update();
                       
                       //put the ID of the current list as the source for the lookup
                       newFieldXml = newFieldXml.Replace("http://schemas.microsoft.com/sharepoint/v3", targetList.ID.ToString());
                       newFieldXml = newFieldXml.Replace("Self", targetList.ID.ToString());
                       //change the ID of the field to create it as a unique new field.
                       newFieldXml = newFieldXml.Replace(field.Id.ToString(), System.Guid.NewGuid().ToString());
                       //TODO - check if the old field was in the default view, and set it in the optionns
                       string newFieldID = list.Fields.AddFieldAsXml(newFieldXml);
                       list.Update();
                       
                       
                   }
               }
           }
           private SPList GetTargetList()
           {
               if (TargetListName.Length == 0)
                   TargetListName = SPContext.Current.List.Title;
               return SPContext.Current.Web.Lists[TargetListName];
           }
       }
   }
   
3. Modify the "AllItems.aspx" to include this control in the following format:
   
   <%@ Register Tagprefix="SharePointTips" Namespace="SharePointTips.SharePoint.WebControls" Assembly="LookupFixer, Version=1.0.0.0, Culture=neutral, PublicKeyToken=074b83dc3e6008ae" %>
   
   <SharePointTips:LookupFixer ID="LookupFixer1" runat="server" TargetListName="Announcements"  LookupFieldName="Parent Task" />
   

What did we just do?
The web control has two properties that allow you to configure the lookup. TargetListName can remain empty if you want the lookup to be to the same list (self referencing list) - like we want it to work in nested tasks, and LookupFieldName is the name of the lookup field that we are trying to create and is broken.
The control, since it is embedded in the "AllItems.aspx" view, will get triggered when the list is created from the list definition, because the AllItems.aspx is the default view.
(*If you change the default view in the schema, make sure you also embedd the control in that aspx file*)
The code in the control reads the properties, loads the list, loads the field, gets the field settings from the schema, and then - because it is impossible to change the broken field - we delete the field, and create a new one from the schema.

The only thing missing here is changing the code to also add the new field to the views that the old field was part of. I didn't have time to look into that yet.

Note!
This is an ugly workaround that works. If anyone has a better solution - please let me know!

SharePoint Nested Tasks Project is published

What does this mean? That you can go to codeplex and view the source code as it changes (there is nothing there but skeletons right now) and most importantly - read the specs as a word document, add to the wish list or just give any kind of feedback in the discussion forum.

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.

SharePoint Nested Tasks Team Needs Beta Testers & Tech Writers

First thing first - Thanks to Coskun Cavusoglu (check out his sharepoint blog) we now have a logo (still needs to be adjusted to 100px height as per codeplex requirements).

I had so many people contact me about this, and I am really excited to start working with all of them, but I will only have time on Saturday to start the project, so please be patient if you emailed me and I didn't reply.
What we really could use is future beta testers and technical writers to do the documentation. The technical writers should be involved from the start (that's now) and have to have excelent english and writing skills to produce our administrator and user guides. The beta testers will be assigned the task of finding our bugs before we release the final version.
Again, if you think you can help, let me know (my email - FirstNameLastName@gmail.com)
Ishai Sagi