Black Ninja Software » sharepoint

Programmatically and Selectively Revoke SharePoint Item-Level Permissions Using PowerShell

donabel — Sun, 20 Jun 2010 09:36:09 +0000

I’ve been using PowerShell more and more lately, and liking it more and more as I use it.

Here’s another one you might find useful – programmatically and selectively revoking item-level permissions. For this scenario, the SharePoint list already has inheritance broken. Now we have to loop through the versions of SharePoint list items, and check a people/group column called Participant. A participant would have had read/contribute permissions before, but after the list item has been verified, we don’t want the participants changing any of the values anymore.

We will start with the typical loading of the DLL, and creating a handle to our SharePoint site:

#Load the SharePoint DLL
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint") | Out-Null
$SiteURL = $server;
 
#make sure we're using the system account token
$TmpSite = New-Object Microsoft.SharePoint.SPSite($SiteURL);
$SysToken = $TmpSite.SystemAccount.UserToken;
 
$SPSite = New-Object Microsoft.SharePoint.SPSite($SiteURL,$SysToken);
 
#if we want to get additional info about SPSite, code is below
#$SPSite.AllWebs | Format-Table Url, ID, Name, AllUsers
 
$SPWeb = $SPSite.OpenWeb();
$SPWeb.AllowUnsafeUpdates = $true;
 
$MyList = $SPWeb.Lists["My Sample List"];

Now let’s get only verified items from our list:

 
#note your ending herestring must NOT have a space before it.
#also, this "Project Audited" field is really a boolean, 
#but using the Integer works
$CAML = @"

     
        
        1
     
  
"@
 
$SPQuery = New-Object Microsoft.SharePoint.SPQuery;
$SPQuery.Query = $CAML;
 
$itemCollection = $null;
$itemCollection = $MyList.GetItems($SPQuery);
$listItem = $null;

Now the bulk of the work is as follows:

 
if($ItemCollection.Count -gt 0)
{
   foreach($listItem in $itemCollection)
   {
 
        $ID = [string]$listItem["ID"]
        $ProjectVerified = [string]$listItem["Project Verified"]
 
        #now I want to display the roles before I revoke, 
        #so I can verify the changes visually
        #assume in here you already created a new file for 
        #this process, and gave it a handle $logfile
        "Roles BEFORE revoke : "  | Out-File -FilePath $logfile -Append
        foreach ($role in $roles)
        {
            $msg =  "Role : ID " + $role.Member.ID.ToString() + " : Name  " +  $role.Member.Name
            $msg | Out-File -FilePath $logfile -Append
        }
 
        #get the item versions (SPListItemVersionCollection)
        $itemVersionCollection = $listItem.Versions;
 
        #need to check current permissions
        #we'll store all Participants in an array first and evaluate later
        $Participants = @();
 
        foreach($currentVersion in $itemVersionCollection)
        {
            $SPFieldUserValue = New-Object Microsoft.SharePoint.SPFieldUserValue($SPWeb, [string]$currentVersion["Participant"]);
            $Participants += $SPFieldUserValue.User.LoginName
        }
 
        #now, we just want to get the unique people from the version, 
        #so we don't unnecessarily revoke
        $Participants = $Participants | SELECT -Unique
 
        #let's now revoke permissions for every participant
        #that has ever been involved in any version of this item
        foreach($Participant in $Participants)
        {
            $user = $SPWeb.AllUsers[$Participant];
            $listItem.RoleAssignments.Remove([Microsoft.SharePoint.SPUser]$user);
        }
 
        #confirm
        "Roles AFTER revoke : "  | Out-File -FilePath $logfile -Append
        foreach ($role in $roles)
        {
            $msg =  "Role : ID " + $role.Member.ID.ToString() + " : Name  " +  $role.Member.Name
            $msg | Out-File -FilePath $logfile -Append
        }
 
    } 
}

And very very important, do not forget to dispose the SPWeb and SPSite objects you created. It’s VERY bad to not dispose it, as it will definitely slow down your site, one way or another. Believe me, you don’t want to learn this the hard way.

1
2
3

$SPWeb.Dispose();
$SPSite.Dispose();
$TmpSite.Dispose();

Done. Happy times.

- Donabel (@sqlbelle)

We’ve Added an Aztec Warrior to Our Team!

donabel — Tue, 23 Mar 2010 20:02:33 +0000

We’re very excited to welcome Miguel A. Tena as the newest member of the Black Ninja team! As you’ll read more about in his bio, Miguel is a huge fan of SharePoint and ASP.NET development and is already gearing up to become super active in the SharePoint and .NET communities. He’s been working with SharePoint since it’s early days and we’ve already begun leveraging his knowledge, enthusiasm and passion for further development of our training services. Stay tuned for more updates from Miguel in the next couple of weeks.

