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.

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.

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

The reasoning is that developers comments should be private by default, so that it requires a conscious action to publish something externally

Configuring default_bugnote_view_status achieves that. Unchecking the private box is an action when the user wants it to be public instead.
However, that option can't be set for developers only. That would be doable by setting the option to specific users in the configuration table. Or better: have that option available to the user in "my account" preferences.

That a user cannot add notes while status change/edit issue, is a major thing.

"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 default_bugnote_view_status.
If the user meets set_view_status_threshold, and bugnote_user_change_view_state_threshold OR change_view_status_threshold, then the checkbox is editable.
Otherwise, the initial status should be shown, but not editable.

The result would be:
If default_bugnote_view_status is VS_PRIVATE, and the user can't edit the checkbox, the note will be created as private (instead of current behaviour: created as public or failed)

I would like to hear input from other developers.

@cproensa I agree with your assessment in 0026699:0063636

@cproensa, @dregad
From a practical point of view, I have a different opinion.
In our setting, we have internal developers - where the default should be PRIVATE, but for external issue submitters the default should be PUBLIC (because if their notes are set to private, even their colleges can't see their notes).

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.
Not really convincing.

Do you have a better idea?

@cproensa, @dregad

I'm just testing 2.24.1 and merging our changes and I've seen this issue.

I agree with polzin.
Changing should not break the IMHO current useful workflow. If this requires additional options (with weird names), I have no problem with that.

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.
With the option set, the internal user has to actively intervene (tick the checkbox) if the customer should be notified.