View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0026993 | mantisbt | security | public | 2020-05-28 15:50 | 2020-11-25 15:28 |
Reporter | polzin | Assigned To | dregad | ||
Priority | high | Severity | major | Reproducibility | have not tried |
Status | feedback | Resolution | reopened | ||
Product Version | 2.24.1 | ||||
Summary | 0026993: bug_reminder_page inappropriately shows wrong view_status in some configurations | ||||
Description | What I have done:
What expected:
What seen:
This is not really a security risc, but a confusion about security, but only, if reports may send reminders. | ||||
Additional Information | Fix: Change in bug_reminder_page.php
to
| ||||
Tags | No tags attached. | ||||
@polzin, in my opinion the current behavior is correct.
$g_set_view_status_threshold is defined as Threshold needed to set the view status while reporting a bug or a bug note; it does not say anything about (preventing the) ability to view the existence of the view status.
In that case, IMO the "final view status" should be the one defined as default ($g_default_reminder_view_status), not _VSPUBLIC In the scenario you describe where a user is allowed to send reminders but not to set the view status (e.g. Based on the above, I believe this issue should be closed as "no change required". Let me know your thoughts. |
|
Since you did not provide any feedback following my earlier reply, I'm resolving this issue. |
|
I am very sorry for the long delay, @dregad.
Literally, from the definition of the setting, you are right. But the program behaves different in all other cases: If you cannot set the view_status, you cannot see it. This is also a more logical behaviour. Some parts of the program interpret it this way (e.g. when reporting a bug).
Again, literally, from the definition of the setting, $g_set_view_status_threshold you have a good point. Yet, it makes sense to interpret "setting a view status" as the "possibility to set an internal view status". Some parts of the program interpret it this way. I am looking to it from the view of a previously working use case that has proven to be very practical: Reporters are outsiders which should not see private notes. Developers communicate mostly internally and only some notes are set to public. So, even you have a difference between your expectation and the current behaviour. But fixing it your way, would make it worse in my interpretation. :-) Okay, what is the consequence? There is a very strange behaviour in a non standard setting (Mantis shows "private", but the result is "public"). But perhaps it's not relevant enough to change it. |
|