This can probably be easily implemented by modifying access_has_bug_level() to check if the user is monitoring the issue, the same way it currently checks if the user is the reporter of the issue.

Whether this is to be configurable or not, will need to be decided.

The change I proposed above will only provide the user access to the issue, if he enters Jump to Issue, or clicks on a link in an email. It will not add it to the list of issues the user can see in the View Issues page (i.e. as a result of a query). Changing the filtering to return these issues can be down, but it will slow down the query.

Yes i did it before reporting. At first I modified access_has_bug_level(), but as You noticed the bug is not displayed in my_view_page so i changed query. Thanks for checking out and still I think it would be nice featue to assign rights to certaing bugs.

Would be a nice to have

w_moroz, can you describe changes you did?

You will need to change access_has_bug_level() but that's not the only place. The mass queries for the My View and View Issues pages will probably need to construct different queries to ensure that you don't miss anything.

There are actually three cases I can think of offhand where adding monitors as a way of implementing access control lists could make varying amounts of sense:

1. (your case) User could see bug if it were not private, monitoring bypasses the view status, user has whatever access they would normally have for public bugs in the same project. Most likely we would then want a new config option to determine what access level is required to add such a monitor, unless it is tied to those who can already view or edit view status on private issues.

2. User cannot see bug because it is in a private project. Monitoring would bypass the private project check but then what access level would the user have? Global access might not be sufficient to see the bug, or (if we are abusing Monitors as access control lists) do other operations like handle, etc. Worst case I could see a per-project option that says what access level Monitors grant (a la adding the user to the project at that level).

3. User cannot see bug because "reporters limited to own issues" is preventing them from seeing it. (BTW, why is that not "access required to see public bugs" ? Probably because it was a very specific request originally I guess.) Presumably we just bypass the reporter check and give them their original access level.

There would also be interactions with the reminders feature (which has its own access level options!) but I think the general principle should hold that if you can't already see a bug, you should not be able to Monitor it; but once you can see a bug, it's an open question (and probably yet more configuration options) as to how much additional access you should need to send reminders and add people as Monitors. (On one end of the spectrum, people granted access via Monitoring would be able to add others as Monitors; on the other end, only those with manager access to the bug -- or configurable/administrator! -- would be able to add Monitors that create exceptions to the normal access levels.)

I recently ran into the same requirement and as this ticket has been around since 2005 without a solution I hacked one myself. In case someone needs it here's what I did in mantis 1.2.17:

in core/access_api.php function access_has_bug_level
AFTER:

<<<<<
if( !$t_bug_is_user_reporter && bug_get_field( $p_bug_id, 'view_state' ) == VS_PRIVATE ) {
<<<<<

INSERT:

//check if user is monitor
$t_bug_monitor_table = db_get_table('mantis_bug_monitor_table');
$query = "SELECT 1 FROM $t_bug_monitor_table WHERE bug_id=" . db_param() . " AND user_id = " . db_param();

$result = db_query_bound($query, Array($p_bug_id, $p_user_id));
if (db_num_rows($result)) {
//treat as if bug was public
return access_compare_level($t_access_level, $p_access_level);
}

in core/filter_api.php function filter_get_bug_rows

REPLACE

<<<<<
$t_public_view_state_check = "( ( $t_bug_table.view_state = " . VS_PUBLIC . " ) OR ( $t_bug_table.reporter_id = $t_user_id ) )";
<<<<<

WITH

$t_public_view_state_check = "( ( $t_bug_table.view_state = " . VS_PUBLIC . " ) OR ( $t_bug_table.reporter_id = $t_user_id ) OR (SELECT 1 FROM $t_bug_monitor_table WHERE $t_bug_monitor_table.user_id = $t_user_id AND $t_bug_monitor_table.bug_id = $t_bug_table.id LIMIT 1))";

Using a subquery might not be the most elegant way, but it worked without major code changes. For a release this might also require a configuration switch.

I needed this feature too since I have some reports which must be visible nominatively (addition as monitor being a perfect for this). So, I successfully applied the cwipll's code, above, in a MantiBT 1.2.14.

Just a point to take care of (obvious, but easy to forgot) : $t_access_level must be defined before (ie. above) the inserted code in core/access_api.php's access_has_bug_level function. Otherwise, the bug is well visible in the "View issues" page, but still unreachable (access denied).

Would be nice feature. Can be done as config option - enable or disable this feature to satisfy everyone.

It would be really helpful feature to add reporters and updaters into a private issue.
Right now I couldn't find an option how a reporter (who didn't create an issue) can participate in a discussion inside a private issue.

cwipll, thank you, it works.

I modified your code little bit for mantis 2.9.0.
Patches is downloaded.

