View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0015305||mantisbt||security||public||2012-12-19 00:47||2018-01-29 02:39|
|Summary||0015305: Access control for copy, attach tag, add note|
There are currently no configuration options within Configuration > Workflow Thresholds to remove access to "copy", "attach tag" and "add note" functions as there are for "move" and others. This results in the ability to mass copy, add notes and add tags to all issues from the view issue page allowing reporters (in some cases anonymous) to mass copy tickets.
|Tags||No tags attached.|
The 3 functions you mention, are controlled by existing thresholds:
copy = report_bug_threshold (which is possibly too permissive, and furthermore not consistent with the handling of the 'clone' button, see 0011290)
add tag = tag_attach_threshold
add note = add_bugnote_threshold
If I understand you correctly, you would like to have a threshold distinct from the "normal", single bug one, for each of the above-mentioned "mass update" functions.
"mass updates" are also possible by using the SOAP API and by automated HTTP requests.
If "Report an issue" in the workflow configuration panel corresponds to report_bug_threshold, then yes, I am asking for a separately configurable option for copy. I am not at all familiar with the inner workings of Mantis so I'm not 100% certain that's correct. I have found that one can remove the ability to post notes in the panel but it completely removes the ability to add a note over just the multiple option on view issues. I would assume it may be impractical to separate these. I have not found which option would correspond to tags.
We are currently using Mantis with anonymous reporting enabled for various reasons and would like to limit it to only the ability to report and add notes, which doesn't appear to be possible currently.
The potential for SOAP API abuse (it can be hidden or removed) and HTTP attacks (Mantis is one of many available targets) are of limited concern versus a button built into the software itself that can cause issues with only a few clicks. Our end users are much more likely to abuse the button than the API or to launch any kind of automated attack.
Indeed, I don't think it would be a good idea.
I think the best approach would be, as atrol suggested, to have a threshold to control who is allowed to perform mass updates.
However, due to resource constraints in the dev team, please note that it is unlikely that this feature would make it into core any time soon.
You can't find it on the configuration page.
|2012-12-19 00:47||Sercrui||New Issue|
|2012-12-19 07:19||dregad||Note Added: 0034575|
|2012-12-19 07:19||dregad||Status||new => feedback|
|2012-12-19 07:20||dregad||Severity||minor => feature|
|2012-12-19 07:20||dregad||Category||feature => security|
|2012-12-19 07:45||atrol||Note Added: 0034577|
|2012-12-19 21:35||Sercrui||Note Added: 0034587|
|2012-12-19 21:35||Sercrui||Status||feedback => new|
|2012-12-20 03:48||dregad||Note Added: 0034589|
|2012-12-20 03:48||dregad||Assigned To||=> dregad|
|2012-12-20 03:48||dregad||Status||new => acknowledged|
|2012-12-20 03:55||dregad||Assigned To||dregad =>|
|2012-12-20 04:37||atrol||Note Added: 0034591|
|2018-01-29 02:39||atrol||Relationship added||has duplicate 0023905|