Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

There is already a webpart for this but it shows subsites etc, which is not the requirement.

What I need is a webpart that will list the Site collections a target user is a member of, and it must be robust enough to work with groups and AD.

I tried to check permissions however on closed site collections that the user who is viewing the list is not a member of won't show.

What I need is a way of making this transparent, so that any user can see another users site collections.

Any more ideas? I have tried several, and they either run into permissions issues or are too heavy in processing to be viable.

[update] This is more of a challenge now than a NEED, best slickest answer gets the goodies.

[update 1] This solution needs to be robust enough to check for a specific permission, this is due to certain sites in some collections are blocked, but some are set to read, this is done with groups, and there are open and closed site collections, which means the users get read access tot he root collection but cannot access higher ones, and sometimes are blocked totally.

The issue with this was that a user requirement was to simplify the view for permissions with users and to only show 3 custom groups, meaning we had to recode the a mass quantity of built in web parts and replace them with custom ones, also limiting views.

With this in mind, a user is given a certain group access in a site collection to be able to have a different level, by default they all get "Non Member" with gradually higher permission types. Default built in groups are not used in this installation so RunWithElevatedPriviliges was not used and we used impersonation to an AD user we created to do the same thing, different site collection types have different setups and this allows us to modify the granularity of the situation. (End users are a pain when they want to break out of the box.)

This is a 100% customised deployment and everything works perfectly, except the site collection membership display is slow with the current method, and I want to make it better!

share|improve this question

3 Answers 3

up vote 2 down vote accepted
+50

The scalable solution to this is to use search:

  • Create a feature to activate on all sites/rootsites depending on what you need to show
  • Create a Content Type
  • In the feature create a hidden list with at single item of that content type having the title equal to the Sites title
  • Change the view page of the item to go to the front page of the site
  • In your web part do a search for all items with that content type, that'll be the sites the current user has access to
share|improve this answer
    
+1 I like this a lot. Let SharePoint Search do the heavy lifting with permissions and your webpart will display instantly. I think this is about as close to realtime as you can get while still being scalable. –  Kit Menke Sep 28 '12 at 16:23
    
This is the sort of solution I was looking to get for this, I like it, much more elegant and better for leveraging the built in resources we already have. +1 accepted answer and bounty awarded. –  Hugh Wood Sep 30 '12 at 17:29

It would be difficult to achieve this using a webpart, as you would need to enumerate all sites in a site collections, in all webapps, in the farm. I think its better to build a Powershell utility, to do this job.

share|improve this answer
    
Sorry this solution just won't cut it for the environment, the company who's servers don't like this sort of approach, and like things to be encapsulated a bit more. I need something slicker and run in page preferably but efficiently. –  Hugh Wood Sep 24 '12 at 10:24

The answer often varies by scale. In the small you could do this e.g. in the code-behind of a web part. However, this won't scale because what we are trying to do has exponential complexity. Perhaps you are already running into this.

The usual approaches apply for making something like this work at scale. It is often necessary to store the information (e.g. in SQL Server) as opposed to querying for it each time. Typically this involves [1] a full crawl or equivalent process for getting all of the info (when necessary) into SQL Server and [2] relying on e.g. web-scoped event handlers for keeping the stored info up to date incrementally.

A number of commercial products take this approach. Then, our web part simply queries (and perhaps caches in memory) the relevant stored information from SQL Server to meet its immediate rendering needs.

This may seem like overkill because we are almost creating a subsystem instead of a web part. However, the SharePoint object model does not give us many options because opening up an SPSite is a relatively expensive (in both time and space) operation.

share|improve this answer
    
I do agree with this one and I gave you a +1, but I am really excited to see if someone has a way of doing this with low overheads, I don't think there is but 50 points if there is, it will solve more than just this problem for code solutions. –  Hugh Wood Sep 26 '12 at 8:54

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.