0016625: Allow reporter to close does not seem to work - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update

0016625	mantisbt	bugtracker	public	2013-11-14 23:15	2013-12-10 15:25

Reporter	david_stephensen	Assigned To	dregad
Priority	normal	Severity	major	Reproducibility	always
Status	closed	Resolution	no change required
Product Version	1.2.15

Summary	0016625: Allow reporter to close does not seem to work
Description	We installed 1.1.15 and the users have started complaining that reporters can no longer close issues. Our system has this setting: All Users All Projects allow_reporter_close integer 1 I have always believed that 'allow_reporter_close' meant 'allow the Reporter of an issue to close their own issue after it was resolved by the Developer but not close issues reported by other Reporters' Is this correct? If yes then here was my test: I set a test user to global level Reporter. I used that account to report an issue and got the Developer to Resolve it. I then viewed the issue with the test user account and there was no Close button. This is consistent with the complaints of the users. This test user was previously a Developer before I changed its level for the test. There was a previous resolved test issue assigned to this user. When the test user looked at that issue there was a Close button. The test user could close an issue that they reported and was assigned to them but not an issue that was not assigned to them, according to my test.
Tags	No tags attached.
Attached Files	config_local_no_comments.php (5,688 bytes) <? $g_allow_signup = OFF; $g_max_failed_login_count = 7; $g_from_name = 'Keech Issue Manager'; $g_show_version = ON; $g_window_title = 'Keech Issue Manager'; $g_logo_image = 'images/keech_issue_manager.png'; $g_show_project_menu_bar = OFF; $g_view_issues_page_columns = array ( 'selection', 'edit', 'id', 'bugnotes_count', 'attachment_count', 'category_id', 'status', 'reporter_id', 'due_date', 'overdue', 'last_updated', 'date_submitted', 'summary' ); $g_print_issues_page_columns = array ( 'id', 'bugnotes_count', 'attachment_count', 'category_id', 'status', 'reporter_id', 'due_date', 'overdue', 'last_updated', 'date_submitted', 'summary' ); $g_csv_columns = array ( 'id', 'bugnotes_count', 'attachment_count', 'category_id', 'status', 'reporter_id', 'due_date', 'overdue', 'last_updated', 'date_submitted', 'summary' ); $g_excel_columns = array ( 'id', 'bugnotes_count', 'attachment_count', 'category_id', 'status', 'reporter_id', 'due_date', 'overdue', 'last_updated', 'date_submitted', 'summary' ); $g_default_new_account_access_level = DEVELOPER; $g_default_bugnote_order = 'DESC'; $g_reporter_summary_limit = 30; $g_view_summary_threshold = ANYBODY; $g_severity_multipliers = array( MINOR => 8, MAJOR => 8, CRASH => 8, ); $g_resolution_multipliers = array( DUPLICATE => 3, DEFERRED => 1, REFUSED => 1, ); $g_reminder_recipients_monitor_bug = ON; $g_reminder_receive_threshold = ANYBODY; $g_file_upload_max_num = 6; $g_status_enum_workflow = array ( NEW_ => '50:assigned,80:resolved,90:closed', FEEDBACK => '50:assigned,80:resolved,90:closed', ASSIGNED => '80:resolved,90:closed', RESOLVED => '20:feedback,90:closed', CLOSED => '20:feedback', ); $g_preview_image_extensions = array( 'bmp', 'png', 'PNG', 'gif', 'jpg', 'JPG', 'jpeg', 'JPEG' ); $g_inline_file_exts = 'gif,png,PNG,jpg,JPG,jpeg,JPEG,bmp'; $g_allow_delete_own_attachments = ON; $g_bug_report_page_fields = array( 'category_id', 'handler', 'summary', 'description', 'attachments', 'due_date', ); $g_bug_view_page_fields = array ( 'id', 'project', 'category_id', 'date_submitted', 'last_updated', 'reporter', 'handler', 'status', 'resolution', 'summary', 'description', 'additional_info', 'attachments', 'due_date', ); $g_bug_print_page_fields = array ( 'id', 'project', 'category_id', 'date_submitted', 'last_updated', 'reporter', 'handler', 'status', 'resolution', 'summary', 'additional_info', 'description', 'attachments', 'due_date', ); $g_bug_update_page_fields = array ( 'id', 'project', 'category_id', 'date_submitted', 'last_updated', 'reporter', 'handler', 'status', 'resolution', 'summary', 'additional_info', 'description', 'attachments', 'due_date', ); $g_report_bug_threshold = REPORTER; $g_update_bug_threshold = MANAGER; $g_view_handler_threshold = REPORTER; $g_view_history_threshold = REPORTER; $g_bug_reminder_threshold = REPORTER; $g_bug_revision_drop_threshold = NOBODY; $g_update_bugnote_threshold = ADMINISTRATOR; $g_manage_news_threshold = NOBODY; $g_delete_project_threshold = NOBODY; $g_delete_bug_threshold = NOBODY; $g_delete_bugnote_threshold = MANAGER; $g_bugnote_allow_user_edit_delete = ON; $g_move_bug_threshold = MANAGER; $g_set_view_status_threshold = ADMINISTRATOR; $g_change_view_status_threshold = ADMINISTRATOR; $g_show_monitor_list_threshold = REPORTER; $g_view_changelog_threshold = NOBODY; $g_roadmap_view_threshold = NOBODY; $g_reopen_bug_threshold = REPORTER; $g_set_bug_sticky_threshold = NOBODY; $g_set_status_threshold = array( FEEDBACK => REPORTER, ACKNOWLEDGED => NOBODY, CONFIRMED => NOBODY, ASSIGNED => REPORTER, RESOLVED => DEVELOPER, CLOSED => MANAGER, ); $g_allow_reporter_close = ON; $g_allow_reporter_reopen = ON; $g_status_colors = array( 'new' => '#fcbdbd', 'reopened' => '#e3b7eb', 'feedback' => '#e3b7eb', 'acknowledged' => '#ffcd85', 'confirmed' => '#fff494', 'assigned' => '#c2dfff', 'resolved' => '#d2f5b0', 'closed' => '#c9ccc4'); $g_display_bug_padding = 5; $g_display_bugnote_padding = 5; $g_access_levels_enum_string = '25:reporter,55:problem solver,70:manager,90:administrator'; $g_severity_enum_string = '50:no effect now,60:may stop production,70:stops production'; $g_status_enum_string = '10:new,20:reopened,50:assigned,80:resolved,90:closed'; $g_resolution_enum_string = '10:open,20:fixed,30:reopened,60:duplicate,80:deferred,90:rejected'; $g_custom_field_link_threshold = ADMINISTRATOR; $g_main_menu_custom_options = array( array( "Intranet", REPORTER, 'https://apps.keech.com.au/intranet/'), array( "TWWDT", REPORTER, 'http://apps.keech.com.au/twwdt/xManualtoc.htm'), array( "TWWMT", REPORTER, 'http://apps.keech.com.au/intranet/hwmt/ProductSelection.aspx'), array( "Wiki", REPORTER, 'https://apps.keech.com.au/confluence/'), ); $g_my_view_bug_count = 15; $g_my_view_boxes = array ( 'assigned' => '1', 'unassigned' => '4', 'reported' => '2', 'monitored' => '8', 'recent_mod' => '3', 'resolved' => '5', 'feedback' => '7', 'verify' => '0', 'my_comments' => '6' ); $g_recently_visited_count = 10; $g_due_date_update_threshold = REPORTER; $g_due_date_view_threshold = REPORTER; ?> config_local_no_comments.php (5,688 bytes) custom_constants_inc.php (300 bytes) <?PHP /* * We have redefined the level 80 and 90 resolution constants as DEFERRED and REJECTED. * They used to be SUSPENDED and WON'T FIX. * The corresponding texts displayed in user interface * are 'Deferred' and 'Rejected' / define( 'DEFERRED', 80 ); define( 'REJECTED', 90 ); ?> custom_constants_inc.php (300 bytes) custom_strings_inc.php (2,261 bytes) <?PHP / Changes to text in the user interface to convert Mantis Bug Tracker for use with business issues. / / Severity levels We reduced them to 3 in the config files. Nore that the severity level constants for 50, 60, 70 are still MINOR, MAJOR and CRASH throughout the config files, but appear as the strings below in the user interface. We omit FEATURE, TRIVIAL, TEXT, TWEAK, BLOCK. / $s_severity_enum_string = '50:no effect now,60:may stop production,70:stops production'; / Resolutions We reduced them to 6. The first 3 are automatically set according to the status of the issue. The last 3 are different types of 'not fixed' resolution. We have redefined the level 80 and 90 constants as DEFERRED and REJECTED. They used to be SUSPENDED and WON'T FIX. We omit UNABLE TO DUPLICATE, NOT FIXABLE and NOT A BUG. / $s_resolution_enum_string = '10:open,20:fixed,30:reopened,60:duplicate,80:deferred,90:rejected'; / Change 'Feedback' status to 'Reopened' status Note that the status level 20 constant is still FEEDBACK throughout the config files, but appears as 'Reopened' in the user interface. / $s_status_enum_string = '10:new,20:reopened,50:assigned,80:resolved,90:closed'; $s_email_notification_title_for_status_bug_feedback = 'The following issue has been REOPENED.'; $s_email_on_feedback = 'E-mail on Reopened'; $s_feedback_bug_title = 'Reopen Issue'; $s_feedback_bug_button = 'Reopen Issue'; $s_reopened_bug_title = 'Reopen Issue'; $s_reopened_bug_button = 'Reopen Issue'; $s_reopened_button = 'Reopen Issue'; $s_reminder_explain = 'This note will be sent to the recipients listed stating that issue has been reopened.'; $s_my_view_title_feedback = 'Reopened, previously Assigned to me'; / Change 'Developer' to 'Problem Solver' and reduce number of displayed user levels. Note that the role level 55 constant is still DEVELOPER throughout the config files, but appears as 'Problem Solver' in the user interface. */ $s_by_developer = 'By Problem Solver'; $s_developer_by_resolution = 'Problem Solver By Resolution'; $s_developer_stats = 'Problem Solver Stats'; $s_access_levels_enum_string = '25:reporter,55:problem solver,70:manager,90:administrator'; ?> custom_strings_inc.php (2,261 bytes) developer has no control for resolving issue.png (30,037 bytes) developer has no control for resolving issue.png (30,037 bytes) reporter can close resolved issue.png (29,331 bytes) reporter can close resolved issue.png (29,331 bytes) global workflow thresholds.png (100,546 bytes) global workflow thresholds.png (100,546 bytes) transitions.png (47,245 bytes) transitions.png (47,245 bytes)

