Archive for Sharpoint Designer 2010

SharePoint Data View Conditional Formatting based on user permissions

In your Data View or Data Form web part, you can conditionally display content based on the ddwrt:IfHasRights() function.


Trying to get info on values for permissionMask from the advanced conditional formatting dialog box was not possible because there is no scrolling of this information in the UI (bug)

After a bit of searching, I found the values in C:\Program Files (x86)\Microsoft Office\Office12\CAML2XSL.XSL

The permissinMask value is the sum of any of the values below:

ViewListItems – 1

AddListItems – 2

EditListItems – 4

DeleteListItems – 8

ApproveItems – 16

OpenItems – 32

ViewVersions – 64

DeleteVersions – 128

CancelCheckout – 256

PersonalViews – 512

ManageLists – 2048

ViewFormPages – 4096

Open – 65536

ViewPages – 131072

AddAndCustomizePages – 262144

ApplyThemeAndBorder – 524288

ApplyStyleSheets – 1048576

ViewUsageData – 2097152

CreateSSCSite – 4194314

ManageSubwebs – 8388608

CreateGroups – 16777216

ManagePermissions – 33554432

BrowseDirectories – 67108864

BrowseUserInfo – 134217728

AddDelPrivateWebParts – 268435456

UpdatePersonalWebParts – 536870912

ManageWeb – 1073741824

UseRemoteAPIs – 137438953472

ManageAlerts – 274877906944

CreateAlerts – 549755813888

EditMyUserInfo – 1099511627776

EnumeratePermissions – 4611686018427387904

FullMask – 9223372036854775807

Displaying SharePoint Fields by Permission Level

There are situations where certain fields in lists or libraries need to be hidden or displayed according to the permission level of the logged in user.  Since there is really no out-of-box way to assign permissions to fields, here’s a way to do it using conditional formatting in SharePoint Designer.  This is my favorite SP Designer trick, that I discovered a few months ago.

See my reference (Ian’s SharePoint Blog):

In this example, the field called “Priority” needs to be hidden from everyone except for those users who have rights as approvers on this custom list.  Also, there is a field called “Audit Date”, that only approvers need to be able to edit, but other users (even those with edit rights) should not be able to edit this field, and everyone can see it.

Doing this entails creating custom forms for all three forms (NewForm, DispForm, and EditForm) in the list.

Here goes…

1.  To keep this simple, create a custom list called “Policies” on your site.  There are 4 fields: 
Policy Name (changed from the default Title field)
Priority – multiple choice
Notes – multiple lines of text
Audit Date – date/time


2.  Create a blank web part page in the same site collection as the Policies list.  It doesn’t matter where you save it, since we’ll be deleting it later.

3.  Open this web part page in SharePoint Designer.  Click on “Click here to insert a Web Part”.  This is really just to make sure that you insert this web part into a web part zone, and not some random spot on the page.

4.  On the menu, choose SharePoint Controls, then Custom List Form.

5.  Pick the Policies list, then choose New Item Form.  OK
6.  Select the entire table row that contains the Priority field.  This is the field that we want to hide from everyone except approvers.  On the menu, choose Conditional Formatting.

7.  In the Conditional Formatting screen on the right, click , and choose .  On the Condition Criteria screen, click


8.  Select IfHasRights from the list of functions, and then put the number 16 in the parentheses.  To see where I got the number 16 (approver permissions), click on the link to Ian’s blog above.  Click OK.  Click OK again.


9.  Next, the Audit field needs to be only editable by list approvers.  So, since this is the new item form, we’ll just hide it from everyone else.  So, select the Audit Date row, and put the exact same condition on it with conditional formatting.

10.  Save this page.  It’s okay to customize it from the site definition.

11.  At this point, it does help to have some data in your form, so go ahead and create a couple of list items.

Also, I’d like to note that when using custom forms like this, the Attachment button doesn’t work anymore.  I think there are blogs somewhere about this bug, but I’ve never tried fixing it.

12.  Create a new, blank web part page in the same place you created the first one.  This will be the EditForm page.  Repeat steps 3 & 4.  Then, this time when inserting the Custom List form, select “Edit item form”.

13.  Repeat steps 6, 7, and 8 on the priority row.

14.  Next, we essentially need to make two copies of the Audit Date field.  We want it to be editable to list approvers, and visible (not-editable) to anyone else.  Create a new row in the table.

15.  Put the text “Audit Date” in the left cell, and put the cursor in the right cell.  In the pane on the right, select the Audit Date field, then click Insert selected field as –> Formatted –> DateTime.  Then, you can opt to uncheck the Time check box, and click OK.


