Sitecore Permissions

Sitecore permissions are always a bit of a pain to figure out. You’ve got the question of inheritance of rights from parent nodes, and how role rights conflicts are resolved.

Well, these two links are particularly useful, I found:

There’s quite a lot of reading there, but it’s good content. The easiest way I’ve found for considering permissions is:

Unspecified (effectively no-access) is beaten by Inherited rules (variable) is beaten by Allowed (has access) which is beaten by Deny (No access).

In other words, an explicit Deny will block access to a user.

If there is a conflict between explicitly assigned roles, Deny wins.

If rights are assigned directly to a user (rather than a role) they win – though you shouldn’t be assigning rights directly to users. It’s unmanagable in the long term.

Simple, right?

 

Advertisements
Sitecore Permissions

Determine if a user is a farm administrator

Sometimes you just need to know if a user is a farm admin; conveniently SharePoint provides a couple of static methods on the SPFarm object to check this:

if( SPFarm.CurrentUserIsAdministrator() ) { ... }

Neat, but one tip – it’s not obvious but it seems that if you want to check this within a content web application, you have to use the method that accepts a boolean and that bool needs to be true:

if( SPFarm.CurrentUserIsAdministrator(true) ) { ... }

Otherwise you will only ever get a ‘false’ response.

Determine if a user is a farm administrator

How I simplified the Users and Group UI – Removing Users

The final component in my users and groups UI is the ability to remove users. This is based very much on how SharePoint works – and it’s a little ugly. My apologies -but this is how SharePoint does it.

Our ListView shows our users. Each user has a checkbox next to them:

ListView

I’ve added a ‘Remove Users’ LinkButton to my fake ‘toolbar’:

Title and View Controls

That LinkButton is defined in my page as:

<asp:LinkButton UseSubmitBehavior="false" id="BtnRemoveUsersFromGroup" runat="server"
Text="Remove Users"
OnClick="BtnRemoveUsersFromGroup_Click"
OnClientClick="return BtnRemoveUsersClick();"
/>

So, on click it runs some client script, and then posts back a click event. So, how do you know which users have been selected within the postback? You could have zero-to-N checkboxes! Continue reading “How I simplified the Users and Group UI – Removing Users”

How I simplified the Users and Group UI – Removing Users

How I simplified the Users and Group UI – Resolve the MembershipGroupID

So, one of the things I skipped over in my last post was just how you get the MembershipGroupID for the group you want the users to administer. Well, there are lots of options – all you’ve got to do is get to your page with the ListView with the correct value for the GET parameter MembershipGroupId.

If you knew the ID in advance, you could hard code it. I didn’t, so I used a redirect page. Continue reading “How I simplified the Users and Group UI – Resolve the MembershipGroupID”

How I simplified the Users and Group UI – Resolve the MembershipGroupID

How I simplified the Users and Group UI – Intro

Previously, I’d blogged about a simplified Users and Groups UI for SharePoint. I really annoys me that the standard one is so complex – I’m a techy, and a specialist, and it confuses me! I’m not sure what chance non-specialist admins will have.

The worst part is, though, often users just want to add or remove users from a pretty limited set of groups. I mean, this is implied by the standard ‘Visitors/Members/Owners’ groups on a site. Unfortunately, there are often a lot of other groups, and other complexities shown through the standard user interface in SharePoint.

For a Case Management system we’ve been working on, I built a simplified user interface. The idea was to make it easy for non-techies to add and remove users from specific groups. They weren’t to have access to all groups, and this wasn’t to replace the ordinary People and Groups pages – so more technical staff could still use those too. What I came up with is shown below.

case-permissions-page

It appears similar, initially – but the navigation on the left is the same as for the rest of our case site. Only the relevant groups (“Case Workers” and “Case Owners“) are linked to on the left, and these links are only shown to users who can edit the groups (Home and Audit aren’t related to people and groups). Also, the menus on this page only let users add or remove users – which is all they should need to do.

Note that the “Case Workers” and “Case Owners” groups are just the groups we happened to be using – you could build this to work for others, depending on your needs.

I built this user interface using 3 application pages put into the _layouts directory. They’re actually Code Behind ASPX pages, and so this is a Visual Studio solution, though some sections of the application could be built in SharePoint Designer.

The pages themselves are for:

  • Listing the users and letting admins remove users.
  • A page for adding new users.
  • A redirect page for identifying the correct ID for the group we want to edit.

The solution is a little complicated, so I’m going to break it down into pieces:

How I simplified the Users and Group UI – Intro

Simplified People and Groups pages in SharePoint

One of my pet peeves with SharePoint is the People and Groups pages. These are pretty damn complicated.

standard-perms-page

You typically get groups for:

  • Owners
  • Members
  • Visitors

And often you can have

  • Approvers
  • Moderators
  • Designers
  • Individual users granted rights directly on the site (rather than being in a group)

… and so on. And if individual sites start to break from inheritance and define their own groups, you get even more groups. It’s possible (especially if the administrator of the system doesn’t understand what they’re doing – which is often the case) to end up with 3 times as many groups as sites!

Frankly, this is enough to confuse me, never mind users. Trips into the People and Groups pages often takes me some time to understand what I’m seeing. And the worst part is that often users just want to be able ‘Give Fred access to this site’. They don’t care about other groups or other sites, permissions levels, or any of that jazz.

The case management system we’re working on at the moment has this sort of requirement. Each case is a site, and we want ‘Case Owners‘ to be able to add/remove ‘Case Owners‘ or ‘Case Workers‘. They don’t need access to other groups. They don’t need the ability to send emails, call people, remove users from the site collection, or any of the other (confusing) options on the menus. So, I built my own administration pages… Continue reading “Simplified People and Groups pages in SharePoint”

Simplified People and Groups pages in SharePoint

UpdateListItems Web Service fails when using item level permissions

This tip come from one of my colleagues, but it’s a good ‘un:
For those of you familiar with the Lists.asmx web service in SharePoint, you’ll know that the UpdateListItems() method allows you to apply metadata to a list item. The following XML provides a simple example of how I’ve been using it so far….
<Method ID='1' Cmd='Update'>
<Field Name='ID' />
<Field Name='FileRef'>http://site/library/folder1/folder2/mydoc.pdf</Field>
<Field Name='ContentType'>Invoice</Field>
<Field Name='InvoiceNumber'>12345</Field>
</Method>
Under normal circumstances, the above XML works just fine. However, if you enable fine grained permissions [Item Level Permissions] in a document library it will break with a permissions related error (even though you have permissions to perform the action!) Continue reading “UpdateListItems Web Service fails when using item level permissions”
UpdateListItems Web Service fails when using item level permissions