Project Roles for better permissions and workflow permissions

Dana Frost
edited August 2016 in
Permissions and Workflow permissions are now by defined groups.  But each project has different people in different roles. To be able to better manage permissions, it would be great if you could define project roles.

This could be used to restrict workflow transitions to only those users who should be making those transitions. It could also be used to better manage project permissions where different people have different roles per project. 

Comments

  • Kristina King
    edited June 2016
    Thanks for posting, Dana. Have you created a workflow that utilizes transition permissions for a specific project group? Given that users can belong to more than one group, it seems a really specific group, like "Project X Test Engineers" should work to restrict transitions only to people in particular roles in particular projects. Or is there something else you're trying to achieve with this? (Or are you running into some permissions entanglements?)
  • Dana Frost
    edited September 2015
    Yes, I can create a workflow that uses group permission for transitions.  Let me give you an example why that does not meet the need.

    We want to use a simple New->In Review -> Committed Status field and we want to use the same field and workflow for all projects.

    We want only certain users  to be able to "commit" to things for each project. If we create a group called "committers", those user will be able to "Commit" for all projects but we only want them to be able to "commit" for the projects they lead/manage.

    Since the "Workflows" in JAMA appear to be "Global" and not project specific, anyone in that group could "Commit" in any project. That defeats the purpose of having specific roles for a project. We don't want manager_B to commit to items in project_A.  We want manager_B to commit to items in project_B.  

    Even if each project could follow different workflow rules (I don't think they can) you would need to create/admin a different workflow for each project to have different permission and that would be harder to manage.

    This is why project roles would be an improvement over simple group permissions.  This is very similar to  the need for custom fields that are  "Pick Lists Per Project".  Per-project differences are common and help manage projects with more precision.
  • Kristina King
    edited June 2016
    Because it is possible to allow project managers to override workflows on their particular projects, have you tried it for this scenario? (I understand that this is harder in practice than in theory!)

    The steps would be:
    1. Create a workflow in Org Admin
    2. Assign the "Commit" field to a limited group (say, org admin)
    3. In Project> Configure Project > Groups, Add Group for that particular project with those particular committers.
    4. In Project> Configure Project > Workflow, choose Override and update the Transition Permissions to that particular limited "Committers" project group.

    Would this work for you? I understand the desire for more granularity in all aspects of Admin (especially permissions), but it seems like this is a particular quandary we can find a workaround for.
  • Dana Frost
    edited September 2015
    I see.  I will try that. That may be a good work-around. I did not realize from your earlier post that you could specifically override the transition permission rules. That makes sense now.  

    Thanks.
  • Kristina King
    edited June 2016
    Great. Let me know if it works!
  • Dana Frost
    edited September 2015
    That did work. Thanks. Though I still like the idea of project roles, at least this will allow us to customize a common workflow when needed. 
  • Kristina King
    edited June 2016
    FWIW, I like the idea of project roles too and think it remains a good "Idea". I'm glad we could figure out something for the workflow, though.