In keeping with the scary Halloween theme, I would like to share a quick tip on how to provide SharePoint Designer data view webpart the ability to delete file (gasp…)

In order to achieve this, we will have to tinker with the xslt that is generated by the data view webpart. So first, you will need to add the dataview webpart on your page to display the contents of document library. You can also use the webpart to aggregate the contents from multiple document libraries. Once you have done that, you will need to add a column (any column will be fine), where we will replace the content of that column to provide the delete link.

Once you add the “dummy” column, locate that in the source view. Replace that with the following:

<a href="javascript:SubmitFormPost(‘/[Relative site]/_vti_bin/owssvr.dll?Cmd=Delete&amp;List=[List GUID]&amp;ID={@ID}&amp;owsfileref={@FileRef}&amp;NextUsing=[Page to go after delete]’);" onclick="return DeleteItemConfirmation();">Delete </a>

Replace the following:

• [Relative site] = The relative site where your document library is (e.g. /sites/test)
• [List GUID] = The list GUID. You can find it easily by looking at the web address URL when you browse to list settings (e.g.: =%7B9A3C5BDF%2DDA36%2D4D48%2DBE5D%2D7CAC5B0C9975%7D)
• [Page after delete] = The page you want redirection to once the delete function is called. (e.g.: /sites/tests/pages/delete_dataview.aspx)

It is scary how simple we can provide delete functionality to end users. However, you do not need to worry. This delete function does exactly what the delete function through SharePoint UI, so if you have recycle bin, then the document will be sent to it.

Note that if your dataview webpart aggregates the contents from multiple document libraries, then you need to provide separate links for separate document libraries, since you will need to pass appropriate document library GUID. What I have done for my dataview webpart is to provide choose-when-otherwise clause of XSLT.

Happy Halloween and happy coding…

Have you ever needed to hide certain contents on your SharePoint page, be it a control or custom javascript? Luckily, SharePoint provides a control to allow you to do just that. The control is SPSecurityTrimmedControl. If you use SharePoint Designer to edit your page and insert this control, anything within this control will only be rendered on your page if it passes the criteria. The criteria it uses is SharePoint permission. You can easily google/bing this control for more information.

However, this control does not meet my requirements. I needed to selectively provide contents based on SharePoint groups, not permissions, since multiple groups can have the same permissions. If you ever have to meet this kind of requirement, do not panic. The SPSecurityTrimmedControl can be easily extended. Below is the code I created for my custom control that extends SPSecurityTrimmedControl.

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Linq;
using System.Text;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using Microsoft.SharePoint;
using Microsoft.SharePoint.WebControls;
namespace Yaohan.SharePoint.CustomControls
{
    public class SPGroupTrimmedControl : SPSecurityTrimmedControl
    {
        private string groupName;
        public string GroupName
        {
            get { return groupName; }
            set { groupName = value; }
        }
        protected override void Render(HtmlTextWriter output)
        {
            if (IsUserInGroup())
                base.Render(output);
        }
        private bool IsUserInGroup()
        {
            bool retVal = false;
            foreach (SPGroup group in SPContext.Current.Web.Groups)
            {
                if (group.Name.Equals(GroupName))
                {
                    retVal = group.ContainsCurrentUser;
                }
            }
            return retVal;
        }
    }
}

What you need to do is whip up Visual Studio and create a web control project. Make sure you “strong name” the project and sign it.

To deploy, you can drop the DLL in GAC, however I will strongly advise you to package this up using SharePoint solution, which should be simple enough to do (create manifest.xml, reference the DLL on assemblies tag and the safe control tag).

After you deploy your DLL, you need to register your custom control, either on your page (if it’s page-specific), page layout or masterpage. Below is the snippet of control registration

<%@ Register Tagprefix="Yaohan" Namespace="Yaohan.SharePoint.CustomControls" Assembly="Yaohan.SharePoint.CustomControls, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3e15ae9471d9f940" %>

And to use the control in your page, you can do the following:

<Yaohan:SPGroupTrimmedControl ID="GroupTrimmedControlForReaders" GroupName="Yaohan Special Group" runat="server">

Kudos to Yaohan special group only.

</Yaohan:SPGroupTrimmedControl>

Now you can extend this control to selectively display contents to not just SharePoint group, but AD group (ala target audience). Multiple groups, or collection of users.

You may ask why you should do this instead of using content editor webpart with target audience. In my scenario, I cannot use content editor webpart, because I need a quick and easy way to hide fields in item display form based on the group the current user belong to. For example, if you have details of asset inventory, I only want to show a general information about the assets for read-only general readers (such as description, photo, etc), but for specific group, I want to show more details.

The way I achieve this is by having a javascript between my custom controls to hide the fields I don’t want to show. Beware that the javascript is only to hide the information, not securing it, thus if users know what they’re doing and view the page source, they can still find the information. If you want a field-based security, there is a third party product that caters for that.

Credit goes to http://blah.winsmarts.com/2008-5-Enhancing_the_SPSecurityTrimmedControl_-_Trimming_UI_on_any_critereon.aspx for providing me inspiration.

Today, I tried to restore a site collection from a backup site collection file to a site collection that I created in new content database. The following is the scenario I took:

1. I used stsadm –o backup –url to create a site collection backup file. My site collection is based on collaboration portal site definition (SPSPORTAL#0)

2. I created a new site collection in new content database using stsadm –o createsiteinnewdb using SPSPORTAL#0 as my site template

3. I used stsadm –o restore to restore my backup file into the new site collection.

Everything is reported okay, but beware that the site is not correct. If you go to check the site content types and site columns, it is empty. Thus, it will cause all sorts of problems.

So, just be careful when you’re trying to move your site collection using stsadm backup restore while using SPSPORTAL#0 site definition.

p.s.: My environment is MOSS 2007 SP1

UPDATE: Issue still occurs when you do import export of site collection based on SPSPORTAL#0 with site collection in new content database. In particular, I cannot access the site output cache settings. I didn’t have time to investigate further, so just be aware of this issue.

I recently enabled kerberos authentication on MOSS 2007 that uses least privilaged access. While setting up the SPN, I learnt one valuable lesson. You cannot have multiple AD accounts that are associated with the URL.

For example, you cannot have:

domain\app_pool1 associated with http://myportal.com and domain\app_pool2 associated with http://myportal.com

Kerberos ticket won’t be issued when it encounters 2 different account associations for the URL. This article that I found is so valuable:

http://www.windowsecurity.com/articles/Troubleshooting-Kerberos-SharePoint-environment-Part1.html

Kudos to Jesper M. Christensen. You saved a lot of hard work for me

In summary, when you want to enable kerberos on your web application, you just need to associate the identity of your app_pool to the URL.