I have been struggling with this one for a few hours now and can’t see any reason for this to be the case.
In my add-on I have a simple class extending AbstractWebCondition
, with a shouldDisplay
method that looks like this:
public boolean shouldDisplay(ApplicationUser applicationUser, JiraHelper jiraHelper) {
return applicationUser != null && ComponentAccessor.getUserUtil().getJiraAdministrators().contains(applicationUser);
}
It appears to work properly, hiding and showing add-on menu items based on the user being a Jira Administrator.
But then in the servlets that these links point do, I have a similar check in the doGet
method:
public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException {
ApplicationUser loggedInUser = ComponentAccessor.getJiraAuthenticationContext().getLoggedInUser();
if (loggedInUser == null) {
// Redirect to login
} else if (!ComponentAccessor.getUserUtil().getJiraAdministrators().contains(loggedInUser)) {
// Show permission denied
}
// Render servlet velocity template
}
And for some reason this is executing the "Show permission denied"
block, even though it appears to be doing the exact same check as the AbstractWebCondition. I’ve added debug code and the ApplicationUser
object appears to be the same in both classes. I’m at a loss. Why would this be happening? The only thing I can think of is that ApplicationUser
in AbstractWebCondition
has some subtle difference from the return value of ComponentAccessor.getJiraAuthenticationContext().getLoggedInUser()
in HttpServlet
, though I have been unable to determine what that might be. Jira Server 7.8.1 and 7.10.0 are both doing it, and it is not happening for all users in the group. Basically the AbstractWebCondition
check always works as expected, but the HttpServlet
check only works properly for most users.