Security Keys for Workflow History

22 12 2010

I’ve recently been working on a client site setting up security in Dynamics AX workflow and the question of access to the workflow history form (accessed via yellow workflow bar) as well as the re-assign, resume and cancel buttons on that form was raised. After a few minutes investigation I found them under the SecurityKey BasicMisc.

Remember that turning off access to workflow history via the security key will remove the Workflow History button from Basic -> Enquiries as well as from your Yellow Workflow Bar

Summarised: (Label, Key)
“View History” – > WorkflowViewHistory (key)
“Resume” -> WorkflowStatusResume (key)
“Reassign” -> WorkflowStatusReassignWorkItem (key)





Rollup 6 Workflow fixes

3 12 2010

With the release of Hotfix Rollup 6 for Dynamics AX, it seems like a number of issues relating to workflow have been resolved. Checkout the full list over at the Knowledge Base. The one in particular that I’m quite interested in relates to last weeks post on security issues for workflow.

The work-items that were being created when that issue occured remained in status pending and were not removed from the processing queue. The hotfix (KB971260) makes a change to the SysWorkflowEventDispatcher class to catch the error and stop the workitem from processing. It doesn’t seem like the correct security is being applied as yet.

 





Security issues in assigning workflow items

25 11 2010

Recently I’ve been having some issues regarding security rights in workflow in Dynamics AX 2009. We keep on receiving the following error: Stopped (error): Work item could not be created. Insufficient rights for user [USERID].

After some investigation I found the code being executed that checks security when assigning workitems at SysWorkflowEventDispatcher::completeWorkItem() line 63. There are three checks done. But the two that I was interested in were the checks for 1. Menu Item access to the Workflow Document Menu Item specified on the approval/task AOT element and 2. Document access to the record in question.

I checked and confirmed that the user in question had sufficient rights for the Menu Item and Table, yet the workitem still refused to process, however once I gave the user full rights for the security keys to which the table and menu item belonged the workitem was able to assign correctly. E.g. The user had permissions to read and write to the PurchaseReqTable, but didn’t have full rights to the Security Key VendTables, once full rights were given on the security key all worked fine.

This is just my observation of the security and how it practically works out (see link to official documentation below), unfortunately this is not desirable behavior in workflow, as it reduces the security control available to administrators. I was able to overcome the menuitem issue by creating my own menuitem and assigning it a unique security key. However for the PurchReqTable I decided to leave the security as is because of other implications of changing it. If however you have your own custom table that you are working off, you would be able to assign a unique security key to it.

Happy Daxing.

Microsoft documentation on security in workflow : http://msdn.microsoft.com/en-us/library/cc641033.aspx








Follow

Get every new post delivered to your Inbox.

Join 135 other followers