View Issue Details

IDProjectCategoryView StatusLast Update
0026627mantisbtfeaturepublic2020-03-23 04:59
Reporterciwu Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
Status newResolutionopen 
Product Version2.23.0 
Summary0026627: Add files with option "default_bugnote_view_status" set to VS_PRIVATE
Description

If $g_default_bugnote_view_status is set to VS_PRIVATE the dropzone is set to"display: none".
Click checkbox "bugnote_add_view_status" does not make dropzone visible.

Adding files only possible on issue creation.

Did I miss some setting?

TagsNo tags attached.

Relationships

related to 0026699 new Inconsistent options for setting public/private status 
has duplicate 0026630 closedatrol No file upload possible, if config( 'default_bugnote_view_status' ) is not VS_PUBLIC 
has duplicate 0026805 assignedvboctor Attachments box is invisible when notes are private by default 

Activities

ciwu

ciwu

2020-01-28 03:46

reporter   ~0063523

I think 0026630 is the same.

If private files planned or allowed dropzone should be always visible.
If not, tickiung the checkbox should change visibility of dropzone.

BTW:
Deleting "display:none" in browser devtools (F12) makes uploading files with private notes possible.

ciwu

ciwu

2020-02-05 06:24

reporter   ~0063586

My workaround in "bugnote_add_inc.php":

<pre>
// after
$t_bugnote_private = $t_default_bugnote_view_status == VS_PRIVATE;

// insert
$t_bugnote_private = $t_bugnote_private && access_compare_level( user_get_access_level( auth_get_current_user_id() ), config_get( 'private_bugnote_threshold' ) );

// change
$t_attach_style = ( $t_default_bugnote_view_status != VS_PUBLIC ) ? 'display: none;' : '';

// to
$t_attach_style = '';
</pre>

Result:
Users with rights for private notes can always attach files.

Users with no rights for private notes can now attach files while adding (public) notes.
Side effect: note input background color for those users uses now correct class 'form-control'.

Additional change:
Show attachment list from 0022323 only if user has rights for private notes.

polzin

polzin

2020-02-05 08:09

reporter   ~0063587

Last edited: 2020-02-05 08:10

View 2 revisions

@ciwu I think, you are working in the wrong direction. It is indeed possible to add private attachments.

I think the bug is just a leftover from the previous situation.

Old code:

{{{
$t_attach_style = ( $t_default_bugnote_view_status != VS_PUBLIC ) ? 'display: none;' : '';
?>
<tr id="bugnote-attach-files" style="<?php echo $t_attach_style ?>">
}}}

As the change of the attach_style was removed, it is not possible to do file uploads, if default_bugnote_view_status is not VS_PUBLIC.

The $t_attach_style is not necessary any longer.

{{{
?>
<tr id="bugnote-attach-files">
}}}

ciwu

ciwu

2020-02-06 05:41

reporter   ~0063591

I've added $t_attach_style = '' because I would not change too much. Empty string has same effect as removing the whole att_style thing.

Our actual setting after 0026627:0063586

  • default_bugnote_view_status = VS_PRIVATE
  • external users have no right for private notes, as result can upload only public files
  • internal users have right for private notes, as result can upload private and public files
  • internal users see file list on top of page (private and public files)
  • external users don't see file list on top, only files embedded in public notes

Work's as expected.

Did I miss something?

polzin

polzin

2020-02-10 09:06

reporter   ~0063600

Last edited: 2020-02-11 18:36

View 2 revisions

I've added $t_attach_style = '' because I would not change too much. Empty string has same effect as removing the whole att_style thing.

This leaves an unused variable. I guess, this is not a good style.

But you are right, it needs another fix so that users who are not allowed to set the privacy, create public notes.
My fix would be so change:

  • $t_bugnote_private = $t_default_bugnote_view_status == VS_PRIVATE;
  • $t_bugnote_private = $t_default_bugnote_view_status == VS_PRIVATE && access_has_bug_level( config_get( 'set_view_status_threshold' ), $f_bug_id );

... as the access level has to be checked in relation to the bug / project, not the user.

The attached patch fixes both.

patch.txt (1,355 bytes)   
diff --git a/bugnote_add_inc.php b/bugnote_add_inc.php
index 92715ef..d78c7d2 100644
--- a/bugnote_add_inc.php
+++ b/bugnote_add_inc.php
@@ -93,7 +93,7 @@ require_api( 'lang_api.php' );
 
 <?php
 	$t_default_bugnote_view_status = config_get( 'default_bugnote_view_status' );
-	$t_bugnote_private = $t_default_bugnote_view_status == VS_PRIVATE;
+	$t_bugnote_private = $t_default_bugnote_view_status == VS_PRIVATE &&  access_has_bug_level( config_get( 'set_view_status_threshold' ), $f_bug_id );
 	$t_bugnote_class = $t_bugnote_private ? 'form-control bugnote-private' : 'form-control';
 
 	if( access_has_bug_level( config_get( 'set_view_status_threshold' ), $f_bug_id ) ) {
@@ -111,6 +111,7 @@ require_api( 'lang_api.php' );
 			</tr>
 <?php }?>
 
