0012324: Cannot assign multiple issues with mass manipulation tool - MantisBT - Signup temporarily disabled due to spam

ID	Project	Category	View Status	Date Submitted	Last Update

0012324	mantisbt	administration	public	2010-09-07 17:20	2014-09-23 18:05

Reporter	drumscum	Assigned To	dregad
Priority	normal	Severity	minor	Reproducibility	always
Status	closed	Resolution	fixed
Platform	PC	OS	GNU/Linux	OS Version	Debian 5.0
Product Version	1.2.2
Target Version	1.2.9	Fixed in Version	1.2.9

Summary	0012324: Cannot assign multiple issues with mass manipulation tool
Description	In my Mantis instance I have made it possible to assign issues to users with an access level of 'updater'. This was done by ticking the 'handle an issue' box in the 'updater' column on Manage > Manage Configuration > Workflow Thresholds. I can now use eg. an 'administrator' or 'manager' account, go to the 'view.php' page for a particular issue, select a user with 'updater' access level, and click the 'assign to:' button next to it. This works just fine. However, when I go to view_all_bug_page.php, tick multiple issues in the list, select 'assign' in the drop down menu, click 'ok', and then in the next page select an 'updater' account and click 'assign issues', I get a permissions error (see screenshot). It doesn't matter if the issues are private or public, or if they are from a single or multiple projects.
Steps To Reproduce	Give 'updater' access level 'handle an issue' rights. Log in with an 'administrator' or 'manager' account. Click 'view issues' in navigation bar. Tick some issues. Select 'assign' in pull-down menu and click 'ok' In the resulting screen select a user with 'updater' access rights and click "assign issues'.
Tags	No tags attached.
Attached Files	screencut-1283894004.png (8,529 bytes) screencut-1283894004.png (8,529 bytes)

jreese 2010-09-07 18:44 reporter ~0026614	Just for further info on the problem, the user that you are trying to assign to, do they have updater access as their global permission level, or do they have a lower global level, an updater access for individual projects?

drumscum 2010-09-07 18:47 reporter ~0026615 Last edited: 2010-09-07 18:59	The 'updater' access is set globally. edit Also, assigning to eg. 'developer' works fine with the mass manipulation tool. To me it looks as if the mass manipulation implementation of the 'assign' functionality isn't aware that it is possible to assign issues to 'updater' accounts. FYI I also tried setting the $g_handle_bug_threshold in config_inc.php to 'UPDATER', but that gives the same result.

drumscum 2010-09-07 20:04 reporter ~0026616	Also happens in 1.1.8.

cas 2010-09-08 07:34 reporter ~0026621	If you this over multiple projects and in one of teh projects the role is lower than Updater, this can happen. have seen the same on our installation. I do not believe it has anything to do with changing the treshold from Developer to Updater

drumscum 2010-09-08 12:25 reporter ~0026626	No, it also happens when only selecting just a single issue. Since it is possible to assign that same issue to an updater on the 'view.php' page, this definitely is a bug. Both methods should work. For the record: the fix mentioned in issue 9227 resolves this.

cor3huis 2011-04-18 04:54 reporter ~0028641	Just to make sure everyone encountering the issue also still has the option to temporary fix the issue. This comes from issue issue 9227, but is is not very obvious this info is stored there. I believe the problem is with line 129 in 'bug_actiongroup.php'. if ( access_has_bug_level( $t_threshold , $t_bug_id, $f_assign ) && The $f_assign variable contains the userid of the user the tickets are being assigned to, and should not be used to check if the logged in user has permission to perform the assignment operation. By removing this variable, the assignments operation as expected. By removing the variable the user is determined upstream in access_has_bug_level.

dregad 2011-12-13 19:44 developer ~0030593	The workaround proposed in 0009227 (and reproduced in 0012324:0028641) does not properly address the issue. To properly fix the problem, the target user's access level must be checked against handle_bug_threshold.

grangeway 2013-04-05 17:57 reporter ~0036360	Marking as 'acknowledged' not resolved/closed to track that change gets ported to master-2.0.x branch

MantisBT: master 297c7930 2011-12-13 11:22 dregad Details Diff	Allow mass-assign of issues to Updaters The code handling assignment in bug_actiongroup.php had an incorrect check for the access level of the user the issues are being assigned to. It was checked against $t_threshold, which is the minimum access level required of the current user to perform the action, instead of the access level to be assigned issues to (handle_bug_threshold). This affects MantisBT instances where Updaters (or aother role) is allowed to handle issues (through custom Workflow Thresholds) Fixes 0012324		Affected Issues 0012324
	mod - bug_actiongroup.php		Diff File
MantisBT: master-1.2.x 0f702d58 2011-12-13 11:22 dregad Details Diff	Allow mass-assign of issues to Updaters The code handling assignment in bug_actiongroup.php had an incorrect check for the access level of the user the issues are being assigned to. It was checked against $t_threshold, which is the minimum access level required of the current user to perform the action, instead of the access level to be assigned issues to (handle_bug_threshold). This affects MantisBT instances where Updaters (or aother role) is allowed to handle issues (through custom Workflow Thresholds) Fixes 0012324		Affected Issues 0012324
	mod - bug_actiongroup.php		Diff File