View Issue Details

WikiJump to Notes
IDProjectCategoryView StatusDate SubmittedLast Update
0016182mantisbtemailpublic2013-07-16 01:192014-01-09 13:05
Reporterkaese Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status confirmedResolutionreopened 
Product Version1.2.15 
Summary0016182: User specific settings not taken into account when emails are send
Description

Viewing an issue via webinterface: The history is missing from the issue (as configured).

If UserX get an issue assigned to him the email being send shows the issues history which should not be shown according to our configuration.

Steps To Reproduce

userX is a DEVELOPER in ProjectY.

The project is configured with:

config_defaults_inc.php: $g_view_history_threshold = VIEWER; (default)

Database configuration:

UserX ProjectY view_history_threshold integer 70 (MANAGER)

Can be reproduced in our environment.

Additional Information

Adding some debug output to core/email_api.php around line 1447:

1447 # put history data
1448 log_event( LOG_EMAIL, "view_history_threshold for user $p_user_id: ".config_get( 'view_history_threshold' ) );

Result:

  • view_history_threshold for user 103: 10 (this is the default value from config_defaults_inc.php) and not the user specific value which should be 70.
Tagspatch
Attached Files
get_correct_user_setting_for_mail_history.diff (724 bytes)    
--- ../../../source/mantisbt-1.2.15/core/email_api.php	2013-04-12 15:37:02.000000000 +0200
+++ email_api.php	2013-07-16 15:33:15.000000000 +0200
@@ -1444,7 +1444,7 @@
 	$t_bug_data['bugnotes'] = bugnote_get_all_visible_bugnotes( $p_bug_id, $t_user_bugnote_order, $t_user_bugnote_limit, $p_user_id );
 
 	# put history data
-	if(( ON == config_get( 'history_default_visible' ) ) && access_compare_level( $t_user_access_level, config_get( 'view_history_threshold' ) ) ) {
+	if(( ON == config_get( 'history_default_visible' ) ) && access_compare_level( $t_user_access_level, config_get( 'view_history_threshold', null, $p_user_id ) ) ) {
 		$t_bug_data['history'] = history_get_raw_events_array( $p_bug_id, $p_user_id );
 	}
get_correct_user_setting_for_mail_history.diff (724 bytes)   

Activities

atrol

atrol

2013-07-16 04:26

developer   ~0037473

Using access_has_bug_level instead of access_compare_level in function email_build_visible_bug_data should fix the issue.

Sorry, no time to test and fix it at the moment.

There is also some kind of conceptual issue.
Settings of thresholds for individual users can't be managed using page Manage > Manage Configuration > Workflow thresholds
kaese

kaese

2013-07-16 06:55

reporter   ~0037474

Setting threshold for individual users seems to work, at least when using the webinterface.

I didn't succeed with your suggestion, but succeeded with the following change:

email_build_visible_bug_data(): changing the config_get( 'view_history_threshold') to config_get( 'view_history_threshold' , null, $p_user_id). This way config_get return the correct per user and per project setting for view_history_threshold. Simple config_get('view_history_threshold') would return the configured setting for the user who initiated the email (usually not the user who gets this email).
dregad

dregad

2013-07-16 07:15

developer   ~0037475

@kaese I think yours is the correct solution but can't test at the moment
kaese

kaese

2013-07-16 09:40

reporter   ~0037477

thanks; patch attached (applies to 1.2.15)
atrol

atrol

2013-07-16 11:04

developer   ~0037478

I recommended at 0016182:0037473 to use access_has_bug_level because access to sponsorship information in the same function is checked with it.

Maybe access_compare_level is also enough for sponsorship checking, maybe access_compare_level is not restrictive enough for history checking.

access_compare_level is faster than access_has_bug_level but not that restrictive in terms of private isues and limit_reporters setting.

We should have a deeper look at it before commiting changes.
dregad

dregad

2014-01-09 13:05

developer   ~0039006

Reopening, as the issue was accidentally set to resolved due to a typo in the commit message to fix 0016812.