I ran into an issue where hyperlinks in workflow task emails where being automatically changed by SharePoint from absolute hyperlinks to relative ones.

Scenario:

1. You create a custom Visual Studio workflow and use the CreateTask activity.
2. You set your SPWorkflowTaskProperties.Description property to some HTML text.
3. In your Description HTML text, you have an html hyperlink <a> tag whose href=”” attribute contains an absolute hyperlink to a resource in the same SharePoint farm (i.e. a list item).
4. Example: “Please review <a href=”http://yourserver/site/lists/yourlist/dispform.aspx?ID=1”>contract #12345</a>”.

Goal:

Users will receive the task email, and be able to click on the absolute URL in the email body to navigate to the SharePoint resource.

Problem:

It appears that SharePoint parses this HTML and readjusts the hyperlink and makes it relative.

Example: “Please review <a href=”/lists/yourlist/dispform.aspx?ID=1”>contract #12345</a>”

This effectively breaks the hyperlink in the email client.

The only workaround was to get rid of the <a> tag and write out the hyperlink in full. For example:

“Please review contract #12345 (http://yourserver/site/lists/yourlist/dispform.aspx?ID=1)”.

In this manner, SharePoint did not adjust the hyperlink at all.

Tags: SharePoint, task, workflow

This is an old one, but some co-workers ran into this again recently on a project.

When you have a SharePoint workflow that assigns tasks (either Designer or Visual Studio workflow), when you change the Assigned To column on the task list to allow Multiple Selections, your workflow will hang and become unresponsive when a user edits the task. You’ll receive a message about the task being locked (“This task is currently locked by a running workflow and cannot be edited”). OnTaskChanged events will no longer fire and your workflow will be stuck and unrecoverable.

There is no hotfix or workaround for this, so you simply cannot have the assigned to column support multiple users or groups. Just use a single group instead.

Following are some other resources discussing this:

• http://www.eggheadcafe.com/conversation.aspx?messageid=32931131&threadid=32931131
• http://connect.microsoft.com/wf/feedback/ViewFeedback.aspx?FeedbackID=273487
• http://social.technet.microsoft.com/Forums/en-US/sharepointworkflow/thread/8ec834b6-5408-4079-bdfb-b88d341b36bf/

Tags: OnTaskChanged, SharePoint, task, workflow

Recently I saw an access denied error when a user tried to edit a SharePoint Designer workflow task. The error did not occur if the user was a site collection administrator, but did occur even if they had full control to the site, list, and task list.

Running through the Request Access pages, it appeared that SharePoint did not think the user had rights to the task list, even though they did after thoroughly checking permissions.

I figured that it was having trouble with permissions to the ASPX pages from the Designer-generated tasks forms, so I solved it by doing the following:

• Open the site in SharePoint designer
• Locate the “Workflows” node in the tree view.
• Right-click “Workflows” and select Properties.
• Click the Security tab.
• Choose the option to manage permissions from the browser.

It turns out that this “Workflows” node is actually a SharePoint folder object, and it turned out that this folder did not inherit permissions from the parent. The web page for managing permissions that came up showed me this, and enabled me to reinherit permissions and fix the problem.

I’m not sure why that folder didn’t inherit permissions though, I’d never seen that before.

Tags: Access denied, SharePoint, task form, workflow