it was possible to add a user to a private issue to give them access to it

It's now again possible in my WIP PR https://github.com/mantisbt/mantisbt/pull/1953/files

It seems that we need to verify that they have some level of access (view_bug_threshold?) to the project (not the issue) before getting added as a monitor, but not necessarily have access to the issue itself they are being added to

I am checking now for monitor_bug_threshold at project level, so with default settings, a reporter can be added.
The user gets added to the monitoring list, but finally can't access the issue due to missing access rights for private issues.

Need some more time to check how / if it worked in earlier versions.

@vboctor I tried old 2.25.8 (the last released version without my changes around 0029454 in 2.26.0 )
I am able to add a reporter to the monitoring list of a private issue, but the reporter is not able to access the issue (similar to my WIP PR for 2.26.0.

Isn't it better to avoid adding users to the monitoring list, if they don't have access?

@atrol I think the change to verify access to a project rather than an issue is the main bug as suggested in my description and addressed with the fix in the PR.

I didn't work with limited view as much, but if a user is going to be able to access an issue after being added as a monitor, then it should be possible to add them as a monitor to give them such access to this specific issue. If they won't be able to access the issue even after they are added, then it makes sense to block the addition.

Maybe this could be controlled by a config option ?

• ON => monitoring grants access, possible to add someone to an issue they normally don't have access to (private project and/or issue, access restricted via limit_view_unless_threshold)
• OFF => only users having access are allowed to monitor it (current 2.26.0 behavior)

We could also consider additional tuning options, e.g. only allow if user has project-level access, display a warning/confirmation if user will be granted access...

One aspect we must remember is that corner cases that allow the user access to issues complicate our regular filter logic for the View Issues page (and filter_api). Hence, unless we are saying certain issues are only accessible via direct links, we have to be careful with adding such features.

However, there is already some logic that enables access to monitoring users. See access_has_bug_level() and access_has_limited_view().

I would say that the fix that is in the PR already addresses the regression. If I find scenarios that were working before and stopped working, I will update this issue or open a new one.

I just realized as I closed a few issues as duplicate of another, private one, that the reporter of the resolved issue was added to the monitoring list of the duplicate, in spite of 0029454.

See for example 0026434, the history of duplicate 0019381 shows

2024-01-29 01:34    dregad  Relationship replaced   has duplicate 0026434
2024-01-29 01:34    dregad  Issue Monitored: jingshaochen   

Strangely, for another issue #0033443, which already had a duplicate relationship with 0019381, the reporter was not added.
And of course I could not add them manually, so I had to briefly make 0019381 public, add the user and change visibility back to private.

@vboctor @atrol after re-reading this discussion and reviewing related issues and PR https://github.com/mantisbt/mantisbt/pull/1953, I think there is a misunderstanding between you.

In the general usage scenario (i.e. when $g_limit_view_unless_threshold is set to its default value of ANYBODY), monitoring does not grant any visibility to an issue the user does not already have access to; I have tested and confirmed this is true in 2.26.0 as well as in earlier versions. Monitoring users do not get notification emails either.

I believe this is the case that @atrol had in mind.

On the other hand, and this is what was reported by @vboctor here as well as by other people in 0033342, 0033348, if $g_limit_view_unless_threshold is set e.g. to DEVELOPER, any users below that threshold will only see issues they reported or are monitoring - assuming they have access to the project of course.

It is worth mentioning however, that this will not allow access to a private issue, or to issues belonging to a private project the user is not authorized to. This is a wider scenario, that should be tracked as a separate feature request.

Anyway, in this context, we DO have a confirmed regression as it is no longer possible to add users to the monitoring list to grant them visibility on the issue.

Maybe the access check to add a monitor can be smarter and take $g_limit_view_unless_threshold into account ?