diff -ur mantisbt-2.9.0/core/access_api.php mantis-2.9.0-AT/core/access_api.php
--- mantisbt-2.9.0/core/access_api.php	2017-12-04 06:57:48.000000000 +0500
+++ mantis-2.9.0-AT/core/access_api.php	2017-12-20 15:40:36.000000000 +0500
@@ -536,6 +536,18 @@
 	# If the bug is private and the user is not the reporter, then
 	# they must also have higher access than private_bug_threshold
 	if( !$t_bug_is_user_reporter && bug_get_field( $p_bug_id, 'view_state' ) == VS_PRIVATE ) {
+
+		// ====== check if user monitores ===== 
+		$t_bug_monitor_table = db_get_table('mantis_bug_monitor_table');
+		$query = "SELECT 1 FROM $t_bug_monitor_table WHERE bug_id=" . db_param() . " AND user_id = " . db_param();
+
+		$result = db_query_bound($query, Array($p_bug_id, $p_user_id));
+		if (db_num_rows($result)) {
+		//treat as if bug was public
+		return access_compare_level($t_access_level, $p_access_level);
+		}
+		//====== end ======
+
 		$t_private_bug_threshold = config_get( 'private_bug_threshold', null, $p_user_id, $t_project_id );
 		return access_compare_level( $t_access_level, $t_private_bug_threshold )
 			&& access_compare_level( $t_access_level, $p_access_level );

diff -ur mantisbt-2.9.0/core/filter_api.php mantis-2.9.0-AT/core/filter_api.php
--- mantisbt-2.9.0/core/filter_api.php	2017-12-04 06:57:48.000000000 +0500
+++ mantis-2.9.0-AT/core/filter_api.php	2017-12-20 15:41:26.000000000 +0500
@@ -1531,7 +1531,14 @@
 		}
 
 		$t_count_public_only_project_ids = count( $t_public_only_project_ids );
