 |
It seems that the link "Manage" should take the project admins to manage_proj_page.php and global admins should be taken to manage_user_page.php |
 |
This still appears to be a problem in 1.0.6. The user that is denied access when a SPECIFIC project is currently selected (i.e. the project to which they are assigned as "administrator"). A workaround, as mentioned in a Dec 2005 report of this issue, is to select "All Projects" first, then "Manage", and then select the specific project. |
 |
The manage link seems to point to manage_user sometimes, and manage_proj sometimes. The function print_menu in html_api calls access_has_project_level( ADMINISTRATOR ), which when true points it to manage_user. It is returning true inappropriately, though-- my manage users threshold is ADMINISTRATOR. My problem is that for MANAGERs it sometimes points to manage_user... Maybe there should just be additional logic that takes the manage user threshold into account in the manage user threshold? I'll give it a try. |
|
|
Okay, in html_api.php, the logic that decides how to print that link hinges around whether a user has admin priviledges on a project basis-- then prints the manage_user_page.php link if they do. This does not work, though, in cases where the manage_project_threshold is one thing but the manage_user_threshold is another. I changed that logic to check the user privilege level agains the manage_user_threshold-- if it's less, it goes to the next bit of logic that will print the manage_proj_page.php link. I also changed the print_bracket_link to check for privileges that way. Seems to make sense... no? |
 |
Does this fix it? |
- Anonymous
