Taiga Roles/Permissions Issue with Viewing

[ric...@gmail.com]

Hello All,

I'm interested in understanding roles/permissions in a project, and I've run into a curious state.

As an exercise to become familiar with the definitions of each permission type (view, add, modify, delete), I decided that a UX role would have zero access rights. That is, for each category (sprints, user stories, tasks, issues, and wiki), I disabled all permission types. As I understand the current design, this should mean that members of UX role would not be able to view, add, modify or delete in each of the categories.

However, this appears to not be the case. It appears that--at minimum--a role will always allow for viewing within the interface.

Is this correct behavior? 

I do note that for the External role, it's not possible to disable the "view" permission type, so I wonder how (or why) it's permissible to do so for a non-External role.

Related to this, it seems that the add, modify and delete permission types would require the enabling  of the view permission type (e.g,. how can I modify a US if I can't first see it?), so the appearance and function of the UI should suggest this (apparent) dependency. 

Thanks much, and keep up the great work!

BTW, I running latest frontend/backend on stable branch on a local dev server.

Rich

[Alejandro Alonso]

Hello Richt!,

Hello All,

I'm interested in understanding roles/permissions in a project, and I've run into a curious state.

I'll try to help :)

 

As an exercise to become familiar with the definitions of each permission type (view, add, modify, delete), I decided that a UX role would have zero access rights. That is, for each category (sprints, user stories, tasks, issues, and wiki), I disabled all permission types. As I understand the current design, this should mean that members of UX role would not be able to view, add, modify or delete in each of the categories.

Yes, that's what it means 

 

However, this appears to not be the case. It appears that--at minimum--a role will always allow for viewing within the interface.

Is this correct behavior? 

If your project is public it's correct, in that situation all the users will have at least view permission, if your project is private you can customize the view permission too.

 

I do note that for the External role, it's not possible to disable the "view" permission type, so I wonder how (or why) it's permissible to do so for a non-External role.

It sounds like your project is public so all the users (including the external role) will have viewing privileges.

 

Related to this, it seems that the add, modify and delete permission types would require the enabling  of the view permission type (e.g,. how can I modify a US if I can't first see it?), so the appearance and function of the UI should suggest this (apparent) dependency. 

Not exactly, some teams have special roles they are using from the API, for the example to link Taiga with a system generating issues from emails. In that situation you could need a role just with creation permission but with no more.

 

Thanks much, and keep up the great work!

You are welcome!, if you have any more doubts, comments, suggestions, feedback...just let us know please!

 

BTW, I running latest frontend/backend on stable branch on a local dev server.

Rich

Regards!,

 

--

Alejandro Alonso Fernández   CIO & Co-founder alejandr...@kaleidos.net  | Tel: (+34) 627263808 | (+34) 913562995 www.kaleidos.net/FC8EAC/

[ric...@gmail.com]

Alejandro,

Claro! The project (Project Example 0) was indeed a public project. Once I changed it to a private project, it limited viewing as expected.

However, I still have some concerns about permission type dependencies on the "view" type. If I disable view for UX (in my example), and enable the "delete" permission for the various categories (sprints, US, tasks, etc.), the UX role will not have the ability to delete because he/she cannot view that category.

I don't think it is a big operational issue, because trial-and-error will eventually inform the Admin, but I don't believe it to be very clear design. 

Instead, I would recommend the UI reflect this dependency on the "view" type so that it's visually apparent that permission types are subordinate to the view state. I've attached two images of how I think view works:

[Alejandro Alonso]

Thank you very much Rich,

I've just created an enhancement request (https://tree.taiga.io/project/taiga/issue/3974) with your comments, I agree, it can be improved and this part can have a better users experience, we will review it with our UX and design people.

Regards!,

--
Please help us keep the Taiga.io Community open and inclusive, follow our Code of Conduct:
https://github.com/taigaio/code-of-conduct/blob/master/CODE_OF_CONDUCT.md
---
You received this message because you are subscribed to the Google Groups "taigaio" group.
To unsubscribe from this group and stop receiving emails from it, send an email to taigaio+u...@googlegroups.com.
To post to this group, send email to tai...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/taigaio/5d07ad95-60ec-432d-9cb4-232a7c0ff83c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.