Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,362,749
Community Members
 
Community Events
168
Community Groups

Solution for viewing issues with different permissions

We use comment-permissions and Issue-wide Permissions to flag issues / comments as internal.

We often discuss issues directly in Jira via Screensharing with our customers. In those discussions we would like to hide those comments / issues from being displayed.

 

Is there a easy way (without being an Admin) to show issues based on other (lower) user-permissions.

Using a generic user account with lower permissions for those meetings is not an option.

We have Scriptrunner, so a scripting solution would be possible.

 

 

2 answers

0 votes

Scriptrunner can't come between Jira and your browser when serving up comments. That's controlled by the internal permission system in jira. 

What can scriptrunner do?

  • Make changes to just about any jira entity that can be done in the ui (add/remove user to roles and groups, change issue or comment attributes etc)
  • Hide an entire UI element
  • Show a custom-built UI element

So one option would be to hide the built-in comments panel and load a completely custom comment panel that would load comments from a SR rest api endpoint that can implement your rules. You would have to trigger the screenshare mode manually by applying something like a user property and refresh the issue view. Then the comment panel would not include certain comments.

The custom-built comment panel would not be trivial to design and may be quite a bit slower than the default one. Perhaps that can be mitigated by showing the custom comment panel only when the screenshare mode is on and the default comments panel otherwise.

Another, perhaps simpler option that might work is if comments are set to be visible only to a specific group. But that group does not control any permission other than comment viewing.

Then you could use a scrirptrunner button to remove the current user from that group and add the user to another temporary group.

After that, when you refresh the page, the protected comments will not load per the built-in permission mechanism.

Then when screensharing is done, because of membership to the temporary group, you allow the user to be added back to the original group (again with a scriptrunner button).

A third non-scriptrunner option is to use something like tampermonkey/greasemonkey browser extension. This would allow you to write some javascript that can tamper with the jira issue view (after or as it's loading) and hide comments when the screenshare view toggle is enabled.

0 votes

This would be a very complex thing to code for and would need a lot more than just scriptrunner.

>We often discuss issues directly in Jira via Screensharing with our customers. In those discussions we would like to hide those comments / issues from being displayed.

You are going to need to code something into the screensharing software that can tell the Jira server not to display comments if the current user of the screenshare hits Jira with a browser.  Plus the code on the server side to listen for it and hide the comments.  And probably something in the browser to shout when screensharing/Jira are being used together.

Probably a better solution - look at why you are screen-sharing Jira issues with customers - that's probably a broken thing to do.

Thanks for your quick reply!

The link between screensharing and Jira ist not necessary in the first step. I thought about a custom button in Jira to set a user-property . As long as this user-property is active all stuff with issue / comment security set is hidden. 

Is something like this possible with scriptrunner?

You're still having to mess with the display a bit too much for SR to deal with.  I'd strongly recommend either

  • Not using screenshares of Jira.  Use it as intended, with customers able to see the public comments when they browse, rather than over a screenshare that would expose internals.
  • @Peter-Dave Sheehan 's answer!

Suggest an answer

Log in or Sign up to answer
TAGS

Atlassian Community Events