View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0030906 | mantisbt | administration | public | 2022-08-20 06:57 | 2022-08-23 01:37 |
Reporter | AdilOzatay | Assigned To | |||
Priority | high | Severity | tweak | Reproducibility | N/A |
Status | new | Resolution | open | ||
Product Version | 2.25.5 | ||||
Summary | 0030906: Give view access to an issue after any relation. | ||||
Description | Hello, In my Mantis configuration, every user can see their own issue. They can either see the issues they submitted or the ones who are assigned to them. The feature that I want is a user to see an issue even if they didnt submit or not currently assigned to them if that user had any relation with the issue before. Please let me know about how to achieve this goal. I dont wanna use the monitor feature I want this to happen automatically. Thank you. | ||||
Tags | No tags attached. | ||||
related to | 0005702 | acknowledged | Giving access to private issues to users who are monitoring them |
I am not sure if this is a good idea in general. |
|
@AdilOzatay I think that such an implementation should not become part of standard MantisBT as it would introduce a security issue. |
|
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. Thanks |
|
Maybe I don't understand your use case, but wouldn't the following setting work for you? |
|
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.
And what I need is one more element to this list,
Thanks. |
|
If you have installed an original version 2.25.5, then you have this option on page Manage > Manage Configuration > Workflow Thresholds The settings in my screenshot would allow DEVELOPER. MANAGER, ADMINISTRATOR to view all issues of a project. Isn't this what is needed? |
|
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. 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. |
|
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:
Why shouldn't user B allowed to see all issues of the project?
Thanks... |
|
@dregad @vboctor I would like to get your opinion on this The implementation should be trivial, but the cons are
|
|
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.. |
|
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. |
|
You can write a plugin that uses https://www.mantisbt.org/docs/master/en-US/Developers_Guide/html-desktop/#dev.plugins.building A lot of examples can be found at https://github.com/mantisbt-plugins |
|
+1 for not adding a 4th rule.
Hence, auto-addition to monitor list is the way to go. We already have a similar case in I don't think adding to monitor list as part of adding a note is necessary for this scenario. |
|