Determine if a user has admin permissions from a javascript web-resource

I need to filter out some elements of the link type selector for all non-administrator users. I am able to accomplish the filtering with some simple javascript:

jQuery(document).ready(function ($) {
  'use strict';

  let whitelist = new Set();
  whitelist.add("relates to");

  JIRA.bind(JIRA.Events.NEW_CONTENT_ADDED, (e, context) => {
    jQuery('#link-jira-issue #link-type.select option')
      .filter((idx, option) => !whitelist.has(option.value))
      .remove();
  });
});

But obviously this applies to all users. I thought of trying a condition on the plugin:

  <web-resource key="WhitelistIssueLinks" name="Whitespace Issue Links">
    <condition class="com.atlassian.jira.plugin.webfragment.conditions.JiraGlobalPermissionCondition" invert="true">
      <param name="permission">admin</param>
    </condition>
    <context>atl.general</context>
    <dependency>jira.webresources:global-static</dependency>
    <description>Whitelist issue links</description>
    <resource type="download" name="whitelistIssueLinks.js" location="/js/whitelistIssueLinks.js" />
  </web-resource>

But ran accross this thread where the guy recommended against doing so (for unexplained caching reasons) and it didn’t seem to work anyway. Any ideas on how to determine if the user is an admin? Is there a better way to filter out the values in that dropdown based on permission?

Hi Lucas,

To check if current user has admin permissions from js, you can use result of a call to /rest/api/2/mypermissions endpoint. In this case you don’t need to use web-resource condition.

The reason that you don’t want to use conditions is that it becomes a performance hit (see https://developer.atlassian.com/server/framework/atlassian-sdk/stateless-web-resource-transforms-and-conditions/#how-do-i-fix-offending-conditions- ) and the support in the products are not so awesome.

Best way would be to do what @AlexeyDorofeyev mentions and do it in the javascript side and send down all of the javascript to the end user.

That said - I would caution against binding to all.general context unless you really have to since that will be on every page. I would look for a context that’s only available on the page/web-panel that you’re displaying on.

1 Like

There is probably a really simple answer to my next question, but… How do you authenticate as the current user (possibly impersonated) from the javascript to the rest api? I tried a simple fetch:

fetch("/rest/api/2/mypermissions").then((data) => console.log(data))

and get what appears to be an empty/useless response:

{ type: "basic", url: "https://review.example.local/rest/api/2/mypermissions", redirected: false, status: 200, ok: true, statusText: "200", headers: Headers(19), body: ReadableStream, bodyUsed: false }

You are calling the API from a Jira page, meaning the call is made as the current user. Your response is fine. The point is that the payload is in the response body, which is a ReadableStream and must be converted with a .json() method like this:

fetch("/rest/api/2/mypermissions").then((data) => data.json()).then(data => console.log(data.permissions))

Or maybe it’s more elegant to use the provided jQuery function that does the conversion automatically:

AJS.$.getJSON("/rest/api/2/mypermissions", data => console.log(data.permissions))
1 Like

Doggonnit… What a rookie mistake. Thank you Alexey, that is exactly what i was looking for and should provide exactly what i need!