Role Definitions

Repairing List Item Permission Actions in Exported Nintex Workflows

While working on a sizeable SharePoint and Nintex Workflow development project recently, I came across a significant issue in Nintex Workflow that the support engineers at Nintex said was not a bug. I disagree with them, and had to find a workaround anyway, so thought I would share it.

The Problem

If you export a workflow from one SharePoint system (e.g. a development farm), and import it into a different SharePoint system (e.g. a production farm), if you are using the “Set Item Permissions” action within your workflow, you will discover that it is broken after importing. I did a bit of digging, and discovered why – the exported workflow describes the permissions sets in XML by both their name, and their internal IDs (large integers) – but only seems to use the IDs when importing – Nintex Workflow doesn’t try to correlate the permission sets by name on the destination system, so presumes it cannot find the permission sets described in the workflow actions.

It’s worth repeating – the Nintex support engineer I dealt with said this was by design. I was quite shocked.

The Solution

If you’re working on a sizeable project, you probably have all the workflows exported to a folder on the filesystem. You can therefore process the files to replace the IDs from the original system with those of the target system. So – we can run the following PowerShell script on the files, while they are sitting on the destination server(s):


$url = "https://server/sites/site_collection/subsite"

$uri = [System.Uri]$url

# Loop through files in Workflows subdirectory
foreach ( $source_file in $(Get-ChildItem './Workflows' -File | Sort-Object -Property Name) ) {

    Write-Host $("Processing [" + $source_file.Name + "]") -foregroundcolor white
    
    $file_content = Get-Content "../Workflows/$source_file"
    
    # repair the role definitions in the XML
    Write-Host " - Repairing Role Definition IDs in XML"
    foreach ($role_definition in $web.RoleDefinitions){
        $pattern     = $('\#' + $role_definition.Name + '\;\#None\;\#[0-9]+\$\$\#\#')
        $replacement = $('#' + $role_definition.Name + ';#None;#' + $role_definition.Id + '$$$$##')
        $file_content = $file_content -replace $pattern , $replacement
    }
    
    # Write the file into the modified directory
    $file_content | out-file -encoding utf8 "./Workflows/Modified/$source_file"
    
    Write-Host $(" - Finished Processing [" + $source_file.Name + "]")

}

The above snippet presumes you have all your workflows in a folder called “Workflows”, alongside the PowerShell script. It also presumes a sub-folder called “Modified” exists within the Workflows folder, to put the modified workflows into. The script does a regex search for the role definition names in the XML (the permission sets), and swaps them out for the matching ones for the destination system. After running the script, you end up with a set of workflow export files that work.

In my mind, this entire situation could have been avoided if the developers at Nintex had been a bit more forward thinking. At least there is a solution.

Posted by Jonathan Beckett in Notes, 0 comments

Breaking Permissions Inheritance and Setting up new Permission Sets in SharePoint with PowerShell

The following snippet shows how you might create a new permission set in a subsite of SharePoint. One of the more common permission sets you might need in a production application is ‘restricted contribute’ – contribute without delete. This shows one method of doing that (there are many) – by duplicating the contribute permission set, minus the delete permission.

# Connect to SharePoint Site
$web = get-spweb "https://server/sites/site_collection/subsite"

# Break Inheritance for the subsite
$web.RoleDefinitions.BreakInheritance($false, $false) > $null
$web.Update() > $null

# Get the Contribute Definition
$contribute_role_definition = $web.RoleDefinitions["Contribute"]
$contribute_base_permissions = $contribute_role_definition.BasePermissions

# Delete the role definition if it exists
if ($web.RoleDefinitions["Restricted Contribute"]) {
    Write-Host " - Removing Existing Role Definition"
    $web.RoleDefinitions.Delete("Restricted Contribute")
    $web.Update()
}

# Create a new Role Definition, and copy the Base permissions minus Delete Items
$restricted_contribute_role_definition = New-Object Microsoft.SharePoint.SPRoleDefinition
$restricted_contribute_role_definition.BasePermissions = $contribute_base_permissions -bxor [Microsoft.SharePoint.SPBasePermissions]::DeleteListItems

# Set the name and description of the new role definition
$restricted_contribute_role_definition.Name = "Restricted Contribute"
$restricted_contribute_role_definition.Description = "Contribute without Delete Items"

# Apply the new role definition to the web
$web.RoleDefinitions.Add($restricted_contribute_role_definition);
$web.Update();

# Release Resources
$web.Close()
$web.Dispose()
Posted by Jonathan Beckett in Notes, 0 comments