-		$t_public_view_state_check = '( ( {bug}.view_state = ' . VS_PUBLIC . ' ) OR ( {bug}.reporter_id = ' . $t_user_id . ') )';
+// ====== monitored issue view ===== 
+		$t_public_view_state_check = '( 
+			( {bug}.view_state = ' . VS_PUBLIC . ' ) 
+			OR ( {bug}.reporter_id = ' . $t_user_id . ') 
+			OR (SELECT true FROM {bug_monitor} 
+				WHERE {bug_monitor}.user_id = ' . $t_user_id . ' LIMIT 1) 
+		)';
+// ======= end ===========
 		if( $t_count_public_only_project_ids == 1 ) {
 			$t_public_only_query = '( ( {bug}.project_id = ' . $t_public_only_project_ids[0] . ' ) AND ' . $t_public_view_state_check . ')';
 		} else if( $t_count_public_only_project_ids > 1 ) {

I have same problem with my_view page, and I wrote it on issue 25314 ( https://www.mantisbt.org/forums/viewtopic.php?f=3&t=25314&p=64473#p64473 ),
I will be thankful if someone help me.

I'm sorry, there is a mistake in my previous path.
New patch is correct for php 7.0 and mantis 2.9.0

diff -ur mantisbt-2.9.0/core/access_api.php mantis-2.9.0-AT/core/access_api.php
--- mantisbt-2.9.0/core/access_api.php	2017-12-04 06:57:48.000000000 +0500
+++ mantis-2.9.0-AT/core/access_api.php	2017-12-20 15:40:36.000000000 +0500
@@ -536,6 +536,18 @@
 	# If the bug is private and the user is not the reporter, then
 	# they must also have higher access than private_bug_threshold
 	if( !$t_bug_is_user_reporter && bug_get_field( $p_bug_id, 'view_state' ) == VS_PRIVATE ) {
+
+		// ====== check if user monitores ===== 
+		$t_bug_monitor_table = db_get_table('mantis_bug_monitor_table');
+		$query = "SELECT 1 FROM $t_bug_monitor_table WHERE bug_id=" . db_param() . " AND user_id = " . db_param();
+
+		$result = db_query_bound($query, Array($p_bug_id, $p_user_id));
+		if (db_num_rows($result)) {
+		//treat as if bug was public
+		return access_compare_level($t_access_level, $p_access_level);
+		}
+		//====== end ======
+
 		$t_private_bug_threshold = config_get( 'private_bug_threshold', null, $p_user_id, $t_project_id );
 		return access_compare_level( $t_access_level, $t_private_bug_threshold )
 			&& access_compare_level( $t_access_level, $p_access_level );

diff -ur mantisbt-2.9.0/core/filter_api.php mantis-2.9.0-AT/core/filter_api.php
--- mantisbt-2.9.0/core/filter_api.php	2017-12-04 06:57:48.000000000 +0500
+++ mantis-2.9.0-AT/core/filter_api.php	2017-12-20 15:41:26.000000000 +0500
@@ -1531,7 +1531,14 @@
 		}
 
 		$t_count_public_only_project_ids = count( $t_public_only_project_ids );
-		$t_public_view_state_check = '( ( {bug}.view_state = ' . VS_PUBLIC . ' ) OR ( {bug}.reporter_id = ' . $t_user_id . ') )';
+// ====== monitored issue view ===== 
+		$t_public_view_state_check = '( 
+                       ( {bug}.view_state = ' . VS_PUBLIC . ' ) 
+                        OR ( {bug}.reporter_id = ' . $t_user_id . ') 
+                        OR (SELECT true FROM {bug_monitor} 
+                                WHERE {bug_monitor}.user_id = ' . $t_user_id . ' 
+                                AND {bug_monitor}.bug_id = {bug}.id LIMIT 1) 
+                )';
+// ======= end ===========
 		if( $t_count_public_only_project_ids == 1 ) {
 			$t_public_only_query = '( ( {bug}.project_id = ' . $t_public_only_project_ids[0] . ' ) AND ' . $t_public_view_state_check . ')';
 		} else if( $t_count_public_only_project_ids > 1 ) {

Dear all
I had refer 0005702:0059265 (monitoring-2.patch ), and try to do it.

On my test environment
Add new issue #0000045,and add ID:M0503 to monitored this issue.
use ID:M0503 log in,
At 'My View' can't see #0000045
But use link can see it .

On My View-->Monitored by Me How can i set see it
Or am I having a setup error over there?
Thank you.

================================================================
update note 2018-07-19
on the live environment try again monitoring-2.patch, it can work.
live environment version is 2.12.2.
test environment version is 2.14.0 or more high (i forget test version)
so i not sure the cause is version problem or add many plugins
anyway the ver 2.12.2 is can show on 'Monitored by Me',
Thank you.

Hello all,

I have MantisBT Version 2.15.0 and after implementing modification proposed by user: Kabushka, user who is monitoring issue can access post only by using URL link.
Can someone help me with modifying PHP code so that user that is monitoring the issue can see it under "Monitored by Me" (main page) ?

Modification in filter_api.php file, proposed by kabushka and cwipll don't work in latest Mantis version...

Best Regards,
Maciej

Hey,

Has anyone managed to correct the code in the latest version of Mantis?
Modification in filter_api.php file don't work in latest Mantis version :(

Thanks

emet, You can modify core/classes/BugFilterQuery.class.php

Here code,

//# for projects with public visibility, public issues can be shown
if( !empty( $t_public_only_project_ids ) ) {
$t_query_projects_or[] = $this->sql_in( '{bug}.project_id', $t_public_only_project_ids ) .
' AND {bug}.view_state = ' . $this->param( VS_PUBLIC ) .
// ====== check if user monitores =====
' OR EXISTS (Select 1 From {bug_monitor} WHERE {bug_monitor}.bug_id = {bug}.id AND ' .
'{bug_monitor}.user_id = ' . $this->param( $t_user_id ) . ')';
// ====== check if user monitores =====
}

Enjoy!

Hi,

tried kabushka's patches from 2018-03-21 14:45 and ljmaza's BugFilterQuery.class.php patch with 2.16.0, user can't see issue in "monitored by me" and is getting a permission denied even with direct URL (../view.php?id=12345).

Not sure if this is due to the issue being already public, but in a private project.

Hi, is it possible to develop this function in mantis?
This ticket is opened from 20 years, many people need this feature, there are 6 duplicated tickets.
I have realized the "Jump to Issue" said by vboctor in the far 2005, but it's important to realize also the bug visualization in the research page and in the main personal dashboard.
If the problem is that the reasearch could become too slow, this feater should be possible to enable/disable.

I've started working on this bug. Here is a proof of concept patch. It covers the web interface, I have not tried the API or emails yet.

Do you think the subquery used in list views to retrieve bugs the user is monitoring is acceptable performance wise ? Using a JOIN instead would make things significantly more complicated since the query could return multiple rows per bug.

From bec46ca7ac33be9cbba7eaa5e887067cb78377d8 Mon Sep 17 00:00:00 2001
From: halibut <halibut>
Date: Sat, 19 Apr 2025 19:11:58 +0200
Subject: [PATCH 1/2] #5702 - Allow users access to private bugs they are
 monitoring

---
 core/access_api.php | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/core/access_api.php b/core/access_api.php
index cacc1cbd7..553af20b1 100644
--- a/core/access_api.php
+++ b/core/access_api.php
@@ -527,7 +527,8 @@ function access_has_bug_level( $p_access_level, $p_bug_id, $p_user_id = null ) {
 
 	# Check if the bug is private
 	$t_bug_is_user_reporter = bug_is_user_reporter( $p_bug_id, $p_user_id );
-	if( !$t_bug_is_user_reporter && bug_get_field( $p_bug_id, 'view_state' ) == VS_PRIVATE ) {
+  $t_bug_is_user_monitor = user_is_monitoring_bug( $p_user_id, $p_bug_id );
+	if( !$t_bug_is_user_reporter && !$t_bug_is_user_monitor && bug_get_field( $p_bug_id, 'view_state' ) == VS_PRIVATE ) {
 		$t_private_bug_threshold = config_get( 'private_bug_threshold', null, $p_user_id, $t_project_id );
 		if( !access_compare_level( $t_access_level, $t_private_bug_threshold ) ) {
 			return false;
-- 
2.49.0


From c490e4b3f5d2af3a992b6b9d1f81cd4e5d7eaaa1 Mon Sep 17 00:00:00 2001
From: halibut <halibut>
Date: Sat, 19 Apr 2025 19:11:59 +0200
Subject: [PATCH 2/2] #5702 - Allow users to view private bugs they are
 monitoring in lists

---
 core/classes/BugFilterQuery.class.php | 18 ++++++++++--------
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/core/classes/BugFilterQuery.class.php b/core/classes/BugFilterQuery.class.php
index b16b8036f..ac531044e 100644
--- a/core/classes/BugFilterQuery.class.php
+++ b/core/classes/BugFilterQuery.class.php
@@ -552,8 +552,8 @@ class BugFilterQuery extends DbQuery {
 			# this array is populated with projects to search only public issues.
 			$t_public_only_project_ids = array();
 			# this array is populated with projects to search only accesible private
-			# issues by being the reporter of those.
-			$t_private_is_reporter_project_ids = array();
+			# issues by being either monitoring them, or being the reporter.
+			$t_private_is_reporter_or_monitor_project_ids = array();
 
 			# these arrays are populated with projects where the user has limited view,
 			# with 'limit_view_unless_threshold' configuration
@@ -598,7 +598,7 @@ class BugFilterQuery extends DbQuery {
 							$t_limited_public_only_project_ids[] = $t_pid;
 							# private issues can be seen by the reporter, which is also a valid
 							# case for the limited view configuration
-							$t_private_is_reporter_project_ids[] = $t_pid;
+							$t_private_is_reporter_or_monitor_project_ids[] = $t_pid;
 						}
 					}
 				} else {
@@ -607,7 +607,7 @@ class BugFilterQuery extends DbQuery {
 						$t_private_and_public_project_ids[] = $t_pid;
 					} else {
 						$t_public_only_project_ids[] = $t_pid;
-						$t_private_is_reporter_project_ids[] = $t_pid;
+						$t_private_is_reporter_or_monitor_project_ids[] = $t_pid;
 					}
 				}
 			}
@@ -624,11 +624,13 @@ class BugFilterQuery extends DbQuery {
 						. ' AND {bug}.view_state = ' . $this->param( VS_PUBLIC );
 			}
 
-			# for these projects, search private issues where the user is reporter
-			if( !empty( $t_private_is_reporter_project_ids ) ) {
-				$t_query_projects_or[] = $this->sql_in( '{bug}.project_id', $t_private_is_reporter_project_ids )
+			# for these projects, search private issues where the user is reporter or monitoring
+			if( !empty( $t_private_is_reporter_or_monitor_project_ids ) ) {
+				$t_query_projects_or[] = $this->sql_in( '{bug}.project_id', $t_private_is_reporter_or_monitor_project_ids )
 						. ' AND {bug}.view_state <> ' . $this->param( VS_PUBLIC )
-						. ' AND {bug}.reporter_id = ' . $this->param( $t_user_id );
+            . ' AND ({bug}.reporter_id = ' . $this->param( $t_user_id )
+            . ' OR ' . $this->param( $t_user_id )
+            . ' IN ( SELECT user_id FROM {bug_monitor} WHERE bug_id = {bug}.id ) )';
 			}
 
 			# for these projects, search any issue (public or private) valid for the old 'limit_reporters' configuration
-- 
2.49.0

I ran some tests with REST API and this patch also applies to listing / viewing issues.
I was not able to test the issues/:id/files endpoint yet, although I'm guessing it's no different from issues/:id regarding access rights.

Probably it would be slow when there are many bugs to show. The best thing would be if the user can enable or disable the option in the view_all_bug_page.php's filter