search

satrun77 / tinyissue

Simple Issue Tracking for Teams
MIT License
48 stars 6 forks source link

Enforce role access and readonly for list and kanban #116

Closed nickbe closed 8 years ago

nickbe commented 8 years ago

If an issues status access role limit forbids it then it shouldn't be able to see the issue in the first place. Neither in the list, nor in the kanban. This way the newly invented ReadOnly tag setting makes most sense then.

satrun77 commented 8 years ago

Can you please provide more details here.

nickbe commented 8 years ago

Sure, let's say an issues status is "BACKLOG" and the BACKLOGs role access limit is "Developer". and the BACKLOGs readonly role is "Developer".

This would mean that the user who created the issue can see it in lists or kanbans but he cannot edit the issue since it's now readonly due to the BACKLOGs readonly role. -> So being the owner overrides the role access limit, but NOT the readonly role.

If the project is PRIVATE then other users cannot see the issue in the lists or kanban at all because they're not the ones who created them.

If the project is PUBLIC then other users should be able to see the issue (issues not created by them) in the list or kanban according to the status access role.

A developer CAN SEE the issue but he cannot edit it because of the readonly role.

satrun77 commented 8 years ago

This is currently working as its described here. The only thing not implemented is the user able to edit the issue created by the user (There is another issue tracker for this).

nickbe commented 8 years ago

Seriously? :) This is how private/public works? I'm on holiday for 3 days now. When I'm back I was told we get the new design samples and I'll have the time to check out the private/public thing.

satrun77 commented 8 years ago

Private projects: User role: cannot see any private projects, unless the user is part of the project team, then this user can add issue and view project issues.

Public projects: User role: can see any of the project issues. Not logged in user: can see any of the project issue.

Your issues view (List and Kanban): User role: see issues the user created. Developer/Manager/Admin: see issues that are assigned to them.

nickbe commented 8 years ago

In a private project normal users should not see issues created by other users. Only the ones they created themselves.

Is this the way it works?

In a private project I don't want a bug reporter (user) see the bugs reported by other users.

satrun77 commented 8 years ago

Users that are not part of the private project don't have access to create issues. The project is private and they are not part of the project team. I cannot see the point of allowing anyone of creating issues to a project they don't have access too.

To private and public projects, you have to be granted an access to the project to be able to create issues.

Public projects means issues and discussing is publicly opened to all users event not registered users.

nickbe commented 8 years ago

So I what I mean is there should be an option to have a "closed" private project. So when one user reports an issue, others are not allowed to see this. Basically every user should see only his/her only issues. (But you already asked the right question on gitter the other day)

nickbe commented 8 years ago

I'll close this issue too. Moving to the user role discussion #133 issue now.