| 2014-02-25 13:24:20 |
Marcos Lobo |
description |
The list_projects_for_user() function on LDAP assignment backend only search projects with associations across user_id, not across group_ids. This function admits the group_ids parameter, but never is used on the body of the function.
I think is necessary change this function to can search projects with associations across user_id and group_id.
USE CASE:
---------------
Check if user named 'u1' (inside group 'G2') has grants on project named 'p1'. We have this hierarchy:
P1 <- G1 <- G2 <- U1
In this use case, user 'U1' should have grants on project 'P1' because user 'U1' belongs to group 'G2', 'G2' belongs to 'G1' and 'G1' has grants on 'P1'.
What happens to the current code:
----------------------------------------------------
User 'U1' has not grants on project 'P1'. That is because list_projects_for_user() only search associations between user and project directly and not between groups and projects. |
The list_projects_for_user() function on LDAP assignment backend only search projects with associations across user_id, not across group_ids. This function admits the group_ids parameter, but never is used on the body of the function.
I think is necessary change this function to can search projects with associations across user_id and group_id.
USE CASE:
---------------
Check if user named 'u1' (inside group 'G2') has grants on project named 'p1'. We have this hierarchy:
P1 <- G1 <- G2 <- U1
In this use case, user 'U1' should have grants on project 'P1' because user 'U1' belongs to group 'G2', 'G2' belongs to 'G1', and 'G1' has grants on 'P1'.
What happens to the current code:
----------------------------------------------------
User 'U1' has not grants on project 'P1'. That is because list_projects_for_user() only search associations between user and project directly and not between groups and projects. |
|