dregad 2013-11-15 05:08 developer ~0038563 Last edited: 2013-11-15 05:59	'allow_reporter_close' meant 'allow the Reporter of an issue to close their own issue after it was resolved by the Developer but not close issues reported > by other Reporters' Is this correct? Yes I just tested this, but was not able to reproduce. Do you have custom workflow settings ? EDIT: the trick was the downgrade of a developer down to a reporter. I can reproduce it now.

dregad 2013-11-15 10:31 developer ~0038564	Don't know what I did before lunch (maybe I was confused), but I am no longer able to reproduce this. The Close button is consistently displayed whenever the test user (regardless of being a reporter from the start or downgraded from developer) is the reporter of the issue, and for both newly reported or pre-existing issues. Tested both with 1.2.15 and current 1.2.x head (7ab61356)

david_stephensen 2013-11-18 00:59 reporter ~0038575	I have looked at this carefully now. It seems that users with level Manager and Administrator are not affected. The main issue seems to be that Developers have no control for resolving issues We have $g_allow_reporter_close = ON; and after resolution the Reporter has a Close button no matter whether they have a Reporter or Developer global status, so that part is OK. We changed the name of the level 55 'Developer' to 'Problem Solver'. This was done with care and has been working fine for several years. You may find ours a strange configuration, but it is designed for working with business issues not software bugs. So far it has served us well and we are big fans of Mantis. I have attached our local config files and some screen snaps. Hope you can shed some light.

