Posts tonen met het label Sharepoint. Alle posts tonen
Posts tonen met het label Sharepoint. Alle posts tonen

ForwardLinks, Variations & user rights

Recently Tom, a colleague of mine, experienced some odd behavior using the ForwardLinks property of an SPListItem. We wanted to extend the out-of-the-box publishing features with some extra functionality using the forward links property, but ended up parsing rich text fields ourselves because of the non-expected behavior.

First of all, the ForwardLinks property should "Get a collection of hyperlinks that are associated with the item; for example, the hyperlinks in a URL Field or rich text field". So when we create a publishing page that contains links to some documents, the ForwardLinks property should be updated to contain these links. In the following scenario's we found that this is not the case.

Scenario 1

  • You create a page in /enu (variation source), with a link Link1 in the Rich Text field
  • You publish the page in /enu
  • The timer service propagates the page to the variations, creating a draft in all the target variations
  • ForwardLinks of all target variations correctly report the link Link1.
  • You publish the page in the target variations
  • You add another link Link2 in /enu
  • When querying the ForwardLinks as the app-pool acc, this link does not show up (the red marked I. in the schema)
  • You publish the page in /enu and wait for the propagation service
  • ForwardLinks is properly updated in /enu
  • ForwardLinks is not updated in the variation targets when querying as a sitecoll admin
  • ForwardLinks is updated when querying as app-pool acc
  • You check out the page in the target variations
  • You edit the rich text field in the target variations
  • You check in the page in the target variations
  • You publish the page in the target variations
  • ForwardLinks is properly updated in the target variations

Scenario 2

This is actually a variation on scenario 1, only this time we don't modify the variation source, only the variation targets

  • You create a page in /enu (variation source), with a link Link1 in the Rich Text field
  • You publish the page in /enu
  • The timer service propagates the page to the variations, creating a draft in all the target variations
  • ForwardLinks of all target variations correctly report the link Link1.
  • You publish the page in a variation target
  • While logged in as the site-admin, you edit a variation target and you add a new link Link2.
  • You check this variation target in as a new minor version
  • In this case, ForwardLinks queried as the site-admin returns the proper links. However, querying it as an app-pool account results in the wrong links (also see the red marked III. in the schema)
  • While logged in as the site-admin, publish the variation target
  • ForwardLinks returns the correct links for both site-admin as app-pool acc

In this case, querying ForwardLinks as the app-pool account returns the exact opposite of what was originally said: it returns the value of the latest published version instead of the latest draft version.

Scenario 3

Almost identical to scenario 2.

  • Execute step 1-5 of scenario2.
  • This time, log in as a user who's a member of the Designers group (not a sitecoll-admin). Edit a variation target and add a link Link2 in the rich-text field.
  • While logged in as a Designer user, do a check-in of the page (minor version)
  • When querying ForwardLinks as the sitecoll-admin or as app-pool, you only get a reference to Link1. Only when querying the property as the Designer-account, you get a proper reference to Link1 and Link2
  • Log back in as the sitecoll-admin and publish the page in the variation target-site
  • ForwardLinks property properly lists Link1 and Link2 for every user.

Conclusion

Querying ForwardLinks as the application-pool account does not always return the values of the latest draft version.

Furthermore, it looks like the values are totally random. Is there some documentation that describes the logic behind this property: in which case will it return a draft-version's links, in which case will it resort to the published version?

Fyi, we tried the following solutions to get the draft version... but they didn't work, since everyone of them conflicted with at least 1 scenario:

  • Query the ForwardLinks as the same user who's specified in ModifiedBy. this conflicts with our findings in scenario1, mark II. (the red rectangle)

If we're in a variation source, query ForwardLinks as the current-user, otherwise use the app-pool acc. this conflicts with scenario2, mark III and scenario3, mark IV

Nintex Workflow vs. Visio 2010

With the new Visio workflow creation tool in the Office clients a lot of questions popped to our minds about the need of a custom workflow creation tool as Nintex offers:

