How best to hide Issue Security Level field on the issue screen

[f***@atlassian.com]

We are using JIRA to manage our customer technical support issues. We are using issue-level security as part of this effort to prevent customers from seeing each other's issues.

Unfortunately, the presence of the Issue Security Level field raises the customer anxiety level about their privacy that would not otherwise have been an issue if the field was not displayed in the first place. In other words, because they know that JIRA can support different issue security level values, they are concerned (despite our assurrances) that there is a risk that the wrong one may be selected and their issue may be visible to other customers.

I can modify the securitylevel-view.vm template or SecurityLevelSystemField class to suppress the value, but I would rather suppress the entire line. Can anyone tell me where I can find where the fields on the issue details page are actually enumerated and rendered? I think that it would be most practical to intercept and skip the loop iteration when it comes upon the issue security level field. Or if you have any better ideas, I would appreciate them as well.

Kindest regards,
--
Post by ***@quic.com - online at:
http://forums.atlassian.com/thread.jspa?forumID=46&threadID=29071

[f***@atlassian.com]

Sorry, this message should probably have been posted to the JIRA Development forum instead.
--
Post by ***@quic.com - online at:
http://forums.atlassian.com/thread.jspa?forumID=46&threadID=29071

[f***@atlassian.com]

Locate the section in \includes\panels\issue_headertable.jsp where security level is displayed (around line 194 in 3.13) and add an extra condition to the block to display only if the logged in user is a member of one of your internal groups. That would mean your clients wouldn't see it, but you would.

To do that try this:

add
<webwork:if test="/remoteUser/inGroup('Staff') == true">
before the existing line

<webwork:if test="@fieldVisibility/fieldHidden(., 'security', ../string('type')) == false">

and then an additional

</webwork:if>

to close the block.

For me, my internal users are members of 'Staff' group. I just tried this in my 3.13 test and it worked like a charm. Thanks for the idea. I am going to implement this in our next upgrade.
--
Post by napplebaum - online at:
http://forums.atlassian.com/thread.jspa?forumID=46&threadID=29071

[f***@atlassian.com]

Thanks for the information, Neal.

Someone else in the office pointed out another option. You can create a copy of the default field configuration, and mark the security level field as hidden. Then you associate the new field configuration to the project. The field is hidden from everyone, in this case; this may or may not be an issue if the field is not of interest to internal staff either.

Thanks again...
--
Post by ***@quic.com - online at:
http://forums.atlassian.com/thread.jspa?forumID=46&threadID=29071

[f***@atlassian.com]

OK - that wouldn't work for us.

There's a certain comfort when I see that the security is set up correctly when viewing an issue.

Besides, if it is hidden, how does it get set?
--
Post by napplebaum - online at:
http://forums.atlassian.com/thread.jspa?forumID=46&threadID=29071

[f***@atlassian.com]

It turns out that the Field Configurations modification that I proposed won't work for us either.

We determined through our testing that hiding the Issue Security field in the Field Configurations area also has the unfortunate side effect of preventing the Issue Security field from being assigned the default security level set for the Issue Security Scheme assigned to the project in the Project administration area.

In other words, by hiding the Issue Security field, Issue Security field is no longer assigned a default value and newly created issues are assigned a security level of none, and the issue is visible to all users.

I think that this is a bug and I'll be creating a issue with Atlassian support.
--
Post by ***@quic.com - online at:
http://forums.atlassian.com/thread.jspa?forumID=46&threadID=29071

[f***@atlassian.com]

Umm, isn't that what I said? "Besides, if it is hidden, how does it get set? "

I don't think this is a bug, although you could log it with Atlassian.
--
Post by napplebaum - online at:
http://forums.atlassian.com/thread.jspa?forumID=46&threadID=29071

[f***@atlassian.com]

It was not obvious to me that you were alluding to the behaviour of JIRA that hidden fields do not have values set for them. I thought you were talking only about setting the value manually, which we have no need of doing. Let me elaborate...

We have an Issue Security Scheme associated to the project wherein the default Issue Security level is "Reporter and Internal Staff". We have no use case of needing to modify the visibility of issues after they have been created, so there is no reason why the Security Level of the issue would need to be changed. We had assumed that the issue's Security Level field would be set to the default when the issue is created despite the fact that the Issue Security field was hidden. Because there is no reason for it to be changed and under the assumption that it would be initialized to the expected default value, there is little reason for it to be visible. Unfortunately, the assumption didn't pan out.

I also appreciated the "comfort" idea, but I believe that over time users would mentally filter out the field and stop noticing that it was there. It would follow that when they stopped noticing that it was there, they would probably also stop noticing that it wasn't there.

I think that the best way (for me) to achieve a decent comfort level would be to run a periodic automated regression test of the project that confirmed that issues had the appropriate Issue Security field value. This probably could be run against the database on the nightly basis confirming that there are zero issues in the project that have the Issue Security field set improperly. Maybe something could be done with a customer user list and a web services API (or REST-based HTTP requests) that return a list of issues (perhaps in the form of an RSS feed); that would certainly give me more comfort that the UI was respecting the database settings, but it might take a little too much effort to get going compared to the database-based solution.

I logged the issue with Atlassian, and they agree with you. They feel that it is not a bug that the field (any field) is not initialized to a value when the field is hidden via the field configurations page.

In light of these circumstances, it looks like I will be implementing your webwork solution after all. Thanks for sharing it!
--
Post by ***@quic.com - online at:
http://forums.atlassian.com/thread.jspa?forumID=46&threadID=29071