Changing permissions during workflow's life time

Question

Hello everyone!

I'd like to remove permissions from list item creator after he started the workflow.
List item goes around some persons which correct the information in the list, and I'd like creator
could not edit the list item during the travel :).

I can define "read" permissions using wellknown decision named "Useful Sharepoint Designer Custom Workflow Activities"
from here http://spdactivities.codeplex.com/wikipage?title=Grant%20Permission%20on%20Item&referringTitle=Home.

But!

The workflow runs under permissions of user run it manually or created list item (if the workflow runs automaticaly). And workflow can't change any information in the list item after I remove permissions from user created the list item.

Whether somebody can give correct advice to me?

Thanks a lot.

Answer 1

Don't all workflows run under the system acount? Are you creating the items with the sytem acount? If so you should create a user account and then try creating the items, or manually start the workflow.

I've also had to change the permissions of a workflow item. I did this in visual studio though not in designer.

In a VS workflow you can create a custom role definition with the permissions you want then bind that definition to a role assignment for a particular group or user. (or you can use existing role definitions such as 'contribute', 'read' etc.)
Then you add that role assignment to the current workflow item.
If you google around there are some examples of this or I can show you what I did if you're interested.

Answer 2

That is right.

Problem is in different permissions of VS and SPD workflows. VS WF runs under system account and SPD WF runs under user account started it.

Question is: can I without using VS change permissions of user started WF and leave this WF in workable state?

Certainly, I'm very interested in your examples.
Please, contact me via email

Answer 3

Ah I see, I didn't realise it was different for VS WFs and SPD WFs.

It is possible to change the value of fields in SPD isn't it?
I'm not sure if this would work - you could change the value of the 'Author' field to an administrator account then maybe the WF can still run and make changes to the item. Although I don't know if this would remove the permissions of the original creator though.

I'll show you my example-I'm at home now so will post it here when I'm at work on Monday.

Answer 4

It's a good idea. I'll try on Monday.
Will wait for examples :)

Answer 5

"you could change the value of the 'Author' field to an administrator account "

I tried.
I can't change value of Author field in SPD :(

Answer 6

I'm stumped, the only thing I can suggest is switch to using a VS worfklow though maybe someone out there has a better solution.

Here is how I change the permissions of a list item in VS for a helpdesk.

SPWeb web = this.workflowProperties.Web;
//create role definition            
SPRoleDefinition rd = new SPRoleDefinition();

//new role assignment for group HelpDeskVisitors
SPPrincipal principalStaff = this.workflowProperties.Item.Web.SiteGroups["HelpDeskStaff"];
SPRoleAssignment ra = new SPRoleAssignment(principalStaff);

//new role assignment for group HelpDeskStaff
SPPrincipal principalVisitors = this.workflowProperties.Item.Web.SiteGroups["HelpDeskVisitors"];
SPRoleAssignment ra2 = new SPRoleAssignment(principalVisitors);

SPListItem item = this.workflowProperties.Item;

//break inheritance of role assignments and don't copy role assignments (i.e. item will have no RAs)            
if (!item.HasUniqueRoleAssignments)
{
    item.BreakRoleInheritance(false);
}

/*create the role definition, since the workflow runs many times
check the role definition has not already been created */
if (web.RoleDefinitions["Ticket Read-Only"] == null)
            {
                rd.Name = "Ticket Read-Only";
                rd.BasePermissions = SPBasePermissions.ViewListItems;
                web.RoleDefinitions.Add(rd);
            }

//bind role definition created above to role assignment for HelpDeskVisitors
ra2.RoleDefinitionBindings.Add(web.RoleDefinitions["Ticket Read-Only"]);

//bind role definitions approve,contribute,read to role assignment for HelpDeskStaff
ra.RoleDefinitionBindings.Add(web.RoleDefinitions["Approve"]);
ra.RoleDefinitionBindings.Add(web.RoleDefinitions["Contribute"]);
ra.RoleDefinitionBindings.Add(web.RoleDefinitions["Read"]);

//add the role assignments to the item
item.RoleAssignments.Add(ra);
item.RoleAssignments.Add(ra2);

item.Update();

So in the end the group HelpDeskVisitors can only read the list item ("Ticket Read-Only") and the group HelpDeskStaff can approve, contribute and read the item. I could have just used the Read role definition for the visitors group but I wanted to try this. Hope that is of some use or of some interest.

Answer 7

Thanks a lot.

This looks good.
I'll try to use your code.

Probably it's the unique decision of a problem.

Can anybody correct me? :)

Answer 8

The workflow runs under permissions of user run it manually or created list item (if the workflow runs automaticaly). And workflow can't change any information in the list item after I remove permissions from user created the list item.

That’s why you use third party SharePoint workflow activities which can be some kind of security issue.

 

SharePoint Designer (SPD) workflow runs under the security context of the interactive user and visual studio workflow for SharePoint runs as the system account.  However, third party SPD activities may run impersonating other users. For impersonating code samples, please refer to http://thingsthatshouldbeeasy.blogspot.com/2009/10/impersonation-options-in-sharepoint.html .

 

SharePoint 2010 would have OOTB impersonating steps for declarative workflows. For detail, please refer to http://technet.microsoft.com/en-us/library/ee428324(office.14).aspx