views:

289

answers:

4

I have an Events list in sharepoint and need to disallow users from having the ability to create meeting workspaces in the new event form. Shy of customizing the new event form (which breaks attachment support), how can this be done?

+1  A: 

By default, in order for users to create a meeting workspace, they will need to be an administrator or Site Owner (specifically they will need the Create Sites permission). If you don't give them this permission, they won't be able to create a meeting workspace.

This will disallow the user to create any site under the site where these permissions are set. I'm not aware of a way to restrict access to a specific site definition but still allow users to create a different one.

Bryan Friedman
A: 

I don't think there is a supported way of doing this. One option is to edit the WEBTEMP.XML file in C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\1033\XML\WEBTEMP.XML (make a backup first of course). Comment out the lines as follows:

    <!-- <Template Name="MPS" ID="2">
    ...    
    </Template> -->

After editing this file and executing IISRESET on every server in the farm, you shouldn't be able to create a meeting workspace any longer.

Alex Angas
Wouldn't this affect all webapps in the farm? I cannot let my solution affect other solutions that may use meeting workspaces
andrew
A: 

If you can get some javascript into the masterpage, I came up with this little hack.

It does have a couple downsides in that MS could potentially releaase a hotfix or service pack that either:

  • changes the name of the "Use a Meeting Workspace to organize attendees, agendas, documents, minutes, and other details for this event" checkbox such that the string "CrossProjectLinkField" is no longer in the name, or...

  • they could use that same string in the name of some other input element on some other OOTB markup

In the ladder case (which I'm not entirely certain is false right now), these inputs would get disabled if they were sporting a masterpage that ran this script.

But this is a risk I can deal with. You run these risks anytime you depend upon client ids and names being emitted by someone else's control.

<script type="text/javascript">    
    var anchors = document.getElementsByTagName('input');
    for(var i=0;i<anchors.length;i++)
    {
        var anchorName = anchors[i].name.match('CrossProjectLinkField');
        if(anchorName != null)
        {
            anchors[i].disabled = true;
            break;
        }
    }
</script>

What this does is find the checkbox that allows users to create meeting workspaces and disables it so that they cannot check it. Problem solved!

andrew
A: 

Create a web scoped feature with a feature receiver that deletes the current web the feature is activated on and have it throw an SPException stating that the template cannot be used. Then create a web application or farm scoped feature stapler that staples the previous feature to the site definitions you want to prevent. Activate that feature on the web application or farm. Then when someone creates a site from one of the site definitions the site will be deleted and the user will be presented with an error page displaying the text of the SPException thrown.