dregad 2013-11-18 04:39 developer ~0038576	Hi David, Renaming the role would have no effect on the functionality, since all the code is based on the access level value (55 in this case). And nothing strange in your config, in fact I think it's great that Mantis is used for other purposes than software development. One key information is missing from your last report. I assume test_user1 = reporter, test_user2 = developer, but in the screenshots, it does not clearly say who you are logged on as. Your config gave me 'Notice: Use of undefined constant REFUSED' - I assume REFUSED = REJECTED. After this, I did the following login as reporter create new issue login as developer/problem solver assign issue to myself ==> It works, I can see the 'change status to: resolved' selection + button (unlike what you describe in your screenshot 'developer has no control for resolving issue.png') Did you check your workflow settings as mentioned in 0016625:0038563 ? Do your 'Problem Solvers' have the rights to reach 'resolved' next status ?

david_stephensen 2013-11-18 06:03 reporter ~0038578 Last edited: 2013-11-18 07:46	Hi dregad The workflow settings for Problem Solvers (Developers) (level 55) are close to default. I've attached a screen shot of our workflow thresholds. Is this what you meant by 'check my workflow as ... in 0016625:0038563'? Yes it should be REJECTED. REFUSED was an old idea. I wonder why it is not giving us an error message about that. That area of the summary has some other gaps too. Must fix, though not much attention is paid to the types of resolution. Just getting throughput of issues is trouble enough! For the test_user1 and test_user2 I ended up setting them both with global status of Problem Solver 55, because that is the reality in the business. We have almost no users who are globally Reporters. The screen shots with test_user1 (the reporter) and test_user2 (the Problem Solver) were identical as uploaded. I then downgraded test_user1 to Reporter, logged in as test_user1 and looked again. The screen was exactly the same again. It's like the Problem Solvers are seeing what Reporters should see. Somehow they are being treated as Reporters. You can see in the workflow thresholds screen snap that the Problem Solvers are set as Handlers. This is the mystery. This has just started happening since 1.2.15. We have used this configuration for over a year. Following your steps I: logged in as myself, Ensured that test_user2 had a level of Problem Solver reopened the issue assigned it to myself. Logged in as test_user2 Assigned the issue to 'myself' (test_user2) Still there was no resolved selection and change status button -- it looked exactly as in the first screen snap. Thanks for your help with this. I really hope we can get to the bottom of it, as it is quite a major disruption for the client. Cheers