The promise is that with the new office clients you'll be able to create new workflows. This would be a fantastic extension for end-users to create their own workflows...however...there's a small catch:
The Visio toolkit will just be extended with SharePoint workflow tasks, so you'll be able to design a workflow, but not to configure it. After you have drawn your workflow design and validated it, you can import the XOML into SharePoint Designer and start doing the actual configuration and deployment.

So will there be a need for clients to have a third party workflow tool? As far as we know now, yes.
First of all having these workflow tools in your browser window is quite a nice feature. No clients needed.
Secondly the deployment is all browser-based, nice and easy. Whereas with the foreseen Visio extensions it would still require multiple client-side steps.

The new Visio extensions look promising, but Nintex still offers a lot of functionalities that I don't see happening with the new workflow support in Visio.

Mike Fitzmaurice (Vice President of Nintex) opened a blog on this topic to answer to some rumours.
If you want to learn about the Visio workflow design capabilities, there is a very good post by Wictor Wilén.

To be continued...

Creating custom listitem menu’s (ECB)

This week I was working on a custom packaging solution for Look And Feel. A colleague of mine needed to add menu items to the List Item menu's of the Style library, the masterpage library and the site collection images. Our first thought was to use CustomActions in a feature to implement this, but soon we found some problems:

Register only on the specified libraries

First of all it is impossible to define a custom action only for the lists that we needed. The RegistrationID property of the CustomAction element gives some form of control, but not as specific as we needed. For more info on Custom Actions see the following articles:

Rights parameter insufficient

Secondly we needed to only show the menu when a user was part of a certain group. CustomActions allow you to specify the rights the user must have in order to see a certain menu-item. Again this was of no value to us because there were several groups with the same rights, but we only wanted the menu-items for a certain group.

ControlAssembly not allowed on Listitem ECB

Our last attempt was to write a custom control that renders the menu-item. If we were able to create a server-side control that could check whether we were on the right list and find out about the user roles…we were off to go…but after some reading we found out that the ControlAssembly option is not available for listitem menu's (see Jan Tielen's blog) since the menu is rendered entirely by javascript.

Solution

I started looking at the core.js (/_layouts/1033/core.js) which contains the menu code and found the functions & mechanisms to create menu items. If you click on a menu-item the menu is rendered by the CreateMenuEx function. This function basically calls several other functions which are all responsible for a subset of menu-items. One of these functions is AddDocLibMenuItems (m,ctx). The AddDocLibMenuItems function takes two parameters. The first parameter, called m, represents the menu object itself; the second parameter, ctx, provides HTTP context information about the web request. I didn't want to edit the core.js file since it is a system file, so I came up with the following solution:

//Store reference to original function
var original_AddDocLibMenuItems = AddDocLibMenuItems;

//Override the original function
AddDocLibMenuItems = function(m,ctx) {
 strDisplayText="Test";
 strAction="alert('ok')";
 strImagePath="";
  
 CAMOpt(m, strDisplayText, strAction, strImagePath);
 CAMSep(m);
  
 //Call the original function
 original_AddDocLibMenuItems(m,ctx);
}

The code is inserted on the listview form pages of the Style library, the masterpage library and the site collection images using a content editor webpart. What it does is override the AddDocLibMenuItems function and assign the original function to a variable. This is necessary to be able to call the original function once we injected our own code. Using this mechanism there is no need to make changes to the core.js file!

Adding a menu item to the menu requires just one function call:

CAMOpt(m, strDisplayText, strAction, strImagePath);

The CAMOpt function takes four parameters: the menu object to add the new item to, the display text of the menu item, the javascript action to perform when the item is clicked and a path to an image file to associate with the item. A call to the CAMSep function adds the separator bar to the menu. Both these functions are defined in the menu.js file on the SharePoint server.

Now if you know all about the wonderful SPAPI libraries to use the SharePoint webservices in javascript, then you know you might implement whatever you want and create advanced menuitems. My complete solution:

