I’ve had a support call from a client; an application that I’d written wasn’t letting some users see the subsites of a particular site. However, in the web browser, they could see (and navigate) to those sites. “Strange”, I thought, “they must’ve misconfigured their permissions”. Well, they hadn’t.

My app communicates with SharePoint via the Web Services, and tracking through my code showed me that the problem was coming from the Webs.GetWebCollection call. As this problem was only affecting some users – notably, those who’d have limited rights, I wondered if this was a permission issue. It seemed strange though; users could still see the sub-sites, either in the navigation menus or in the ‘View all site content’ page.

Digging further into permissions, I found that users with ‘Read’ rights got errors with my application. I decided to set up a test system.

I created a site collection with three ‘levels’ of sites (Gateway, Branch, Subsite). For my test, I would use the Gateway site, the Branch A site inside it, and the Subsite 1 site inside that. Thus, they looked like:

Gateway > Branch A > Subsite 1

I then created four users and gave them different memberships on the different sites:

	Gateway	Branch A	Subsite 1
Alice	Member	Member	Member
Bob	Visitor	Member	Member
Chan	Visitor	Visitor	Member
Dina	Visitor	None	Visitor

As usual, Members have Contribute rights and Visitors have Read rights

I tried logging into SharePoint through the web browser as the different users to see what I could see in the navigation. Alice, Bob and Chan all saw the same:

All these users could see and navigate to Gateway, Branch A and Subsite 1 without error, although sites where they were only visitors they couldn’t make any changes, like creating new documents, etc..

The user Dina was a little different though. With no rights on Branch A, she couldn’t see it in the navigation:

She could, however, still go to Subsite 1 via it’s URL.

Note that the breadcrumb shows Branch A, but clicking on it gives:

So far, so good. The browser interface behaves pretty much as one would expect.

Next, I wrote a console app that would, as each of the users, try the Web.GetWebCollection web service call on each of those sites. The results I got were:

Looking through the results, a pattern becomes pretty clear. Only sites where the user has Contribute rights work correctly, otherwise the result is an error. In other words, users with Read rights aren’t able to call the Web.GetWebCollection service, even though they can see sub-sites of the site in the web browser.

Strange.

So what permission is doing this? Looking at Read and Contribute perms, I noticed the Browse Directories permission:

Hmm. All I can find on google says:

Enumerate files and folders in a Web site using an interface such as SharePoint Designer or Web-based Distributed Authoring and Versioning (Web DAV).

Well, it looks like something related to web services. I mean, SharePoint Designer must use the web services, right? Well, one way to find out – I added that right to the ‘Read’ permission level, and ran my application again:

This looks better – all calls have been successful, apart from Dina’s request of Branch A, which is also correct – she has no rights on that site!

So has this affected what users can see and do in the web interface?

Well, no, would be the short answer.

So what is the Browse Directories permission? Well, damned if I know. All I can find on Google is the same text as above. I gather that it does somehow affect Spell-checking, but that still doesn’t tell me what it does.

After a fair bit of testing, I can’t see any other effects.