When you changed the access level to configure email, was the setting for "All Projects" or for the specific project. I believe that the latter will do what you are looking for. That is, select the specific project, then update the notification settings to lower the access level.

Thanks, the limitation not to configure email of "All Projects" works:
-> access level to configure email notif. for 'All Projects' = Admin.
-> access level to configure email ntoif. for certain project = Manager
That's ok..

The problem is that a user with global access level < Manager never sees the link 'Email Notification'. If a user changes to a project he has access level = Manager, and then follows the link 'Manage', there appears the link 'Manage Configuration' which must be followed to configure email, but the result of the link is 'access denied'.
I did not found an option to configure access rights to visit the 'Manage Configuration' site.

similar problems occur on custom fields:

in the config_inc.php I set $g_manage_custom_fields_threshold = MANAGER and as a result, if the user switches to a project he is a manager in and clicks on 'Manage', the link 'Manage Custom Fields' appears, but when clicked, there is an 'Access Denied'

The manage configuration pages should be shown if the user meets the view_configuration_threshold (default DEVELOPER). The thresholds to show the controls vs just the settings are done in an individual control basis based on the current project settings.

The Manage custom fields page does mix the project and global settings. It should use the global settings since CFs are global in nature and affect all projects.

the link 'Manage Configuration' is shown when
project-access-level >= view_configuration_threshold (DEVELOPER - default - in my case)
(core/html_api.php, line 642, rc1)

but the linked page adm_permissions_report.php shows itself only if
global-access-level >= view_configuration_threshold
(line 18, rc1)

which does not make sense in my opinion (maybe you now better.. :) )

so i changed adm_permissions_report.php as follows an it works for me:

--- mantis-1.0.0rc1.orig/adm_permissions_report.php 2005-07-26 15:37:54.000000000 +0200
+++ mantis-1.0.0rc1/adm_permissions_report.php 2005-07-26 15:36:54.000000000 +0200
@@ -15,7 +15,7 @@

    require_once( 'core.php' );

• access_ensure_global_level( config_get( 'view_configuration_threshold' ) );

• access_ensure_project_level( config_get( 'view_configuration_threshold' ) );

  $t_core_path = config_get( 'core_path' );

..now a user can view configuration for projects he is manager in, also if global access level is e.g. viewer

what do you think about this patch?

The reports noted in the last message have been fixed.

adm_permissions_report.php ->1.11
core/html_api.php -> 1.181

Does the problem with the email configuration still exist?

in manage_config_email.set.php ~ line 18 (v1.6)

access_ensure_global_level( $t_can_change_level );

must be changed to

access_ensure_project_level( $t_can_change_level );

to be able to edit project specifc email-configs ..

i guess manage_config_workflow_set.php needs to be changed the same way

another problem with access rights:

the page manage_config_work_threshold_page.php works well, but manage_config_workflow_page.php seems to have some errors, propably based on a not so perfect use of var t_can_change_flags.. (?):

the submit button on the page end (in fact the form-tags) depends on $t_can_change_flags which seems to be true only if the user can change workflow settings
so if the user can change treshhold flags on this page, but now workflow settings there is no submit button to update the changes

another bug:

the code generating the combo-box to choose who can alter access-levels for status change at the page end has 2 bugs i guess:

if ( $t_access <= config_get_access( 'set_status_threshold' ) ) { # old
    if ( $t_access >= config_get_access( 'set_status_threshold' ) ) { # new
...
print_enum_string_option_list( 'access_levels', config_get_access( 'status_enum_workflow' ) );  # old
            print_enum_string_option_list( 'access_levels', config_get_access( 'set_status_threshold' ) );  # new
...

}

Fixes submitted to CVS. Thanks for the debugging.

core/html_api.php -> 1.182
manage_config_workflow_set.php -> 1.7
manage_config_workflow_page.php -> 1.14
manage_config_email_set.php -> 1.7

the first bug of note 0011003 still exists (manage_config_workflow_page.php)

situaton:
a user is able to edit configs in section 'THRESHOLDS THAT AFFECT WORKFLOW'
and/or in section 'ACCESS LEVELS' but not in section 'WORKFLOW' -> then there is no submit button on the page. the submit button appears only if the user is able to edit something in section 'WORKFLOW'

the attached file x.diff is a possible patch for manage_config_workflow_page.php (v1.14) to fix bug mentioned in note 0011011

Fixed in CVS. I used a method similar to that used in manage_config_work_thresholds_page.php.

manage_config_workflow_page.php -> 1.15