<script type="text/javascript" src="/_layouts/js/jquery-1.3.2.min.js"></script>
<script type="text/javascript" src="/_layouts/js/SPAPI_Core.js"></script>
<script type="text/javascript" src="/_layouts/js/SPAPI_Lists.js"></script>
<script type="text/javascript" src="/_layouts/js/SPAPI_UserGroup.js"></script>
<script type="text/javascript" src="/_layouts/js/SPAPI_UserProfile.js"></script>

<script type="text/javascript">
$(document).ready(function () {
 var userName = getCurrentUserName();
   if (userName != null){
        var accountName = getAccountName(userName);
        if(accountName != null) {
          if(isMemberOfGroup(accountName,"Blog - Test site Members")) {
    showLink();
   }
        }
      
     }   
});



//Helper functions
function showLink() {
 //Store reference to original function
 var original_AddDocLibMenuItems = AddDocLibMenuItems;

 //Override the original function
 AddDocLibMenuItems = function(m,ctx) {
    strDisplayText="Test";
    strAction="alert('ok')";
    strImagePath="";
  
    CAMOpt(m, strDisplayText, strAction, strImagePath);
    CAMSep(m);
  
    //Call the original function
    original_AddDocLibMenuItems(m,ctx);
 }
}

function isMemberOfGroup(accountName,groupName) {
   var usergroup = new SPAPI_UserGroup('http://moss/sites/blog');
        var items = usergroup.getGroupCollectionFromUser(accountName);
    
        if(items.status == 200)
 {
  if($(items.responseXML).find("Group[Name='" + groupName + "']").size() > 0)
  {
   return true;
  } 
  else 
  {
   return false;
  }
        } else {
  return false;
 }
        
}

function getAccountName(userName)
{
     var profile = new SPAPI_UserProfile('http://moss/sites/blog')
     var p = profile.getUserProfileByName(userName);

     if (p.status == 200)
     {
         var properties = p.responseXML.getElementsByTagName('PropertyData');
        var propertyValues = new Array();

        for (var i=0; i < properties.length; i++)
        {
          var propName = properties[i].getElementsByTagName('Name')[0].childNodes[0].nodeValue;
          propertyValues[propName] = properties[i].getElementsByTagName('Value');
        }
        return propertyValues['AccountName'][0].childNodes[0].nodeValue;
  
     }
     else
     {
         return null;
     }
}


function getCurrentUserName()
{
    var lists = new SPAPI_Lists('http://moss/sites/blog')
    var items = lists.getListItems(
    'User Information List',
    '',
    '<Query><Where><Eq><FieldRef Name="ID"/><Value Type="Counter">' + _spUserId + '</Value></Eq></Where></Query>',  // query
    '<ViewFields><FieldRef Name="Name"/></ViewFields>',
    1,  // rowLimit
    ''  // queryOptions
    );
    
    if (items.status == 200)
    {
        var rows = items.responseXML.getElementsByTagName('z:row');
        if (rows.length == 1)
        {
            return rows[0].getAttribute('ows_Name');
        }
        else
        {
            return null;
        }
    }
    else
    {
        return null;
    }
} 
</script>

To create an easy deployable solution you might want to opt to insert this code through a delegate control and just perform some additional checks on the location. I know this is not the most beautiful solution, but based on the design of these menus I can't think of a better way to implement this. Of course, all suggestions are more than welcome!

Cascading fields solution using jQuery – PART 1

Many of my clients require cascading fields in SharePoint lists. The most common solution to this problem is creating a custom field that implements the desired functionality. In this series however, I will try to create the cascading fields using a combination of the out-of-the-box SharePoint fields, the jQuery library, SPAPI and SharePoint webservices. In this first part we'll create the supporting lists and add some functionality that allows easy input for the end-user. In part 2 I'll go deeper into creating the cascading field.

1. Requirements

Suppose our end-user wants to have the following features:

  1. See all cities that are related to a certain country on the display form of the country
  2. Have a link to insert cities for a certain country

