Rally Software

  • 1.  Role Managment and Audit Trail of Approvals

    Posted Apr 06, 2018 10:31 AM

    I am in the process of preparing for an audit and I need help understanding how are the roles managed in Rally. 

     

    From what I have gathered from the website, there are two level of access Administrative and User access. For the Administrative (Subscription, Workspace, Project - Admins) would be the people who managed the overall workspace and access to the workspace.  For the User level access (Administrator, Product Owner, Product Manager, Scrum Master, Developer, Tester) are my worker bees and do not have the ability to add/delete/modify users rights. Is it true to say that Project Administrator and Administrator would be the same individual? I would like to know what are some of the best practice in the industry for managing user access. 

     

    Do you need a scrum master and product owner in a project?

     

    As auditor, I would like to know who approved what.  Did product owner change in the project?  Did a developer assume another role in the project.  How can I obtain a report of the actionable steps that were taken in project.  For example, if I select a project for sampling I will need to see who approved the project from User Story to Deployment. 

     

     

    Thank you in advance for your response.



  • 2.  Re: Role Managment and Audit Trail of Approvals

    Posted Apr 06, 2018 02:49 PM

    @tolbert200 To make a change to a work item in Agile Central (portfolio item, story, defect, task, test case, etc.) you need edit access to the AC project the work item is in. Subscription Admins have edit access to everything. Workspace admins have edit access to everything within the workspace they're admin of. Project Admins the same except for the projects they admin. Workspace users have what ever access rights they've been granted on a project by project basis. Regardless, anyone with edit access to the project containing the work item can make changes to the work item.  As to "best practices", you can leverage Notification Rules to inform owners of work items if someone other than themselves makes certain changes to your work item such as moving a story to Accepted, or re-ranking a story (assuming you're the product owner). Another control mechanism is to move work items to a sub-project or different project where only the "anointed few" have edit access and can make any further changes. All changes to work items are captured in revision history including who made the change, when, and what was changed. Revision history would be your audit mechanism.