However, it is mentioned that this new feature should only affect state changing calls, and suggest to change calls to GET to avoid the problem, which is what I already do.
I saw the following: How to work around the @SupportedMethod problem?
This solution seems very cumbersome, I was hoping there is a simpler solution.
Maybe I am missing something, I am new to Jira Plugin development, but if I compile for Jira 9 I assume some features that can be used and are not part of Jira 8 will be broken and make the plugin unstable
It’s possible to make a plugin that works both in Jira 8 and 9. The general trick: If you use a class, all its imports must be available. So, the class must only be loaded if you are in Jira 9.
Therefore the solution highlighted in the previous answer is to have a specific class for Jira 8 and another specific for Jira 9, and only do “new()” on them if you are in the correct Jira version. If you understand this, then the answer shouldn’t seem too complicated.
The answer pointed by AlexeyDorofeyev is to compile against jira 9 and use com.atlassian.jira.security.request;resolution:=optional.
I understand the logic of your elaborate solution from that thread, but as it involves an additional library and two webhooks I was hoping there is something simpler, as having a plugin that works with both versions sounds like a common request, especially when I only use GET which should not be blocked by the XSRF protection