You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
JiraMonitoringFilter assumes that the Principal in the current session is of a sub-class that JIRA's PermissionManager can handle. This is not always the case, e.g. for JIRA 6+ when a custom authenticator sets a Principalother than an ApplicationUser. Ideally, JiraMonitoringFilter should only assume a Principal and not a specific sub-class, and therefore convert it to an appropriate user class as needed.
This change targets JIRA 6+ by explicitly converting the Principal to an ApplicationUser.
For JIRA 5 and older, the existing logic is used. It's possible the improve the logic for those older JIRAs as well, but with little benefit, because those JIRA versions are unsupported and not used much anymore.
java.lang.IllegalStateException: java.lang.IllegalArgumentException: argument type mismatch
at net.bull.javamelody.JiraMonitoringFilter.hasJiraSystemAdminPermission(JiraMonitoringFilter.java:224)
The reason will be displayed to describe this comment to others. Learn more.
I would prefer return false instead of throw new IllegalStateException(e) here, in order to never have an exception when the instance of JiraMonitoringFilter is created.
The reason will be displayed to describe this comment to others. Learn more.
The if condition would always be true in JIRA 6+. And the code in the if block executes getUserByName (which runs whatever and which may slow down the rendering of the reports). But this code is needed only when a custom authenticator sets a Principal which is not an ApplicationUser.
So I think it would be better to not do that when not needed and to add && !Class.forName("com.atlassian.jira.user.ApplicationUser").isInstance(user) in the if condition.
I'm an admin for Atlassian Toolchain, so forgive me if this might be a stupid question here.
What I'm missing in the new version is the plugins for JIRA, confluence and Bamboo. Do I have to build those on my own?
EDIT: Found it. Extra site: https://github.com/javamelody/jira-confluence-javamelody/releases
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
JiraMonitoringFilterassumes that thePrincipalin the current session is of a sub-class that JIRA'sPermissionManagercan handle. This is not always the case, e.g. for JIRA 6+ when a custom authenticator sets aPrincipalother than anApplicationUser. Ideally,JiraMonitoringFiltershould only assume aPrincipaland not a specific sub-class, and therefore convert it to an appropriate user class as needed.This change targets JIRA 6+ by explicitly converting the
Principalto anApplicationUser.For JIRA 5 and older, the existing logic is used. It's possible the improve the logic for those older JIRAs as well, but with little benefit, because those JIRA versions are unsupported and not used much anymore.