+
 			<tr>
 				<th class="category" width="15%">
 					<?php echo lang_get( 'bugnote' ) ?>
@@ -146,9 +147,8 @@ require_api( 'lang_api.php' );
 		$t_file_upload_max_num = max( 1, config_get( 'file_upload_max_num' ) );
 		$t_max_file_size = file_get_max_file_size();
 
-		$t_attach_style = ( $t_default_bugnote_view_status != VS_PUBLIC ) ? 'display: none;' : '';
 ?>
-			<tr id="bugnote-attach-files" style="<?php echo $t_attach_style ?>">
+			<tr id="bugnote-attach-files">
 				<th class="category">
 					<?php echo lang_get( $t_file_upload_max_num == 1 ? 'upload_file' : 'upload_files' ) ?>
 					<br />
patch.txt (1,355 bytes)   
polzin

polzin

2020-02-10 09:08

reporter   ~0063601

@ciwu, are you okay with the patch?
@atrol, are you okay with the patch?

cproensa

cproensa

2020-02-10 09:30

developer   ~0063602

@polzip
this is included in PR https://github.com/mantisbt/mantisbt/pull/1606

can you have a look if it's everything is right there?

polzin

polzin

2020-02-10 10:09

reporter   ~0063603

@cproensa, thanks for checking.
No, one of the two issues, $t_bugnote_private = $t_default_bugnote_view_status == VS_PRIVATE; is still present in print_api.php:2269.

cproensa

cproensa

2020-02-10 10:47

developer   ~0063607

No, one of the two issues, $t_bugnote_private = $t_default_bugnote_view_status == VS_PRIVATE; is still present in print_api.php:2269.

Can you explain what is exactly the problem there, so i understand the issue?

polzin

polzin

2020-02-10 12:07

reporter   ~0063609

In the setting as described at 0026627:0063591, the background of a note of someone who is not allowed to add private notes is yellow-private, although it will be a public note.

cproensa

cproensa

2020-02-10 13:09

developer   ~0063611

I'm not familiar with the option set_view_status_threshold, but i'd say that 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.

It's definition is vague.
I'd say that it means the user can't change the public/private status, for bug or notes, not that the user can't create private notes. So if the default status for note is private, the user would still be able to create the note, private, as is.
Probably some code use the other interpretation, where "the user can't create a private note".

I'd like more input on this to see if there are mote to fix.

polzin

polzin

2020-02-11 02:25

reporter   ~0063612

Last edited: 2020-02-11 18:34

View 2 revisions

Yet, it's the current behaviour. If the default is private and a user is not allowed to set view_status, the notes are public. See bugnote_add in core/bugnote_api.php

Check for private bugnotes:
if( $p_private && access_has_bug_level( config_get( 'set_view_status_threshold' ), $p_bug_id, $p_user_id ) ) {
$t_view_state = VS_PRIVATE;
} else {
$t_view_state = VS_PUBLIC;
}

BTW: Where is the syntax for the bugnote markup? How to create such code sections? In older versions of mantis <pre></pre> worked...

cproensa

cproensa

2020-02-11 17:48

developer   ~0063619

Creating a separate topic for the configuration option: 0026699

ciwu

ciwu

2020-02-18 10:40

reporter   ~0063654

@polzin

I've done it via "user_get_access_level" because in our installation all rights (internal vs external users) based on access level.

I'll wait for the next release.
The developers should decide how it will be changed.
If it is less inconsistent it's OK for me.

Issue History

Date Modified Username Field Change
2020-01-27 03:39 ciwu New Issue
2020-01-28 03:46 ciwu Note Added: 0063523
2020-01-28 04:39 dregad Relationship added has duplicate 0026630
2020-02-05 06:24 ciwu Note Added: 0063586
2020-02-05 08:09 polzin Note Added: 0063587
2020-02-05 08:10 polzin Note Edited: 0063587 View Revisions
2020-02-06 05:41 ciwu Note Added: 0063591
2020-02-10 09:06 polzin Note Added: 0063600
2020-02-10 09:06 polzin File Added: patch.txt
2020-02-10 09:08 polzin Note Added: 0063601
2020-02-10 09:30 cproensa Note Added: 0063602
2020-02-10 10:09 polzin Note Added: 0063603
2020-02-10 10:47 cproensa Note Added: 0063607
2020-02-10 12:07 polzin Note Added: 0063609
2020-02-10 13:09 cproensa Note Added: 0063611
2020-02-11 02:25 polzin Note Added: 0063612
2020-02-11 17:48 cproensa Note Added: 0063619
2020-02-11 17:48 cproensa Relationship added related to 0026699
2020-02-11 18:34 polzin Note Edited: 0063612 View Revisions
2020-02-11 18:36 polzin Note Edited: 0063600 View Revisions
2020-02-18 10:40 ciwu Note Added: 0063654
2020-03-23 04:56 atrol Relationship added related to 0026805
2020-03-23 04:59 atrol Relationship replaced has duplicate 0026805