View Issue Details

IDProjectCategoryView StatusLast Update
0008900mantisbtemailpublic2009-05-19 19:47
Reportersmig1o Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
Status acknowledgedResolutionopen 
PlatformLAPPOSLinuxOS Version2.6.24
Product Version1.1.1 
Summary0008900: Problems with project_get_all_user_rows - not all users are processed
Description

project_get_all_user_rows gives list of all users with level equal to or higher than given that eather members of project with given level or NOT in the project at all.

Steps To Reproduce

Put users into mantis with global level:
A - manager
B - manager
C - manager
D - manager

X - developer
Y - developer
Z - developer

Create project and put users with level
A - manager
B - reporter
X - developer
Y - developer
Z - developer

now call project_get_all_user_rows( project_id, MANAGER )
According to function 1st you select all users with global MANAGER level:

SELECT id, username, realname, access_level
FROM mantis_user_table WHERE enabled = 1 AND access_level >= MANAGER

and put results into $t_users array

then you search all users assigned to the project:

SELECT u.id, u.username, u.realname, l.access_level
FROM mantis_project_user_list_table l, mantis_user_table u
WHERE l.user_id = u.id
AND u.enabled = 1 AND l.project_id = 5

then you unsetting from t_users elements that didnt meet criteria on 2nd list.

Global Users:

A - manager
B - manager
C - manager
D - manager

Local Users:
A - manager
B - reporter
X - developer
Y - developer
Z - developer

On both lists there is A and B user so X,Y,Z wont appear on output.
A on both lists meets MANAGER level so it will stay on output list.
B is REPORTER on 2nd list and will be unset.
C and D wont be checked and they will appear on output list.
As a result I'll get list of all users with MANAGER level that are eather MANAGER on project or not in the project at all.

Is that correct??

TagsNo tags attached.

Activities

smig1o

smig1o

2008-02-16 18:05

reporter   ~0017076

Seems a new array instead of unsetting values on old one is good solution for that.

thraxisp

thraxisp

2008-02-16 20:36

reporter   ~0017083

I believe that this is correct. For public projects, the global settings will also apply. For private projects, only the users listed in the project will be used.

The best way to use this is to give users the minimum permissions globally, then upgrade permissions on a project basis.

smig1o

smig1o

2008-02-17 04:53

reporter   ~0017088

Ok.. I see.
But this function is used in >email_collect_recipients< (thats why I put it in email category ;). As a result mantis will send an e-mail to project manager (A) but also to people that arent involved in the project (C and D).
And this isnt correct IMHO.