Monday, July 4, 2011

Content Server design flaw discovered: "Sometimes it takes a Big Boss to approve a workflow"

Last week I've got an email form a senior developer, forwarded by our client in Europe. The guy that shortly after found a major design flaw in Content Server workflow engine! 

They wanted to have a user's manager approve their content, so they simply added a user information field called Manager:



Sounds like a simple and intuitive solution, right?

Yep. And they've created a token

<$wfAddUser(getUserValue("uManager"), "user")$>

and added this "Manager Approval" step to the workflow.

Now what they found is this: The manager did receive email notification and the were able to see the workflow, but they couldn’t approve or reject!

So he was asking me why....

I told him that only the Big Boss can approve the workflow and if he sets the user's manager value to himself - the guy will be able to approve :) He laughed but did try to prove his point...

And he was shocked to see that....

It worked like magic!

So did we discover a design flaw? A piece of code somewhere in Content Server that let’s you approve the workflow if there's no manager higher then you and you're your own boss?

Uh.. Not really.

You see, what Eric didn’t consider is the fact that the token is re-evaluated every time. When the item goes into the workflow, notification is sent to the manager of the guy who submitted the item. All good! But once the manager arrives to approve the item - the token is evaluated again! Guess why the person with the Manager set to themselves can approve the item?

Solution?

Well, if you're set on having the Manager specified in the User Attribute, write this value to a workflow variable or an extended metadata value and add users to the step based on that. This way you know that the value won't change when approver is there to act on the item.... Or simply have a dropdown of approvers on the check in form (let’s say, you name the filed xWfApprover) and use that content metadata field in your token instead:

<$wfAddUser(xWfApprover, "user")$>

Guess what? Everything's working as designed....

2 comments:

  1. I really like the way you wrote that - I was laughing while reading.

    ReplyDelete
  2. We were too :) Glad you liked the post!

    ReplyDelete