View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0026699||mantisbt||administration||public||2020-02-11 17:46||2020-05-27 04:03|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Summary||0026699: Inconsistent options for setting public/private status|
The definition for
As an example scenario:
$g_default_bugnote_view_status = VS_PRIVATE;
With a user having DEVELOPER access level:
Additionally, there are other related options:
Wich can be confusing when putting them all together.
|Tags||No tags attached.|
Thanks for having a thorough look into that.
I think the desired behaviour should be, that if someone does not have the set_view_status_threshold, the user should not the right to create private notes. I see that this is not what is documented, but it used to be the behaviour, and me and @ciwu use it this way. The reasoning is that developers comments should be private by default, so that it requires a conscious action to publish something externally. The other way around, for the external submitters, the default should be public. Furthermore, the new addition that attachments can be private should not break the existing pre 0.23 which is not really related to the change, right?
And I think it's important to distinguish between minor issues and major issues. That a user, that is not able to change public/private notes, sees the wrong color, is a minor thing, because he sees only one color and is not confused by this. That a user cannot add notes while status change/edit issue, is a major thing.
And there is another aspect that is related: While "send a reminder" you have the same problem.
As far as i can tell, there is not an option that prevent a user to set visibility to private. Those permissions are aimed to changing the visibility, but don't limit whether the target status is public or private
"Adding a note, from status change page" fails with access denied. That fits the major issue criteria, so something should be done at this moment that the related code is being reviewed.
Regarding the note form and the initial private checkbox, i think this is what should be done to normalize the situation:
The form input should be always be visible and populated according to
The result would be:
I would like to hear input from other developers.
I understand your reasoning @cproensa, following the explicit words, the options "set_view_status" should only impact, if the view_status is editable. But practically, the resulting behaviour is not sensible (or can you think of users that should be forced to submit only private bugnotes?) and breaks existing, reasonable behaviour that could not be achieved any longer.
Therefore, I would strongly suggest not to go into that direction.
A compromise could be to add another option with the weird meaning default_bugnote_view_status_if_changing_view_status_is_forbidden.
Do you have a better idea?
I'm just testing 2.24.1 and merging our changes and I've seen this issue.
I agree with polzin.
In our setting only internal users (developer, support, sales ...) can add (and obviously see) private notes.
Forcing new note status to private is very useful, as most communication is internal and with automatic email notification, deleting accidentally public added notes is useless.