I’ve implemented a workflow using SharePoint Designer in a site which is mainly read-only to "NT_AUTHORITY\Authenticated Users" (i.e. lahat). There is a forms library for an InfoPath form. There is an associated workflow tasks list as well so that when the workflow operates, maaari itong magtalaga ng mga gawain sa mga tao.

I break permission for the forms library and task list so that any authenticated user can create forms and update their assigned tasks.

I test with my low-privileges test account.

Can I fill out and save a form to the library? –> YES

Can I access the task from an email link? –> YES

Can I see an Edit workflow task link –> YES

Can I click on that link? –> NO … Permission Denied.

Why can I see an edit link that denies me permission when I click on it? That’s not how it’s supposed to work…

I go through the security configuration again, very closely. I do it again. I consider deleting this post because I obviously don’t know anything about security.

Sa wakas, I search the Internets. I find this highly unlikely MSDN forum thread: http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=1838253&SiteID=17

The posters appear to be suggesting that the simple act of exporting the workflow to a drive platter will fix a MOSS security issue? I can hardly believe I just typed that. I’m reminded of the South Park episode about the 9/11 conspiracy where Stan is asking our Preznit, "Really?" over and over again.

Kaya, nothing to lose, I fire up SPD, right-click on the workflow and save it to my c:\ drive. That would be the c:\ drive on my laptop. I’m looking over my shoulder the whole time so that no one will ask me, "why are you saving that workflow to your laptop?"

Incredibly, that solves my problem. I can edit the task.

I hereby nominate this to be the Most Bizarre Workflow Workaround of 2007.

</dulo>