Sunday, July 19, 2009

How to: fixing Out of box Approval Workflow issue and solution - Part 1

Hi All,

I came across an interesting behavior of SharePoint out of the box "Approval Workflow".

PROBLEM:
Apparently, when an item is attached to Approval workflow to control content approval for a user with contribute permissions, they can approve their own major version of an item through the approve button in the workflow.

There a no way to configure the workflow so the site members (contribute permission level) can not approve their own major versions of an item. Its really a MAJOR drawback of out of the box Approval Workflow.

For e.g.

>> Create a new team site such as Document Repository
>> Under "People and Group" section, configure site permissions for groups as follows:
i) Document Authors - with Contribute permission.
ii) Approvers - with Approvers permission.
iii) Visitors - with Read-Only permission.


>> Configure Shared Documents Library

Versioning Settings:

Require content approval for submitted items? Yes
Create a version each time you edit a file in this document library? Create major and minor (draft) versions
Who should see draft items in this document library? Only users who can edit items
Require documents to be checked out before they can be edited? Yes

Workflow Settings:

Start this workflow to approve publishing a major version of an item.
Allow this workflow to be manually started by an authenticated user with Edit Items Permissions
After the workflow is completed: Update the approval status (use this workflow to control content approval)

TESTING:

>>Login as Doucment Author
>> upload a new document and check in
publish a major version - Approval workflow will start
Enter the an Approver.
Use Approve/reject from the item drop down - will receive Error Access Denied. EXPECTED BEHAVIOR.
Go to task list and approve task - workflow will be completed and version 1.0 approval status approved. NOT EXPECTED BEHAVIOR.

Therefore, document author who has contributor permissions can approve his own document and its counter-intuitive.


SOLUTION:

Though we should not touch out of the box behavior, but can certainly change TASK list's behavior. Here is easy workaround.

These are the steps: (obviously, a coding effort is required!)

>> You need an event handler which is associated with TASK list.
>> Get the role definition for "Contributor" permission. (i.e. Document Author)
>> Check the role of user. If it’s a Contributor then throw an error. If it’s an approver then don’t take any action.
Here is the code. Though it needs some improvements but it works properly. I have not touched OOTB workflow, just modified its behavior using TASK list.



MY EVENT HANDLER CODE

public override void ItemUpdating(SPItemEventProperties properties)
{
base.ItemUpdating(properties);

this.DisableEventFiring();

using (SPWeb currentTeamSite = properties.OpenWeb())
{
SPListItem currentItem = properties.ListItem;

// A role definition is required to represent a permission level in SharePoint site
SPRoleDefinition roledefinition = currentTeamSite.RoleDefinitions.GetByType(SPRoleType.Contributor);

bool isContributor = currentItem.AllRolesForCurrentUser.Contains(roledefinition);

if (isContributor)
{
properties.Cancel = true;
properties.ErrorMessage = "You dont have access to this operation because of your access rights.";
}
}


this.EnableEventFiring();
}


In the elements.xml, use ListTemplateId=107 which is base list template id. Tt worked perfectly fine for our case.

Hope it will work fine for others too,

Cheers,
--aaroh

No comments:

Low Code Reimagined with AI + Copilot Pitch Deck - Copy Copilot day (Virtual) - 2023

 Hi All,  I presneded a session at Pune UG on Low Code Reimagined with AI + Copilot Pitch Deck.  Video is at this address  https://www.youtu...