Site collection administrators / owners question

Question

I'm stuggling over a somewhat architectural question which concerns site collection admins and owners. To begin with, I found the thread answerd by Per Jakobsen (here Site collection owners and site collection administrators. Can anyone explain the difference in plain english). I understand it, but I need to know if I can apply it to fill in the business requirement I've got.

The requirement states the users need to be able to request a new site collection. After approval (workflow), the user requesting the site will be made site owner, but should not have permissions to manage settings scoped to the site collection (site collection features for instance). Those settings should be managed centrally by the portal management team.

I though of this solution: - Create a new site collection and set the user as the primary site owner. - The user is automatically added to the site collection administrators group, but we'll delete him there. - The user is automatically added to the site owners group, which is ok.

So afterwards, the user will be listed as site owner (which receives the quota warnings and such), will not have rights to manage site features (because he is not in the site administrators group) and will have manage feature rights on a web level (since he's a site owner).

After initial testing this seems to work as expected, but I want to make sure I'm not missing anything here which will be hard to make right once provisioning has started.

Update: it seems I was wrong. After deleting my account from the site collection administrators group, it was also removed from the site collection owners entry. So I cannot remove it from the site collection administrators group without also losing the e-mail warnings for quota's and such. So then the question becomes: how can I leave it in those groups, but put restictions on things like site collection feature management?

Answer 1

To answer my own question: it's a combination of things.

Using features you can hide options from the Site Actions page, which disables the editing of features for instance. One thing I didn't check though, is if the feature management pages actually are disabled when you directly navigate to them by URL. For us, hiding the links was enough.

Other permissions, like creating groups, can be disabled by removing the permission level in Central Admin.

So like that you can leave your user in the primary site administrator role, but still manage the actions available. Because some of this is being done at web application level, you'll probably need a seperate web application for sites to which this behaviour applies.