The picture shows how our solution could look like. Notice the column Cities in the Display form of a Country. This additional column is inserted through our solution. It lists all cities that are related to the current country. At the bottom of the list you find a link that allows the user to add additional cities for the current country. The link takes you to the New form of the cities list. The lookup field in that list should already point to the country.

2. Lists

For this tutorial we create two custom lists: 'Countries' and 'Cities'. The Country list only has one field of type single text named Country.

The Cities list contains two fields:

  • City- single line of text
  • Country - lookup field to Country list

3. Libraries

Since this tutorial is all about the usage of jQuery in combination with out-of-the-box SharePoint we'll make live a little easier and use some excellent libraries that exist for the tasks that we need to perform.

AJAX calls to SharePoint webservices:

The list of related cities will be retrieved by an AJAX call to the SharePoint web services. Writing the SOAP envelop is somewhat of a tedious task so we'll use the great javascript library written by Darren Johnstone that simplifies the code to connect to the SharePoint webservices. More information can be found here.

Populate fields on forms using jQuery:

Not so long ago I discovered a great library (reading another excellent blog post of the Paul Grenier ' jQuery for everyone' series) that makes your SharePoint forms look at the querystring and automatically populate the corresponding fields. This is just what we need to automatically fill in the lookup field that points to the country. The library itself can be found on Codeplex.

4. Preparing the environment

First we need to add the jQuery library to our SharePoint pages (see Jan Tielen's blog if you don't know how) to be able to write some powerful javascript. I usually go for the delegate control variant because it allows to insert jQuery for a complete site by activating a feature. To include the other three libraries where needed, we'll put a Content Editor webpart on the forms page. Since you cannot edit the SharePoint forms pages in the browser, you need to apply a little trick: Open the form (for example the EditForm.aspx of the cities list) and append to the querystring PageView=Shared&ToolPaneView=2 (more info can be found here). You'll be able to add a Content Editor webpart and add a link to the desired library as follows:

<script type="text/javascript" src="_layouts/js/SPAPI_Lists.js"></script>

For now just leave as is, once we setup the solution I will link the correct libraries at the correct places.

5. Creating the solution

Adding the Cities to the DisplayForm

To add the list of cities to the displayform of a country open the DisplayForm for one country and add the PageView=Shared&ToolPaneView=2 to the querystring. This should allow you to add a content editor webpart on the form. Inside the content editor webpart we need to link to the SPAPI libraries (SPAPI_Core.js & SPAPI_Lists.js) to do the AJAX calls. I placed these libraries into the Layouts folder of the 12 hive so we insert the following links:

<script type="text/javascript" src="http://moss/sites/blog/_layouts/js/SPAPI_Lists.js"></script>
<script type="text/javascript" src="http://moss/sites/blog/_layouts/js/SPAPI_Core.js"></script>

Since jQuery is available we're going to use this library to add an additional row to form. The HTML code for this row should be something like this:

<tr>
 <td class='ms-formlabel' nowrap='true' valign='top'>
  <h3 class='ms-standardheader'>Cities</h3>
 </td>
 <td id='SPFieldText' class='ms-formbody' valign='top'> 
  [List of Related Cities]
  [Link to New City form]
 </td>
</tr>

So to add it to the table we insert the following code:

$(".ms-formtable tbody").append("<tr><td class='ms-formlabel' nowrap='true' valign='top'><h3 class='ms-standardheader'>Cities</h3></td><td id='SPFieldText' class='ms-formbody' valign='top'> <ul id='citiesUl'></ul><a href=''>Add new city</a></td></tr>");

Now to find the cities and place them in this row, we first need to find the ID of the current Item to query the cities list. The ID is in the querystring so I insert the following code to read out that value and store it in a variable:

function getUrlParam(name){  
 name = name.replace(/[\[]/,"\\\[").replace(/[\]]/,"\\\]");  
 var regexS = "[\\?&]"+name+"=([^&#]*)";  
 var regex = new RegExp( regexS );  
 var results = regex.exec( window.location.href );  
 if( results == null )    
  return "";  
 else 
  return results[1];
}

