View Issue Details

IDProjectCategoryView StatusLast Update
0026699mantisbtadministrationpublic2020-05-25 14:03
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 closedatrol 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

polzin

polzin

2020-03-05 08:44

reporter   ~0063733

@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?

ciwu

ciwu

2020-05-22 07:36

reporter   ~0064018

Last edited: 2020-05-25 14:03

View 2 revisions

@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.

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
2020-03-05 08:44 polzin Note Added: 0063733
2020-05-22 07:36 ciwu Note Added: 0064018
2020-05-25 14:03 ciwu Note Edited: 0064018 View Revisions