• Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Medium Medium (View bug fix roadmap)
    • None
    • 7.0.0, 7.1.0, 7.2.0, 7.3.0, 7.4.0, 7.5.0, 7.6.0, 7.7.0, 7.8.0, 7.9.0, 7.10.0, 7.11.0, 7.12.0, 7.13.0, 8.0.0
    • Documentation

      Problem Solution:

      While we have JIRA Core JAVA API available for version 7.X and JIRA Service Desk 3.x, the latest JAVA API that is available for JIRA Software is 6.7.12 which is JIRA Agile.

      Suggested Solution:

      To update the page with JIRA Software latest JAVA API list.

            [JSWSERVER-15321] JIRA Software JAVA API for Version 7 and above

            Monty added a comment -

            Jira 8 has come and is almost on it's way out and now Jira 9 has been released and still no updated docs?
            For shame Atlassian, you were doing so well and things are starting to slide for way too long now. 
            As someone trying to get into the Jira plugin game for internal Jira needs it's hard to learn anything. I NEED HALP!!!

            Monty added a comment - Jira 8 has come and is almost on it's way out and now Jira 9 has been released and still no updated docs? For shame Atlassian, you were doing so well and things are starting to slide for way too long now.  As someone trying to get into the Jira plugin game for internal Jira needs it's hard to learn anything. I NEED HALP!!!

            Guys common. We are developing for 15k+ user tier Data Center customer and we are unable to read in documentation? What kind of product this is?

            Tomáš Vrabec [neresit.cz] added a comment - Guys common. We are developing for 15k+ user tier Data Center customer and we are unable to read in documentation? What kind of product this is?

            So now I'm trying to call classes in 8.5.7 that are apparently deprecated, and I have no way of determining the correct implementation to support my instance. Why does anyone think this is a good idea?

            Chuck Vanderwist added a comment - So now I'm trying to call classes in 8.5.7 that are apparently deprecated, and I have no way of determining the correct implementation to support my instance. Why does anyone think this is a good idea?

            Dear Atlassian, I am baffled that this request does not get attended and only has a MEDIUM Priority.

            Jira is good as a toolbox you can tweak, not as a final end user tool as it lacks so much. You are really playing against your strengths not exposing the API of a major part of your software, and I guess a part that many of your customers do buy your software for.

            Yves Basquet added a comment - Dear Atlassian, I am baffled that this request does not get attended and only has a MEDIUM Priority. Jira is good as a toolbox you can tweak, not as a final end user tool as it lacks so much. You are really playing against your strengths not exposing the API of a major part of your software, and I guess a part that many of your customers do buy your software for.

            @Gustav : couldn't have said this better

            Marc Minten (EVS) added a comment - @Gustav : couldn't have said this better

            I think Atlassian would actually benefit from investing the time needed to properly document the backend API for Jira Software. The reason is this:

            When no official documentation exists, third-party developers will try to figure out how things work for themselves. Because the Jira backend isn't sandboxed, many (most?) internal Jira implementation details are fully exposed to third-party code. So not only is there a risk that information circulating on the forums is incorrect (or makes use of Jira internals in incorrect ways), there is also a risk that people propose solutions that make things more difficult for Atlassian in the future.

            For example, I have seen several recommendations that suggest that we should extract information about sprints from (what I assume) is internal data stored in a custom Jira field. Now that this practice has been established, any change Atlassian makes in that internal data format will immediately break all plugins that rely on it.

            I cannot help but think that such a situation would hurt Atlassian too, and not only third-party developers. If, at some point in the future, Atlassian really does need to change that data format and they wanted to avoid the break-all-plugins problem, they would have to implement a workaround that is likely to be more complex and bug-prone than if the internal data format had remained hidden.

            One way to look at it is that the lack of official documentation is implicitly causing third-party developers to add to Atlassian's technical debt.

            Gustav Taxen added a comment - I think Atlassian would actually benefit from investing the time needed to properly document the backend API for Jira Software. The reason is this: When no official documentation exists, third-party developers will try to figure out how things work for themselves. Because the Jira backend isn't sandboxed, many (most?) internal Jira implementation details are fully exposed to third-party code. So not only is there a risk that information circulating on the forums is incorrect (or makes use of Jira internals in incorrect ways), there is also a risk that people propose solutions that make things more difficult for Atlassian in the future. For example, I have seen several recommendations that suggest that we should extract information about sprints from (what I assume) is internal data stored in a custom Jira field. Now that this practice has been established, any change Atlassian makes in that internal data format will immediately break all plugins that rely on it. I cannot help but think that such a situation would hurt Atlassian too, and not only third-party developers. If, at some point in the future, Atlassian really does need to change that data format and they wanted to avoid the break-all-plugins problem, they would have to implement a workaround that is likely to be more complex and bug-prone than if the internal data format had remained hidden. One way to look at it is that the lack of official documentation is implicitly causing third-party developers to add to Atlassian's technical debt.

            Joel added a comment - - edited

            ^^^ what Stefan Glase said...

            Created:  13/Dec/2016 3:49 PM !?

            Joel added a comment - - edited ^^^ what Stefan Glase said... Created:  13/Dec/2016 3:49 PM !?

            I agree with the previous commenters and the author of this issue. Not having a stable, reliable and documented Jira Software API available is a major issue to all developers in the Atlassian Jira ecosystem.

            Stefan Glase added a comment - I agree with the previous commenters and the author of this issue. Not having a stable, reliable and documented Jira Software API available is a major issue to all developers in the Atlassian Jira ecosystem.

            oliver.hundeshagen882665184 added a comment -

            In additon to the documentation part of this issue it should also be mentioned that at the moment the Jira Software JAVA API is hardly usable in an enterprise customer environment. 
            The exposure and therefore availability of service seems to be rather random.
            Some of them are usable (e.g. the RapidViewService) while others are not made public in the plugin.xml of the API (e.g. BoardAdminService)

            This makes it currently not possible to propose any custom development for Java API based plug-ins for Jira Software because at some point you run into a missing piece of functionality that is based on not available components.

            oliver.hundeshagen882665184 added a comment - In additon to the documentation part of this issue it should also be mentioned that at the moment the Jira Software JAVA API is hardly usable in an enterprise customer environment.  The exposure and therefore availability of service seems to be rather random. Some of them are usable (e.g. the RapidViewService) while others are not made public in the plugin.xml of the API (e.g. BoardAdminService) This makes it currently not possible to propose any custom development for Java API based plug-ins for Jira Software because at some point you run into a missing piece of functionality that is based on not available components.

            This is not exactly relevant but I'm not sure where else to mention it (feel free to point me in the right direction). I noticed recently that links for versions of Jira after 7.6.1 are no longer showing up at https://docs.atlassian.com/software/jira/docs/api/. Although, as Matt points out above, they are there (and latest goes to the right spot).

            For the record, it is confusing that the docs URL has "software" in it but does not include Jira Software. I just assumed that it did until I found this issue today (I don't actually use Software specific api calls that regularly, obviously). I've added my vote.

            Nathanael Motz added a comment - This is not exactly relevant but I'm not sure where else to mention it (feel free to point me in the right direction). I noticed recently that links for versions of Jira after 7.6.1 are no longer showing up at https://docs.atlassian.com/software/jira/docs/api/ . Although, as Matt points out above, they are there (and latest goes to the right spot). For the record, it is confusing that the docs URL has "software" in it but does not include Jira Software. I just assumed that it did until I found this issue today (I don't actually use Software specific api calls that regularly, obviously). I've added my vote.

              94e733e73fd4 Robert Klimkiewicz
              jrahmadiputra Julian (Inactive)
              Affected customers:
              105 This affects my team
              Watchers:
              76 Start watching this issue

                Created:
                Updated: