View Issue Details

IDProjectCategoryView StatusLast Update
0005702mantisbtsecuritypublic2017-05-19 03:24
Reporterw_morozAssigned To 
PrioritynormalSeverityfeatureReproducibilityalways
Status acknowledgedResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0005702: Giving access to user who is monitoring bug
Description

Let's say we hve private project. User 1 (REPORTER) has added a private issue. administrator decided to send reminder to User 2 (REPORTER) of issue reported by user1. User 2 is monitoring issue but he do not have access to it.

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

TagsNo tags attached.

Relationships

related to 0007642 new Sending reminder from private issue should grant person rights to view this issue 
related to 0007584 new Add reporter to view private bugs 
has duplicate 0005701 closedvboctor Giving access to user who is monitoring bug 
has duplicate 0004763 closeddregad Allow monitor access to private bug in private project 
has duplicate 0015505 closeddregad 'Monitor'-ing on a private issue is not working 
related to 0015466 new Reporter can't see an issue they have been made a monitor of 

Activities

vboctor

vboctor

2005-06-03 04:42

manager   ~0010340

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.

vboctor

vboctor

2005-06-03 04:45

manager   ~0010341

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.

w_moroz

w_moroz

2005-06-03 05:43

reporter   ~0010343

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.

istvanb

istvanb

2011-02-17 08:00

reporter   ~0028251

Would be a nice to have

jas0n

jas0n

2011-07-15 04:46

reporter   ~0029175

Last edited: 2011-07-15 04:47

View 2 revisions

w_moroz, can you describe changes you did?

toddpw

toddpw

2011-08-11 00:04

reporter   ~0029458

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.)

cwipll

cwipll

2015-07-15 14:52

reporter   ~0051073

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.

0xFF

0xFF

2015-12-03 10:00

reporter   ~0052003

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).

aavagyan

aavagyan

2017-05-19 03:24

reporter   ~0056904

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

Issue History

Date Modified Username Field Change
2005-06-02 08:21 w_moroz New Issue
2005-06-02 09:13 vboctor Relationship added has duplicate 0005701
2005-06-03 04:42 vboctor Note Added: 0010340
2005-06-03 04:42 vboctor Status new => acknowledged
2005-06-03 04:45 vboctor Note Added: 0010341
2005-06-03 05:43 w_moroz Note Added: 0010343
2011-02-17 08:00 istvanb Note Added: 0028251
2011-07-15 04:46 jas0n Note Added: 0029175
2011-07-15 04:47 jas0n Note Edited: 0029175 View Revisions
2011-08-11 00:04 toddpw Note Added: 0029458
2011-08-11 03:38 dregad Relationship added has duplicate 0004763
2013-02-06 10:52 atrol Relationship added related to 0007642
2013-02-06 10:52 atrol Relationship added related to 0007584
2013-02-06 10:54 atrol Relationship added related to 0015466
2013-02-14 15:15 dregad Relationship added has duplicate 0015505
2015-07-15 14:52 cwipll Note Added: 0051073
2015-12-03 10:00 0xFF Note Added: 0052003
2017-05-19 03:24 aavagyan Note Added: 0056904