The comment visibility default selection can be configured?

[Manuel P.]

The comment visibility can be selected when someone creates a new comment. However, the default selection is "All Users". Can it be changed to a specific group/project-role? Maybe on a project basis?

Thank you.

[DanielG · Accepted solution]

You can change default comment visibility doing the next steps:

1.- Go to Administration->Issues->User Interface->Announcement Banner
2.- Put the next script:

<script language="JavaScript">
<!--
jQuery.noConflict();
var defaultRoleName = "role:10001";
var customRoleSelected = false;

function changeCommentLevel()
{
if (customRoleSelected) return;

var commentLevelSelect = jQuery('.security-level select#commentLevel option[value=\'' + defaultRoleName + '\']');
if (commentLevelSelect)
{ var labelText = commentLevelSelect.first().text(); jQuery("select#commentLevel").val(defaultRoleName); jQuery("#commentLevel-multi-select a.drop span.icon").removeClass("icon-unlocked").addClass("icon-locked"); var htmlEscapedLabel = AJS.$("<div/>").text(labelText).html(); jQuery(".security-level span.current-level").html(AJS.format(AJS.params.securityLevelViewableRestrictedTo, htmlEscapedLabel)); }

}

jQuery('#comment').live('focus', changeCommentLevel);
jQuery('#commentLevel-suggestions').live('click', function()
{ customRoleSelected = true; }

);
//-->
</script>

<style>
.alertHeader
{display:none;}

</style>

CAUTION: 'role:10001' must be match with the role that you want to put default. In my case is 10001.

Hope this helps.

Best regards,

Daniel

[Manuel P.]

It works even when you have two different groups of users that need to have different defaults?

For example:

• A group "customers" with default "All users".
• jira-developers and jira-administrator and jira-users with default jira-users

BTW, thank you for your answer.

[DanielG]

I think you're confusing terms.

One concept is a role of project. A Role contain user or group of user. For example in my JIRA configuration I have 2 role: Developers and Clients. 'Developers' contain the group of users of my configuration that are developers of my company and the same by role 'Clients'.

In my JIRA, I put default comment visibility to 'Developers' so ever comment I put in Issue can only view to developers. With this I prevent information leaks that I don't wnat to be seen by my clients.

Do you understand me?

[Thomas PF]

Thanks Daniel!

This works for me!

[Joey McDaniel]

Hi Daniel,

Could this be modified to hide a specific Project Role from showing in the Comment permissions drop down?

I'm trying to hide a specific Project Role from showing in the drop down for comments. Editing the global.vm seems to be the way to go, but I don't understand how to single out that Project Role from showing.

This is the code that controls the drop-down options:

#if ($isRolePresent)
<optgroup label="$i18n.getText('common.words.project.roles')">
#foreach ($level in $roleLevels)
<option value="role:${level.id}" #if($level.id && $selected == "role:${level.id.toString()}")selected="selected"#end>$textutils.htmlEncode($level.name)</option>
#end
</optgroup>
#end

I'm hoping to modify this to hide on specific group, something like this:

#if ($isRolePresent && !ProjectRole == "Name of Project Role To be Hidden")
<optgroup label="$i18n.getText('common.words.project.roles')">
#foreach ($level in $roleLevels)
<option value="role:${level.id}" #if($level.id && $selected == "role:${level.id.toString()}")selected="selected"#end>$textutils.htmlEncode($level.name)</option>
#end
</optgroup>
#end

But of course that logic doesn't work. Any suggestions?

[avidD]

Works like a charm, thanks Daniel!

[Svante Gustafsson Björkegren]

Hi all,

This is almost what I am looking for! I just want to throw out this additional use-case and see if there are any solutions for it:

What if I want to have 2 different Comment buttons? One for regular comments visible to "All Users" and one for internal comments viewable to a specific project group only?

I have taken the script above and tweaked it to my best knowledge but I get a weird behavior that JIRA remembers the last used security level. It has to do with refreshing page in some way. Please take a look at this post for details: https://answers.atlassian.com/questions/221408/separate-button-for-internal-comment-in-jira

Does anyone have a clue why this is the case and in that case is there a way of working around this?

Looking forwards to your replies!

// Svante

[Jan Evetts]

Hi, can someone explain to me how I make this work? I've placed the code in the banner field: /secure/admin/EditAnnouncementBanner.jspa without effect.

Thanks.

Jan

JIRA 5.2

[Jijo John [DevOps Consultant]]

Hi Daniel, Does this works for JIRA 6.x?

[Global Tools]

This doesn't work for Jira 6.3.14

[Sandra Meessen]

Hello Daniel, I don't understand completely. If I want to set the default visibility for comments different than "all users" I put your peace of coding in the announcement banner? But's that for the entire Jira?

I only want to change the default visibility for comments for 1 specific project. How do I do that?

[Danielle Zhu]

This is not available yet but the request seems to have gathered many votes: https://jira.atlassian.com/browse/JRA-9091

[pschaff01]

The answer provided by Daniel is great, but using "jQuery.noConflict();" in the beggining of the code can break the Classic Agile boards with an infinite spinning wheel. To fix this, you can use the code Daniel provided and just remove this line.

[Sebastiano VASSALLI]

Thanks Pietro,

I was having a strange behaviour where auto-complete wasn't working anymore in the issue navigator JQL filters and removing jQuery.noConflict() fixed it

[Minds]

In my tests if the inital code, the edit comment doe snot waork (the visible always change to Developers).

I made some changes and it worked

<script language="JavaScript">
<!--

jQuery.noConflict( );
var defaultRoleName = "role:10001";
var roleSelected = false;