16.  Select the row of the editable audit date field.  For the conditional formatting, only show the content when IfHasRights(16).

17.  Select the row of the read-only date field (the one that was inserted in step 15), and create a conditional formatting rule to HIDE content when IfHasRights(16).

At this point, since you most likely have full control permissions on this list, this row will seem to disappear!  While you’re doing this design work and showing/hiding fields, you can go to the Conditional Formatting pane, and click Set Visibility and choose All Formatting hidden.  This will let you see the field you just hid.  Be sure to set it back to default when you’re done.

HANG in there, only one more form to go.

You know the drill… create another blank web part page…
When you insert the custom list form this time, choose “Display item form”
All we have to do on this one is create a conditional formatting rule that will show the content IfHasRights(16)

NOW, it’s time to save each of these data views as web parts.  Go to the browser, and navigate to the library where you saved the 3 web part pages you just created.  Open each page export the web part.  Save the *.webpart files to your desktop or whatever.  In the filename, be sure to indicate whether it’s New, Edit, or Display.


In your Policies list, create 3 new, standard views, and call them “New”, “Edit”, and “Disp”.

On each of these new views:
– click and .  Delete the default list view web part.  Be sure to delete it, not just close it.
– Import the associated web part from your desktop.
– Exit Edit Mode

Now that there are 3 new forms in the Policies list, the last thing to do is associate them correctly. (I think that’s the right terminology).  Anyway, go back to SharePoint Designer.

In the left pane, under the Lists folder, right click on the Policies list, and choose “Properties”.

Click the “Supporting Files” tab.  Change the content type to Item.
Change each of the 3 supporting files to your new Edit, Display, and New aspx files.

Fun!  Now test it!

Once it’s just the way you like it, then you can delete those 3 original web part pages that you exported from.  Check it out, we didn’t leave anything unghosted!

Move a Sharepoint Designer Workflow to a different Farm

Sharepoint 2010 has introduced lots of new features in Sharepoint Designer Workflows. What used to be a technology designed to allow some power users to create their own workflows and associate them with Sharepoint lists is now a much more powerful tool. Amongst the new features introduced are the possibility of creating reusable and global reusable workflow that can be reused in the same site or at the Site collection level, create Site level workflows and also to export Sharepoint Designer workflows to .WSP templates

What we are interested here is in this very last new feature. In theory, Sharepoint Designer workflows can be exported to solution files and then imported in a different Site Collection or a different Sharepoint Farm. Now they can even be opened in Visual Studio 2010, although it’s not a reversible process and once opened in Visual Studio they can’t be changed using Sharepoint Designer anymore. In previous versions it was a very bad idea for developers to create workflows in Sharepoint Designer, the main issue being that these workflows could not be moved across environments. It was not possible to design a workflow in a development platform, then move it to a test environment for testing and finally once accepted deploy it to production, workflows had to be created directly at production and tested from there.

Sharepoint Designer workflows weren’t meant to be used by developers to create new workflows. And they still aren’t. What I try to show in this article is how to move Sharepoint Designer 2010 workflows across farms and while this feature can be useful in many scenarios, I strongly encourage you as a developer to try to build your workflows in Visual Studio, this is the proper way to implement, distribute and mantain any workflow. 
So let’s ignore that last warning and try to move the workflow 🙂

What we have to do here is create a new Sharepoint Designer workflow, it has to be a reusable workflow because only those can be then saved as templates. For this demo I just created a workflow that logged a string in the workflow history. Once we have finished with the workflow we save it and we click on the “Save as Template” button on the ribbon bar.

This will generate our Solution .wsp file and save it in the “Site Assets” document library on the current site.

After this the next step is to download a copy of the Solution file and upload it to the other Sharepoint Farm where we want to move the workflow to. We navigate to the Solutions gallery and upload the .wsp file, finally we have to activate the solution.

Once activated, a new feature will appear on the Site Features of all sites in the current Site Collection, we navigate to the Site where we want to use the new workflow and activate that feature.

This feature deploys the workflow to the workflows list and after activating it we would expect to have the new workflow available in the Site Collection. Unfortunately, if we navigate to the Workflows list at the Site Settings page, we won’t find our workflow there ! 
I opened the feature definition file that was deployed as part of the solution and I found that it should have deployed the workflow .xoml file in the workflows gallery of the Site Collection. To check if that was the case, I opened Sharepoint Designer and navigated to the Workflows section and surprise! the new workflow was there.

What we need to do then is open the workflow in Sharepoint Designer and click on the Publish button. This will publish the workflow again in the Site Collection and after we do that it will appear on the workflows list and we will be able to run it and associate it to Sharepoint Lists.