So, please join us in welcoming Miguel, the Aztec Warrior, to our team!

How to Clear and Repopulate Your ASP.NET DropDown List with jQuery

donabel — Fri, 05 Jun 2009 04:41:28 +0000

Yes you can call and use your ASP.NET controls from jQuery! Shereen has already posted a blog on how you can access these controls JQuery Accessing the Client Generated ID of ASP.NET Controls so feel free to check it out there first.

Recently we’ve had to create a UI that has a datepicker, and the date that a user selects should determine what values get populated in an ASP.NET dropdown.

Here’s how we did it

We’ve listed below the two controls we’re using in this example: a calendar control and an asp.net drop down list.

1 2	<input id="datepicker" type="text" /> <asp:DropDownList ID="ddlDates" runat="server" Width="100px">asp:DropDownList>

For the date picker, we used the DatePicker control from jQueryUI. Their demos and documentation are a great starting point, if you have any troubles with the calendar on your site, drop us a line.

Next, we had to add the following references:

1
2

Then we wired it up! Good ol’ jQuery!

function PopulateDropDownDates(dateText, numDaysToAdd)
{
    var selectedDate = new Date(dateText);
 
    //clear the dropdown
    $("#<%= ddlDates.ClientID %>>option").remove();
 
    //add todays date
    $("#<%= ddlDates.ClientID %>").append($('').val(dateText).html(dateText));
 
    //counter
    for (var i = 0; i <= numDaysToAdd; i++)
    {
        var currentDate = new Date(selectedDate.getFullYear(), selectedDate.getMonth(), selectedDate.getDate() + i);
        currentDate = currentDate.getMonth() + 1 + "/" + currentDate.getDate() + "/" + currentDate.getFullYear();
        $("#<%= ddlDates.ClientID %>").append($('').val(currentDate).html(currentDate));
    }
}
 
$(document).ready(function() {
 
    $("#datepicker").datepicker({
            onSelect: function(dateText, inst)
            {
                PopulateDropDownDates(dateText, 14);
            }
    });

Voila! That’s it. Works beautifully!

Why Should Indexing a SharePoint Field Break Your CAML Query?

donabel — Tue, 12 May 2009 19:03:06 +0000

We ran into an issue today – one of our calculations that rely heavily on CAML queries stopped working. The CAML query we use – which we haven’t changed in forever and which used to work – now returns 0 results when run.

This is what our original query looked like:

>
>
 Name='Project' LookupId='TRUE'/>
 Type='Lookup'>100>>
>

It’s not a complicated query, and this used to work. Used to. But for some reason, it doesn’t anymore.

And for some reason, if we change the Value from Type=’Lookup’ to Type=’Integer’ it magically works again:

>
>
 Name='Project' LookupId='TRUE'/>
 Type='Integer'>100>>
>

Why will using Type=’Lookup’ suddenly fail, and using Type=’Integer’ work? Does this mean we need to change all of our CAML queries that use Lookup?

What changed? No new service packs. No recent patches.

We tried to retrace our steps, in the hope that we don’t have to rewrite all of our CAML queries and retest all our application pages:
1. No change
2. No change
3. Ah, one minor change, but all we did was create an index in the Project field because we have over 2000 items in this list.

Indexing the column should help optimize retrieving records from this list. But could indexing the Project field be the culprit? This seems to be about the only change we did on this list.

But I think to myself, it should not be the culprit. Right?

I am a database person, and I create indexes here, there and everywhere whenever I need performance gains on some of my reports (ok, let me qualify that, I index where it makes sense. Of course if it is a purely reporting read only database, then I will index the heck out of it. OLTP databases are a different story). So for me, I don’t think it should affect the way we retrieve our records using our CAML query.

We needed to test if this was the case, so we did a quick experiment:
1. Created a custom list with a field that uses a regular lookup to another list
2. Used CAML with Type=Lookup ——-> Works
3. Indexed the column
4. Re-tried the CAML with Type=Lookup ——-> Does not work
5. Tried CAML with Type=Integer ——-> Works
6. Removed index from column
7. Re-tried the CAML with Type=Lookup ——-> Magically works again

So, why would (or should) the implementation of our CAML query change when we decide to index, or drop an index, from one of our SharePoint lists?

We tried to look for an explanation, but we haven’t found any official documentation, or any definitive rationale.

Again, maybe I just don’t understand, but in my database world, creating indexes, or dropping indexes from my tables does not break my SQL queries.

So why should indexing break a query in the SharePoint world?

Anyone from Microsoft SharePoint team care to explain? I’m sure we’re not the only ones interested to know the answer.