var id = getUrlParam("ID");

Now we can create a CAML query to find all cities that are related to the current country:

<Query>
 <Where>
  <Eq>
   <FieldRef Name="Country" LookupId="true"/>
   <Value Type="Lookup">[ID]</Value>
  </Eq>
 </Where>
</Query>

Great, all that is left to do is write an AJAX call to the _vti_bin/Lists.asmx webservice and display those items in the form. The SPAPI library allows to query lists with the following code (more examples can be found here):

var lists = new SPAPI_Lists('http://moss/sites/blog');
var items = lists.getListItems(
 'Cities',   // listName
 '',         // viewname
 '<Query><Where><Eq><FieldRef Name="Country" LookupId="true"/><Value Type="Lookup">' + id + '</Value></Eq></Where></Query>',  // query
 '<ViewFields><FieldRef Name="Title"/></ViewFields>',  // viewFields
 100,    // rowLimit
 '<QueryOptions><IncludeMandatoryColumns>FALSE</IncludeMandatoryColumns></QueryOptions>'  // queryOptions
);
  
if (items.status == 200) {
 // do something with the response
}
else {
 alert('There was an error: ' + items.statusText);
}

Now we add some processing of the XML to the code (don't you love jQuery!) and combine all together to:

<script type="text/javascript" src="http://moss/sites/blog/_layouts/js/SPAPI_Lists.js"></script>
<script type="text/javascript" src="http://moss/sites/blog/_layouts/js/SPAPI_Core.js"></script>


<script type="text/javascript">
 function getUrlParam(name){  
  name = name.replace(/[\[]/,"\\\[").replace(/[\]]/,"\\\]");  
  var regexS = "[\\?&]"+name+"=([^&#]*)";  
  var regex = new RegExp( regexS );  
  var results = regex.exec( window.location.href );  
  if( results == null )    
   return "";  
  else 
   return results[1];
 }
 
 $(function() {
  var id = getUrlParam("ID");
  var lists = new SPAPI_Lists('http://moss/sites/blog');
  var items = lists.getListItems(
   'Cities',   // listName
   '',         // viewname
   '<Query><Where><Eq><FieldRef Name="Country" LookupId="true"/><Value Type="Lookup">' + id + '</Value></Eq></Where></Query>',  // query
   '<ViewFields><FieldRef Name="Title"/></ViewFields>',  // viewFields
   5,    // rowLimit
   '<QueryOptions><IncludeMandatoryColumns>FALSE</IncludeMandatoryColumns></QueryOptions>'  // queryOptions
  );

  
  if (items.status == 200) {
   var cities ='';
   $(items.responseXML).find("z\\:row").each(function() {
    var liHtml = "<li>" + $(this).attr("ows_Title") + "</li>";
    cities += liHtml;
    //$(cities).append(liHtml);
   });
   $(".ms-formtable tbody").append("<tr><td class='ms-formlabel' nowrap='true' valign='top'><h3 class='ms-standardheader'>Cities</h3></td><td id='SPFieldText' class='ms-formbody' valign='top'> <ul id='citiesUl'>" + cities + "</ul><a href=''>Add new city</a></td></tr>");  
  }
  else {
   alert('There was an error: ' + items.statusText);
  }
 });
</script>

Creating a prepopulated field

Let's start out by creating a link to the new item form of the cities list that includes a value to prepopulate a field on the form. Since we are using the SPFF library the querystring just needs to be extended with [fieldname]=[value]. In this case the fieldname is 'Country' and the value is the ID of the current country. We already have the ID of the current country in a variable so all we have to do is create a link. Replace the link in the previous code by the following:

<a href='../Cities/NewForm.aspx?Country=" + id + "&Source=" + escape(window.location.href) + "'>Add new city</a>

So it becomes:

$(".ms-formtable tbody").append("<tr><td class='ms-formlabel' nowrap='true' valign='top'><h3 class='ms-standardheader'>Cities</h3></td><td id='SPFieldText' class='ms-formbody' valign='top'> <ul id='citiesUl'>" + cities + "</ul><a href='../Cities/NewForm.aspx?Country=" + id + "&Source=" + escape(window.location.href) + "'>Add new city</a></td></tr>");

The code for the content editor webpart on the display form of the Countries list is complete. Save it and watch the magic happen!

The last part of the solution is to include the SPFF library on the new item form of the cities list and activate the querystring processing (examples can be found here). Again, open the new form and add PageView=Shared&ToolPaneView=2 to the querystring. Add a Content Editor webpart and add the following code:

<script type="text/javascript" src="_layouts/js/spff.js"></script>

<script type="text/javascript">
 $(function(){
 $.spff({lock:true});
 });

</script> 

If everything went ok, you can now test this connection. Clicking on the link to add a city should prepopulate the lookup field:

In the next part we'll look at how the 2 lists can be used to create cascading fields. Stay tuned!

SharePoint WCM pages on mobile devices

An ever present possible requirement is for Web Content pages to be accessible via mobile device. SharePoint introduces some nice features for mobile devices. Each library & list can be configured to allow a mobile view. This way your mobile device can access those lists easilly.
Secondly you can use the variation system to create a variation for a mobile view. Creating a master page designed specifically for mobile devices can make your WCM pages available. A nice overview of the possibilities is given by Jamie McAllister.
But what when you need to create a mobile view for a variated site? Furthermore, based on the experience I've got with variations I'm not that eager to start creating variations. This made me think about an other approach to mobile views.
Based on an article about changing the masterpage for application pages using a HttpModule we constructed the following solutioin.
  1. Extend your WCM application to an other url, specifically for use with mobile devices e.g. mobile.company.com
  2. Create your mobile masterpage/CSS/... and store it in the original site collection
  3. Create an HttpModule that replaces the default masterpage with your new mobile masterpage (make sure to read this post about Publishing Pages!)
  4. Register the HttpModule in your web.config.
  5. Grab your device and see the magic happening!
On codeplex there is a project that provides an HttpModule that can be configured in the web.config file. It might be usefull to take a look at that before writing your own HttpModule.

SQL Server - SharePoint Configuration Wizard

Wizards are nice as long as nothing goes wrong. Behind the scene the carry out a lot of work and all you have to do is click on a button, wait...and pray to every God of every world religion that all goes well! Because if it doesn't....that's where the hair pulling starts!
Last week I got a call from a collegue of mine to take a look at a service pack installation problem on a MOSS 2007 server. All installations were carried out successfully, but when the configuration wizard kicked in, they received an error about a connection failure using Named instances. Because we disabled named instances & only allowed connections using TCP we were supprised by the error message.
Digging deeper into the system gave some insight into how SQL Server 2005 works and what causes the error:
In the early days SQL Server only allowed one instance per server which listened to port 1433 for incomming connections. As SQL Server 2000 introduced support for multiple instances a new service (SSRP) needed to provide a way of determining which instance needed to be connected to. This service was later replaced by SQL Server Browser service. Essentially this listener service responds to client requests with the names of the installed instances, and the ports or named pipes used by the instance.
When the SharePoint Configuration Wizard kicks in, it requests information from the SQL Server Browser service about the instance to connect to. A failure contacting the listener will result in the "connection failure using named instances". Even though you disabled named instances and only allow TCP connections.
In our case the Service was running, but due to a SQL Server 2000 also running on the server it somehow got mashed up. Removing the old SQL Server 2000 instances & restarting the service solved the problem.
Lessons to be learned:
  • Make sure the SQL Server Browser service is up and running on the SQL Server
  • Make sure that no firewall is blocking the SQL Server communication (open up 1433 for TCP & 1434 for UDP)
If you do not want to open port 1434 or don't want to start the SQL Server Browser Service you can still run the configuration wizard by using the command line. This way you can provide all parameters manually to connect to the instance directly.
Psconfig –cmd configdb –create –server "dbserver\instance,1433" –database SharePoint_Config –user adomain\username –password ***** –admincontentdatabase SharePoint_Admin
More information on SQL Server Browser Service: http://msdn.microsoft.com/en-us/library/ms181087.aspx

Site Template - Category

Many times site templates are a good solution to store out-of-the-box customisations. These templates can be retrieved under the 'Custom' tab during the site creation process.

You can however create your own custom tabs, be it with a little workaround: after some searching I found out that the site definition on which the site template is based, apparantly defines the name of tab! Here is how you do it...

1. Create a custom site definition to define the category. You can for example copy the Publishing template.

2. In the webtemp file of you site definition provide the FilterCategories parameter on the Configuration tag. Assign it the string you want to appear on the tab:

< Template Name="CUSTOMSITE" ID="1001" >
< Configuration ID="0" Title="Custom Web Site" Hidden="FALSE"
ImageUrl="/_layouts/images/stsprev.png" Description="Customized site definition for My Team Site"
DisplayCategory="My Site Definitions" FilterCategories="My Custom Site Templates" >
< /Configuration >
< /Template >

3. Install your custom site definition

4. Create a site based on you site definition and customize it.

5. Save your site as template

Your site template will be available on the site creation page under the tab 'My custom site templates'.

A site template is in fact a cab-file with a manifest.xml file in it. In this xml file the site definition ID is stored. Based on this ID the FilterCategories parameter of the site definition is retrieved.

Lookup Fields

Another post on relational data in SharePoint.

The lookup field turns out to be one hell of a powerfull tool! Suppose you want to relate two different list items or documents. For this purpose you need to use the lookup field.
This field internally stores the ID of the related item, but in the drop-down it displays whatever field you want. However, in your CAML queries you can use both values!

To query the display-value, your CAML would look like this:
<Query>
   <Where>
     <Contains>
       <FieldRef Name="Event" />
         <Value Type="Lookup">Cronos</Value>
     </Contains>
   </Where>
</Query>


To perform a query on the ID you just need to specify LookupId='true' in the FieldRef tag:

<Query>
   <Where>
     <Eq>
       <FieldRef Name="Event" LookupId="true"/>
         <Value Type="Lookup">7</Value>
     </Eq>
   </Where>
</Query>

Relational Data in SharePoint

Recently I needed to develop a simple subscription system in a WSS 3.0 environment. My client wanted to have a simple event list on which employees could register (with approval).

One of the fantastic 40 application templates addresses this topic, but as I started thinking about it...I wanted to try to make use of the new possibilities of wss 3.0 concerning multiple content types in a custom list. As it turns out my efforts took me quite far!

Let's start by briefly listing the functional requirements:

  1. There needs to be a table/list to store all events. Several different event types exist: internal or external, workshop or course.
  2. Users can register for internal events, an approval workflow is needed.
The obvious choice would be to use a lookup field on the subscription list to link the 2 lists. However, this would mean we have to write some eventhandlers on the first list to ensure that when an event is deleted, the related subscriptions also get deleted. Why not try to reduce the coding by using a different approach.

Since wss 3.0 it is possible to use multiple content types on one list. So all event types can be joined into one list. To ensure that no event handlers need to be written, we'll need to combine the registration and the event list into one custom list. Again this poses no problem: folders can be used to define a relation between an event and a registration.

So the final idea would be to create some content types for the events that inherit from the folder content type. The registrations for each event are stored in a different content type inside the folder of the event.

We end up with a flexible system! As a event gets deleted, all registrations within the folder are deleted. And no coding needed!

Now we only need to define some views, an approval workflow, use some customized CQWP's to ensure a nice layout and we're all set!

Debugging in SharePoint Land

Debugging in SharePoint might seem at first a little bit harder to do, but this excellent post shows that you still have a lot of day-saving tools at hand!