View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0005702 | mantisbt | security | public | 2005-06-02 08:21 | 2022-08-22 05:00 |
Reporter | w_moroz | Assigned To | |||
Priority | normal | Severity | feature | Reproducibility | always |
Status | acknowledged | Resolution | open | ||
Summary | 0005702: Giving access to private issues to users who are monitoring them | ||||
Description | Let's say we have a private project. 1.User 1 (REPORTER) has added a private issue.
It would be nice if administrator has an option to allow user2 to view private issue1. | ||||
Additional Information | I changed a lot in my conf files and .php files so please check out on "clean" mantis version | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
has duplicate | 0005701 | closed | vboctor | Giving access to user who is monitoring bug |
has duplicate | 0004763 | closed | dregad | Allow monitor access to private bug in private project |
has duplicate | 0007642 | closed | dregad | Sending reminder from private issue should grant person rights to view this issue |
has duplicate | 0007584 | closed | dregad | Add reporter to view private bugs |
has duplicate | 0015505 | closed | dregad | 'Monitor'-ing on a private issue is not working |
related to | 0015466 | closed | cproensa | Reporter can't see an issue they have been made a monitor of |
related to | 0030906 | new | Give view access to an issue after any relation. |
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:
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 <<<<< INSERT:
$result = db_query_bound($query, Array($p_bug_id, $p_user_id)); in core/filter_api.php function filter_get_bug_rows REPLACE <<<<< WITH
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. |
|
cwipll, thank you, it works. I modified your code little bit for mantis 2.9.0. monitoring.patch (2,179 bytes)
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'm sorry, there is a mistake in my previous path. monitoring-2.patch (2,353 bytes)
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 On my test environment On My View-->Monitored by Me How can i set see it ================================================================ |
|
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. Modification in filter_api.php file, proposed by kabushka and cwipll don't work in latest Mantis version... Best Regards, |
|
Hey, Has anyone managed to correct the code in the latest version of Mantis? Thanks |
|
emet, You can modify core/classes/BugFilterQuery.class.php Here code, //# for projects with public visibility, public issues can be shown 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. |
|