Help Your Users Choose Good Group Names (Take Away their Choice)

This is a small tip to help your users make the right choices when setting up groups for sites with unique permissions.

It is a very specific post however the main points are:

1. How easy it actually is to help your users by injecting javascript

2. How that help translates directly into easier governance, maintenance and less end-user support

Note: The actual script is MOSS specific but with very modest modifications it can be used in SharePoint 2010 too (equally applicable)

What does it do?

At the “Setup Groups for this site” page after you create a new sub-site (a web) with unique permissions it will choose the name of the group to create for you and make those input fields read-only.

The scheme we’re using is that the group name should follow the site structure followed by the Visitors, Members or Owners label, e.g. Site at “Intranet / Teams / Bravo” would have a members group named “Intranet Teams Bravo Members”. The names will be long but the limit is at 305 characters so you have some way to go until you hit the ceiling. It can be slightly annoying with those long names however as the number of groups in the site collection passes a couple of hundreds you’ll appreciate it.

Note: I’m not handling the 305 character limit (which I found by simple tests), so the script will likely fail for very deep hierarchies. I suppose I could call it a feature to limit the depth likely I’ll change that in the future as the need arises.

It looks something like this (url: .. /_layouts/permsetup.aspx?…):

And yes it works for all three fields though only two are shown.

The Script

The JavaScript is utilizing jQuery so you’ll need to ensure that has been injected into the page (all pages?) before trying to implement this script. You can fairly easily convert it to not use jQuery however I’ve used jQuery on every MOSS site I’ve ever built and I would recommend it to everyone.

$(document).ready(function() {

// The following script sets the group names on the “Set Up Groups for this Site” page
// when you have created a new site with uniques permissions or just entered the page.
// Purpose:
// Enforce the group naming standards, i.e. Full path + Member/Owner/Visitor
// Søren Nielsen 16/6 (

//only fire on /_layouts/permsetup.aspx page
if( /.*\/_layouts\/permsetup.aspx/i.test(document.location.href) ){
var inputs = $(“.ms-propertysheet”)
var trailObj = $(“ span”)

var trail = “”;
//Skip the tail of the trail and concatenate rest
trailObj.slice(0,-1).each( function(i, trailElem) {
trail = trail + trailElem.innerHTML + ” ”

inputs.each( function(j, inputElem) {
if( /.+(Visitors|Members|Owners)$/i.test( inputElem.value ) ){
inputElem.value = inputElem.value.replace(/.+(Visitors|Members|Owners)$/i, trail + “$1”)
inputElem.disabled = true;



  • The $() gizmo stuff at the top is to ensure that the scripts runs after the elements on the page have loaded and the script itself should be injected after the jQuery core script.
  • The first if statement ensures that is only runs on the right page  (permsetup.aspx) so you can safely add this script globally without breaking anything (else).
  • I’ve added an if statement to ensure that I only lock the controls that I actually know how to and do modify. It is possible to hit this page through site permissions where things looks slightly different.
  • It will break for non-english languages. Easy fix is to not look for Visitors, Members or Owners in the regular expression but just use the very last word as such. I have no need for that at the moment though.

We’ve injected it using delegate controls however you could also just add an extra script link in your (system) masterpage.


Think about it this is a light weight customization to help your users and a lot cleaner than coding your own wizards/pages for common tasks like creating a new site. It should not be overdone though – you don’t want your users to download hundreds of KB of javascripting for fixing something on every page.

Also remember that javascripting is (usually) executed after the page has been rendered, so if you do big real estate handling, e.g. hiding the left menu, your page will jump in a not too pretty way. Also remember that your users are sure to be at a slower connection and computer than you and therefore a lot more susceptible to small annoying movements of elements.

There are plenty of other candidates, one example is the “Create new site” page, e.g. fill the url by default when the user writes a title and hide the navigation inheritance selector.

What about 2010? The same page exists, the same issue applies. They changed a bit in the breadcrump html, but that should be a very easy fix.

Note: How do you most easily develop stuff like this? Start Firefox with the Firebug add-in and a text editor (e.g. visual studio). That way you can very easily inspect the html element, execute your selectors to ensure correctness and test the entire script on page without actually deploying it. That assumes that jQuery has already been added. I suppose the learning curve for javascript is fairly steep, however jQuery helps a lot by letting you find elements with a CSS like syntax.