I am not sure if this is a good idea in general.
It can happen that user B was not intentionally assigned.
If the current behavior is changed to the wanted behavior, the user would forever be able to view the issue that was not meant for him.

@AdilOzatay I think that such an implementation should not become part of standard MantisBT as it would introduce a security issue.
If security is not important for you, you would have to change function access_has_bug_level in file access_api.php.

Hey atrol, thanks for the answer. I need this feature. It wont cause any security problem with the way I use Mantis.

I checked the access_api.php but couldnt figure out how exactly I can manage to give access to users had any relation with the issue.
Can you give me more details please on what to add and what to remove.

Thanks

Maybe I don't understand your use case, but wouldn't the following setting work for you?

Workflow Thresholds - MantisBT.png (11,634 bytes)   

Workflow Thresholds - MantisBT.png (11,634 bytes)   

I dont have that option on my Mantis version 2.25.5.

I have the $g_limit_view_unless_threshold config on my config_inc.php and as you know it limits the user to see the issue in following cases.

• They reported the issue,
• It is assigned to them,
• Or they are monitoring the issue.

And what I need is one more element to this list,

• They added a note or it's been assigned to them at least once.

Thanks.

I dont have that option on my Mantis version 2.25.5.

If you have installed an original version 2.25.5, then you have this option on page Manage > Manage Configuration > Workflow Thresholds
Finally it's just the UI representation of the option you mentioned $g_limit_view_unless_threshold

The settings in my screenshot would allow DEVELOPER. MANAGER, ADMINISTRATOR to view all issues of a project.
Any other access role (e.g.  REPORTER) will just be able to see the issues they reported, they are assigned to, or where they are in the monitoring list.

Isn't this what is needed?
E.g. do you want to restrict also DEVELOPER from viewing all issues?
If yes, what's the reason for it?

I dont want a feature related to it. As I mentioned in the issue description, I want a user to always see the issue after it is assigned to the issue at least once.
1) User A opened an issue and Assigned to user B (A and B both see the issue)
2) User B changed the status to "Feedback" and assigned the İssue to user A. (Only A can see the issue)

What I want is in the second phase, B must still see the issue even if it is not assigned to him anymore. Cause he was able to see the issue at least once.

I understand what you want, but I don't understand why you want it.
Why shouldn't user B allowed to see all issues of the project?

User B can already see all issues related to him. I just want him to keep seeing after it is not assigned to him anymore. And the reason why is just to check the current state of the issue. It is like a monitor feature but it must just be automatic. It can be activated after he is assigned to the issue once. I believe the problem can be solved by adding a 4th feature to $g_limit_view_unless_threshold as:

• They added a note or it's been assigned to them at least once.

Why shouldn't user B allowed to see all issues of the project?

• Because its a private project. There are users who are not supposed to see the issue. But when an issue assigned to someone, he must see always until the issue is closed.

Thanks...

@dregad @vboctor I would like to get your opinion on this

The implementation should be trivial, but the cons are

• Security issue, if someone was not intentionally assigned.
  As opposed to monitoring users, you can't remove later.
• Slightly decreased performance, especially on pages like "View Issues", "Changelog", "Roadmap"
  Additional access of the history table is needed.
• Not easy to get an overview who has access to an issue
  At the moment it's easy to understand and visible: The reporter, the handler and the monitoring users (and configured access levels).
  In addition to that, you would have to read the whole history, which might not even be visible depending on configuration.

Actually what I want is giving monitor access to the user Assigned to project automatically. Therefore he would still keep seeing the issue after he is unassigned. And we can remove his monitoring access when we wanted so security issues would be resolved.

Is there a way to automatically give monitoring access to the users we assign to an issue.

Thanks..

@dregad @vboctor I would like to get your opinion on this

In my opinion, we should not implement this as described, as it will permanently give access to an issue in a non-transparent way (as you pointed out, need to carefully review the history to see, AND need to know what to look for) without a possibility to revoke the access later on.

This is a subject I remember discussing many years ago with dhx (or maybe it was grangeway). The general idea was to rely only on the monitoring feature for notifications, instead of current system behavior (assigned / note added / monitoring). That means, automatically add user to monitoring list e.g. when they add a note. This way, someone can selectively stop receiving notifications for specific issues. The same behavior could be applied for assignment as well. The automatic monitoring could be optional (config-driven) or not.

Then, as requested in 0005702, monitoring could also drive visibility.

Is there a way to automatically give monitoring access to the users we assign to an issue.

You can write a plugin that uses EVENT_UPDATE_BUG to find out if the assigned user was changed.
If yes, use function bug_monitor from bug_api.php to add the user to the monitoring list

https://www.mantisbt.org/docs/master/en-US/Developers_Guide/html-desktop/#dev.plugins.building
https://www.mantisbt.org/docs/master/en-US/Developers_Guide/html-desktop/#dev.eventref.bug.action

A lot of examples can be found at https://github.com/mantisbt-plugins
You could start with https://github.com/mantisbt-plugins/Example

+1 for not adding a 4th rule.

1. It should be straight forward to see who has access to an issue.
2. We should keep the serving of accessible issues as simple as possible - or at least not add complexity
3. We should keep the recipients of notifications as simple as possible.
4. It should be possible to remove user's access specially if they didn't add notes - i.e. fix assignment mistakes and remove monitoring.

Hence, auto-addition to monitor list is the way to go. We already have a similar case in reminder_recipients_monitor_bug where we add a user automatically to monitor list when a reminder is sent to them. You can imagine the same for assignment of an issue with a config or it can be done via plugin.

I don't think adding to monitor list as part of adding a note is necessary for this scenario.