dregad 2013-11-18 08:27 developer ~0038580	Is this what you meant by 'check my workflow as ... in 0016625:0038563'? I was actually thinking about the workflow transitions page. This has just started happening since 1.2.15. What version did you upgrade from (trying to assert which code base did not have the issue) Kind of busy now, will try

dregad 2013-11-18 08:59 developer ~0038581	Sorry David but I'm still missing a clear understanding of what the problem is and more specifically how to reproduce it. Can yo uplease provide step-by-step instructions, from scratch (so that I can use these steps from a newly installed Mantis to reproduce), and a description of what you get vs what you expect (or used) to get

david_stephensen 2013-11-18 17:30 reporter ~0038584	We upgraded from 1.2.11 I'm preparing some steps to follow

atrol 2013-11-18 18:02 developer ~0038585	Maybe we can shorten this if you provide the requested "Workflow Transition" page. Especially check the last row for status "closed" in section "Access Levels" at the bottom of the page.

david_stephensen 2013-11-18 18:14 reporter ~0038586	Ha! I think identified the problem and put in a workaround. Had to think what we were doing differently from the rest of the world, since nobody else was having the problem. Answer: not letting Developers update issues. I have temporarily allowed Developers to update issues using the setting update_bug_threshold = 55. Now everything is back to normal. Before this was set to 70. With that setting, in 1.2.11 Developers could change issue status but in 1.2.15 they can not. It could be that Mantis developers did this on purpose because they considered it a bug. For us it was a feature. We still want to allow Developers to change issue status (of course) but not to update the original statement of an issue. Is that possible? Do the Mantis developers regard this change as a bug or a bug fix? Thanks for your help so far. What is our prognosis?

