This one was *really* weird stuff.
– There is a SPD-created workflow that creates successive approval tasks, using Collect Data From a User action
– This workflow is hosted on a subsite that has unique security
– After the workflow is created, I add a new user with Full Control permissions over the site, let’s call him johndoe
– Johndoe initiates a workflow, as he wants to try the workflow
– The workflow creates a task for another user, as expected
– Johndoe clicks the task in the task list, it shows the task data, as expected (johndoe has Full Control over the site, right?)
– Johndoe clicks the “Edit Item” to impersonate the user
– “Access denied” message appears!
I wandered why a user who has Full Control rights over the site cannot edit a task. The task itself had inherited permissions from the host site, giving johndoe Full Control over itself. Extensive Googling took me to this MSDN Forum post.
I tried the suggested solution of publishing the site to a local disk. After this, johndoe can edit the task. It smells like a bug inside SharePoint workflow infrastructure.