Project and Portfolio Management Practitioners Forum
cancel

PRJ in Workflow Step Security

SOLVED
Go to solution
Highlighted
Jamie Pick
Super Contributor.

PRJ in Workflow Step Security

I'm trying to use Workflow step security to limit who can see the buttons in a Project Issue step - more specifically, only the Program Manager(s) of the Associated Project on the Issue.

I've tried [PRJ="[REQ.P.KNTA_MASTER_PROJ_REF]".PROJECT_STAKEHOLDER] but with no luck. Any other thoughts?

Thanks!

Jamie
10 REPLIES
Erik Cole
Acclaimed Contributor.
Solution

Re: PRJ in Workflow Step Security

Jamie, that looks like a valid token. What does "with no luck" mean? You added that token to the WFS and a stakeholder can't see the buttons? Did you also give that token "edit" rights on the request type?
Jamie Pick
Super Contributor.

Re: PRJ in Workflow Step Security

Thanks for the response.

In testing this change, I assigned myself as the Project Manager on the Associated Project for a given Project Issue. More specifically, I should see buttons to Reassign, Close, or Escalate the Issue, but the buttons are not visible, indicating to me that my token in the Workflow Security tab for that step is not working correctly.

I did not try adding that token on the Request Type security - I'll try that as well.

Thanks!

Jamie
Jamie Pick
Super Contributor.

Re: PRJ in Workflow Step Security

The Request Type has Workflow Security enabled to Edit, so it should be inheriting it from what's setup in Workflow security.
Jamie Pick
Super Contributor.

Re: PRJ in Workflow Step Security

Oh, and the token I'm using is close to the one I specified in my original post, it's actually [PRJ="[REQ.P.KNTA_MASTER_PROJ_REF]".PROJECT_MANAGER].
Erik Cole
Acclaimed Contributor.

Re: PRJ in Workflow Step Security

Do you have the token in your WFS set to User-Defined Token of type UserID?
Jamie Pick
Super Contributor.

Re: PRJ in Workflow Step Security

Yes...

The only other thing that's suspicious is that the Associated Project on the request is using a custom validation. The validation returns ProjectId (hidden), ProjectName (displayed), and ProjectId (displayed).

Maybe this is the culprit?

It appears to be modeled after the standard "PMO - Master Projects" validation. The Associated Project field is using the KNTA_MASTER_PROJ_REF token.

Thanks.
Michael.Ebert
Super Contributor.

Re: PRJ in Workflow Step Security

Hi Jamie,

you told you changed the field in project request and use the token in the project issue workflow.
What does the approval details of the project issue say. If it shows your name, the token ist fine, otherwise ...
But the token security is not that dynamic. It's calculated and stored in database on save. So if you changed the stakeholder and didn't save the project issue again, the approval details will show the right user although you won't have permission.

Kind regards,
Michael
Jamie Pick
Super Contributor.

Re: PRJ in Workflow Step Security

Micheal hit it right on the head... I was updating the Associated Project, returing to the Issue but had not actually saved the Issue. In doing this, it works as expected with the above token.

Thanks to the both of you for your help.
TurboPask
Regular Contributor.

Re: PRJ in Workflow Step Security

Hi Jamie et al.

I have run into the same problem (I think) but I don't quite understand what you did to resolve.

I a newbie and perhaps going about it the wrong way but would appreciate if you could take me through it.

In my workflow step under security I create a new user defined token of type User ID. Then do I enter the token value exactly as:
"[PRJ="[REQ.P.KNTA_MASTER_PROJ_REF]".PROJECT_MANAGER]" ?

Then what do I need to do to apply this security change?

Thanks in advance for your help.
Jamie Pick
Super Contributor.

Re: PRJ in Workflow Step Security

The token that works looks like this...

[PRJ="[REQ.P.KNTA_MASTER_PROJ_REF]".PROJECT_MANAGER]

On the security screen, you'd select User Defined Token, the above token, and the type is User Id.

Thanks,

Jamie