Role Based Access Control

As an admin, i should have option to assign rights to what users are allowed to do. Role Based Access Control (RBAC) would bring this application to a level where we can start using it in our team.

Roles should be with group of ACE keeping the usage to a wide area of application. e.g. Customer, Product Owner who can work on project requirements but a Developer/Tester cannot create/change project and requirements.

Status

Issue is closed.

Comments

Tue, May 10, 2011, 11:08 by Witek (SM,T)

Roles are pretty good defined in Scrum. We want Kunagi to be a tool for Scrum and not so much a flexible general purpose project management tool.

What permissions in particular would you like to change?

Thu, May 12, 2011, 08:14 by Jags

Here is what i would like to see. As an admin of Kunagi, one should be able to define roles according to who is signing in at a site.
Example is a scenario where we have various customers and various development teams scattered across the globe. This ACL would allow us to use the tool in such a way that a customer can/cannot see the other project/development team working. Same goes for development team also. Development team can/cannot see other customers besides the one they are working with unless it's explicitly specified.

As a role

1. Product Owner/Customer:
a. Can define Projects and requirements.
b. Cannot see projects defined for other customers unless it's allowed.
c. Can be given watch status for the ongoing activity in Scrum.
2. Scrum Master:
a. Define Iterations, Tasks, Impediments, Risks and other artifacts.
3. Developer/Tester:
a. Cannot define projects and requirements.
b. Can only see/work on projects he is assigned to.

We can define domains where close teams are in a single domain and further each role is associated with a particular type of task he is allowed to do.

Does that clear the air? If not, maybe I'll prepare some detailed chart to explain.

Thu, May 12, 2011, 10:19 by artjom (PO,T)

I am not entirely sure I fully understand what you aim at. We are generally open to implementing features that are requested by users, as long as it fits Kunagi's overall design. I get the feeling, however, that we are not going to implement this due to reasons I will lay down in a moment. I'd appreciate some feedback on whether that is what you propose or not.

Kunagi is designed to support Scrum and Scrum only (not some arbitrary project management concept or some diffuse "agile"). We picked usability and coherence over configurability. Therefore, the Scrum roles are fixed according to Scrum (so in a sense, there is already role-based access control).

Relating to your role proposals in Scrum and Kunagi:

  • A Product Owner is already the only one who can define Stories (requirements); accordingly, Team Members can not create Stories.
  • Users (including Product Owners, Scrum Masters and Team Members) can already see only projects they participate in (i. e. are set to "Participant" status in the project).
  • According to Scrum
    • Scrum Masters do not define Sprints (iterations); Product Owners do.
    • Scrum Masters do not define Tasks nor do they assign them. This is catastrophical misuse of the Scrum practices. The Scrum Team is self-organizing and committed. There is no self-organization or commitment to be found in such practices as being assigned tasks you have never seen before by somebody else.

I'd like to stress that the Scrum Master is not a project manager in a classical sense. He aids the Team and protects it from adverse influence from it's environment. He does not plan anything for the Team and does not interfere with their self-organization.

I hope I was able to communicate Kunagi's design clearly enough to explain why things are the way they are. Chanching that would mean moving away from core design principles and that is why we are not going to do that.

Post a comment



optional
optional