david_stephensen 2013-11-18 18:21 reporter ~0038587	Sorry. Misunderstood the request before. Workflow transitions now uploaded.

atrol 2013-11-18 18:35 developer ~0038588 Last edited: 2013-11-18 18:38	I can't try myself at the moment. I would expect that you have to change from "manager" to "reporter" in row "closed" or change your setting for $g_set_status_threshold in your config file.

david_stephensen 2013-11-18 20:52 reporter ~0038589 Last edited: 2013-11-19 01:22	But we only want Managers to be able to close issues and Reporters to be able to close issues they reported. I misunderstood the request about the Workflow Transitions but that may be irrelevant now that I found out what is happening with our problem. See comment above. ^0038586

atrol 2013-11-19 02:39 developer ~0038590	But we only want Managers to be able to close issues and Reporters to be able to close issues they reported. You are right, I forgot for a moment that we have two kind of reporters. The one user with any access level who reported the issue vs. all users with access level reporter.

dregad 2013-11-19 04:21 developer ~0038591	David With the additional info you provided, I believe the root cause of your problem is the fix for 0015258, released in 1.2.13. It was later discovered that the wrong access threshold had been used in the fix (see 0016376). That second correction [1] is not yet released, I suggest you apply it to your installation; alternatively you may want to deploy a nightly build of 1.2.x branch. [1] https://github.com/mantisbt/mantisbt/commit/e074efded3b60beae84174e6023bde2ed4fdb5a7

david_stephensen 2013-11-19 19:53 reporter ~0038597 Last edited: 2013-11-19 19:53	Hi Dregad Thanks very much for sticking with me through this. I'm very happy to have found the problem. Our in house computer support person applied whatever [1] was (sorry-I am not a developer). I removed the "update_bug_threshold = 50" setting from Configuration Report, reverting back to our setting of 70 in config_inc.php. On looking at an assigned issue using a Developer login, I saw that there was an Edit button but no Resolve control. Unless something was caught up in a cache somewhere, that Edit button should not have been there. Would the nightly build be safe for a production installation?

dregad 2013-11-22 08:16 developer ~0038626	Since I still do not have detailed steps to reproduce the error, I am not able to comment on the fact that you still get the issue with the patch. With regards to running a current nightly build of 1.2 branch in Prod, that should be fairly safe, but I do recommend that you perform adequate testing prior to deploying, to make sure. Should you find issues, feel free to report them here.

david_stephensen 2013-11-22 13:13 reporter ~0038633	Thanks, dregad. I'll return to this issue soon and give you the steps.

dregad 2013-11-27 04:53 developer ~0038645	Resolving this for now, feel free to reopen if you think the issue persists, and provide detailed, steps-by-step instructions to reproduce the problem over a clean MantisBT install.

View Issue Details

Relationships

Activities

related to	0015258	closed	dregad	CVE-2013-1811 Reporter can change issue status to 'new'
related to	0016376	closed	dregad	Not able to change status without having update issue rights