function changeCommentLevel( )
{
	if ( roleSelected )
	{
		return;
	}//if

	if ( jQuery( '#comment' ).val() != "" )
	{
		// edition;
		roleSelected = true;
		return;
	}

	var commentLevelSelect = jQuery( '.security-level select#commentLevel option[value=\'' + defaultRoleName + '\']' );
	if ( commentLevelSelect )
	{
		var labelText = commentLevelSelect.first( ).text( );
		jQuery( "select#commentLevel" ).val( defaultRoleName );
		jQuery( "#commentLevel-multi-select a.drop span.icon" ).removeClass( "icon-unlocked" ).addClass( "icon-locked" );
		var htmlEscapedLabel = AJS.$( "<div/>" ).text( labelText ).html( );
		jQuery( ".security-level span.current-level" ).html( AJS.format( AJS.params.securityLevelViewableRestrictedTo, htmlEscapedLabel ) );
		roleSelected = true;
	}

}


jQuery( '#comment' ).live( 'focus', changeCommentLevel );
//-->
</script>
 
<style>
.alertHeader
{display:none;}
 
</style>

[Paul Clark _Redmoon Software_]

Hi, I realise you have found your answer but for others looking for an answer where they don't have to edit files or want a project level default then I have a paid plugin in the marketplace called comment security default (https://marketplace.atlassian.com/plugins/com.redmoon.jira.comment-security-default). This allows you to set a default globally or per project. You can also assign behaviour in case the permission is no longer available (you can force the user to choose a new permission). The default can be set for adding a comment, adding an attachment, logging work, linking issues and editing issues.

Thanks

Paul

[Manuel P.]

Very nice! Thank you Paul, I'm glad there is a cleaner way to do it.

Thanks, Manuel

[Jack Kelly]

I agree. Thanks for mentioning this. I find it better as not all of my teams will want the same default. I also like the color visual to support it as well. I just tested it and I will be requesting a purchase of it.

[Manuel P.]

Ok, thank you Danielle. I upvoted that issue.

In the meantime, I've found what could be a temporary workaround: the behaviours plugin. However, I haven't managed to make it work yet (w/ JIRA 5.0).

[DanielG]

I think it's better my solution that to implement behaviours plugin...

If you upgrade JIRA, you will need to check the compatibility of the plugin with JIRA. However with my solution will not be necessary.

[Sandra Meessen]

I tried the Behaviours functionality for this matter (hiding comments by default in a specific project for all users but 1 group) and it doesn't seem possible to do, because the comments are "not hidable". 

Than I am still looking for a solution to hide all comments for all users and only visible for 1 specific group and this within only 1 project (not over my entire Jira instance). Who can help me?

[Mullangi Madhu]

Hi @Manuel P. , Did you manage to find answer for the below. 

It works even when you have two different groups of users that need to have different defaults?

For example:

• A group "customers" with default "All users".
• jira-developers and jira-administrator and jira-users with default jira-users

Any suggestions please, I am starving for this since 1 month.

Please help me if you have a solution for this.

Thanks in Advance

Madhu

[Christopher Nelson]

This seems to work for me in Jira Server v7.11.  I imagine it has sharp corners. ;-)

It does have the advantage of not needing to know the role ID (e.g., 10001, etc.).

// Adapted from https://community.atlassian.com/t5/Jira-questions/The-comment-visibility-default-selection-can-be-configured/qaq-p/450149
// (That is for an older version of Jira. This works with v7.11.)
var restrictComments = function(groupOrRole) {
    console.log("Trying to restrict comments");
    var security = document.getElementsByClassName("security-level")[0];
    var commentLevelSelect = security.getElementsByTagName("select")[0];
    // commentLevelSelect is a SELECT, find the OPTION child which has innerText we want
    var options = commentLevelSelect.getElementsByTagName("option");
    var option;
    for (var i = 0; i < options.length; ++i) {
        if (options[i].innerText == groupOrRole) {
            commentLevelSelect.selectedIndex = i;
            option = options[i];
            break;
        }
    }

    // jQuery("#commentLevel-multi-select a.drop span.icon").removeClass("icon-unlocked").addClass("icon-locked");
    var e = document.getElementById("commentLevel-multi-select");
    e = e.getElementsByClassName("drop")[0];
    e = e.getElementsByClassName("security-level-drop-icon")[0];
    e.classList.remove("aui-iconfont-unlocked");
    e.classList.add("aui-iconfont-locked");
    // var htmlEscapedLabel = AJS.$("&lt;div/&gt;").text(labelText).html();
    // jQuery(".security-level span.current-level").html(AJS.format(AJS.params.securityLevelViewableRestrictedTo, htmlEscapedLabel));
    e = security.getElementsByClassName("current-level")[0];
    e.innerText = groupOrRole;
};

[Christopher Nelson]

I'm looking for an answer to this for Jira Server v7.11.  I'll keep looking and if I find something, link it here.  Hints appreciated...

[Paul Clark _Redmoon Software_]

Hi Chris, not sure if you are interested but there is a paid for app called "Comment Security Default" that handles the defaulting for you.  You can specify the different defaults for new Comments and comments in the edit issue, log work, assign and transition dialogs.  

Also to make users aware of the default you can set the background and/or border color of the comment field for comments that are "Viewable to all users" or all the other security settings

https://marketplace.atlassian.com/apps/1212192/comment-security-default?hosting=server&tab=overview

Thanks

Paul

[Shawn Cady]

I agree that this would be a security issue if this approach were to be allowed - just checking to see if there are any other workarounds that might be possible using existing capabilities (without injecting javascript into pages via the banner)

[Shawn Cady]

Daniel, I assume that this is only possible in Hosted version of Jira, and not OnDemand (as onDemand correctly encodes anything entered in the Banner field). Are you aware of a way to do this or anything close in the OnDemand version?

[MattS]

If such a way exists then I think Atlassian would treat it as a security problem.