View Issue Details

IDProjectCategoryView StatusLast Update
0026699mantisbtadministrationpublic2020-02-17 04:02
Reportercproensa Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
Status newResolutionopen 
Product Version2.24.0 
Summary0026699: Inconsistent options for setting public/private status
Description

The definition for set_view_status_threshold, according to documentation:

threshold to set an issue to Private/Public

or config_defaults_inc:

Threshold needed to set the view status while reporting a bug or a bug note.

As an example scenario:

$g_default_bugnote_view_status = VS_PRIVATE;
$g_default_bug_view_status = VS_PRIVATE;
$g_set_view_status_threshold = MANAGER;

With a user having DEVELOPER access level:

  • Creating a new issue, the issue is created as private
  • Adding a note, from issue view page: the note form is rendered as private (yellow background), but after submitting the note is created as public
  • Adding a note, from group action page: the note form is rendered as private, but after submitting the note is created as public
  • Adding a note, from status change page: the note form is rendered as private (yellow background), but after submitting there's an error "access denied"
  • Adding a note, from issue edit page: (same results as status change page)

Additionally, there are other related options:

$g_change_view_status_threshold
Threshold needed to update the view status while updating a bug or a bug note

$g_bugnote_user_change_view_state_threshold
Threshold at which a user can change the view state of his/her own bugnotes

Wich can be confusing when putting them all together.

TagsNo tags attached.

Relationships

related to 0026627 new Add files with option "default_bugnote_view_status" set to VS_PRIVATE 

Activities

polzin

polzin

2020-02-11 18:43

reporter   ~0063620

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.

cproensa

cproensa

2020-02-14 12:10

developer   ~0063634

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.

cproensa

cproensa

2020-02-14 12:18

developer   ~0063636

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.

dregad

dregad

2020-02-17 04:02

developer   ~0063641

@cproensa I agree with your assessment in 0026699:0063636

Issue History

Date Modified Username Field Change
2020-02-11 17:46 cproensa New Issue
2020-02-11 17:47 cproensa Description Updated View Revisions
2020-02-11 17:48 cproensa Relationship added related to 0026627
2020-02-11 18:43 polzin Note Added: 0063620
2020-02-14 12:10 cproensa Note Added: 0063634
2020-02-14 12:18 cproensa Note Added: 0063636
2020-02-17 04:02 dregad Note Added: 0063641