JIRA
  1. JIRA
  2. JRA-17509

A SOAP API method using an issue id seems odd

    Details

      Description

      Looking at the new methods in the SOAP API for the 4.0.0 beta1 there is one method that seems odd: getResolutionDateById(String token, Long issueId)
      Why would I want to use the Long issueid parameter for anything? Finding the issue id (as opposed to the issue key) is hard. What's the purpose of adding this method to the API?

      Interface com.atlassian.jira.rpc.soap.JiraSoapService

      Added Methods from 3.13.1 to 4.0.0 Beta1

      boolean addBase64EncodedAttachmentsToIssue(String, String, String[], String[]) An alternative mechanism for adding attachments to an issue.
      void deleteProjectAvatar(String, long) Deletes the given custom Avatar from the system.
      RemoteIssue[] getIssuesFromFilterWithLimit(String, String, int, int) Returns issues that match the saved filter specified by the filterId.
      RemoteIssue[] getIssuesFromTextSearchWithLimit(String, String, int, int) Returns issues containing searchTerms.
      RemoteAvatar getProjectAvatar(String, String) Retrieves the current avatar for the given project.
      RemoteAvatar[] getProjectAvatars(String, String, boolean) Retrieves avatars for the given project.
      Date getResolutionDateById(String, Long) Given an issue id, this method returns the resolution date for this issue.
      Date getResolutionDateByKey(String, String) Given an issue key, this method returns the resolution date for this issue.
      void setNewProjectAvatar(String, String, String, String) Creates a new custom avatar for the given project and sets it to be current for the project.
      void setProjectAvatar(String, String, Long) Sets the current avatar for the given project to that with the given id.

        Activity

        Hide
        Brad Baker [Atlassian] added a comment -

        The ResolutionDate is now a System field in JIRA. HOwever we did not want to add it to the RemoteIssue object because it would break backwards compatiblity on th SOAP objects returned.

        So we added 2 new methods to get it, as you have pointed out :

        Date getResolutionDateById(String, Long) Given an issue id, this method returns the resolution date for this issue.
        Date getResolutionDateByKey(String, String) Given an issue key, this method returns the resolution date for this issue.

        The paradigm is that you wond make one call to get issue information and one call per issue to get resolution date if needed. Not efficient as one can imagine but backwards compatible.

        If you dont like using issue Id you can use issue key via getResolutionDateByKey()

        Show
        Brad Baker [Atlassian] added a comment - The ResolutionDate is now a System field in JIRA. HOwever we did not want to add it to the RemoteIssue object because it would break backwards compatiblity on th SOAP objects returned. So we added 2 new methods to get it, as you have pointed out : Date getResolutionDateById(String, Long) Given an issue id, this method returns the resolution date for this issue. Date getResolutionDateByKey(String, String) Given an issue key, this method returns the resolution date for this issue. The paradigm is that you wond make one call to get issue information and one call per issue to get resolution date if needed. Not efficient as one can imagine but backwards compatible. If you dont like using issue Id you can use issue key via getResolutionDateByKey()
        Hide
        Matt Doar (ServiceRocket) added a comment -

        I get that, but the point is that it is inconsistent having the issue id even mentioned. Most people stop their abstraction level at the issue key level.
        Who on earth are the users who want to use that method?

        Show
        Matt Doar (ServiceRocket) added a comment - I get that, but the point is that it is inconsistent having the issue id even mentioned. Most people stop their abstraction level at the issue key level. Who on earth are the users who want to use that method?
        Hide
        Brad Baker [Atlassian] added a comment -

        Who on earth are the users who want to use that method?

        Those people who stop their abstraction level at the issue id level

        Show
        Brad Baker [Atlassian] added a comment - Who on earth are the users who want to use that method? Those people who stop their abstraction level at the issue id level
        Hide
        Matt Doar (ServiceRocket) added a comment -

        So you don't know either . Luckily for us, Fisheye does:

        http://svn.atlassian.com/fisheye/browse/public/atlassian/rpc-jira-plugin/trunk/src/main/java/com/atlassian/jira/rpc/soap/JiraSoapService.java?r1=29227&r2=30097

        Just to humour me, could you ask Andreas K. why he thinks that the issue id will be useful for customers?

        ~Matt

        Show
        Matt Doar (ServiceRocket) added a comment - So you don't know either . Luckily for us, Fisheye does: http://svn.atlassian.com/fisheye/browse/public/atlassian/rpc-jira-plugin/trunk/src/main/java/com/atlassian/jira/rpc/soap/JiraSoapService.java?r1=29227&r2=30097 Just to humour me, could you ask Andreas K. why he thinks that the issue id will be useful for customers? ~Matt
        Hide
        Anton Mazkovoi [Atlassian] added a comment -

        The issue key changes when the issue is moved to a different project. It would be much better, if all remote methods used an issue id (the true unique, non changing identifier of the issue) for everything.

        The only time I see the need to use an issue key in a method call, is when it is entered by the user as some input parameter.

        Cheers,
        Anton

        Show
        Anton Mazkovoi [Atlassian] added a comment - The issue key changes when the issue is moved to a different project. It would be much better, if all remote methods used an issue id (the true unique, non changing identifier of the issue) for everything. The only time I see the need to use an issue key in a method call, is when it is entered by the user as some input parameter. Cheers, Anton
        Hide
        Matt Doar (ServiceRocket) added a comment -

        Ah, the light dawns. The problem is that the issue key is only nearly constant, not totally constant. From the API user's point of view however it might be easier to assume that the key is constant and just provide a redirect to the new issue key as necessary. Thinking about it I believe there are only a few types of methods where this might even matter:

        getIssue(String issueKey) - return an object with the real, changed issue key as well as all the other fields. Also applied to getComponent, getVersion etc

        createSubTask(String issueKey) - the key of the new subtask could be in a different project than the user assumed

        cloneIssue( issueKey) - the key of the new issue could be in a different project than the user assumed

        Anyway, I'm enlightened. Thanks for your patience, Brad.

        ~Matt

        Show
        Matt Doar (ServiceRocket) added a comment - Ah, the light dawns. The problem is that the issue key is only nearly constant, not totally constant. From the API user's point of view however it might be easier to assume that the key is constant and just provide a redirect to the new issue key as necessary. Thinking about it I believe there are only a few types of methods where this might even matter: getIssue(String issueKey) - return an object with the real, changed issue key as well as all the other fields. Also applied to getComponent, getVersion etc createSubTask(String issueKey) - the key of the new subtask could be in a different project than the user assumed cloneIssue( issueKey) - the key of the new issue could be in a different project than the user assumed Anyway, I'm enlightened. Thanks for your patience, Brad. ~Matt

          People

          • Assignee:
            Unassigned
            Reporter:
            Matt Doar (ServiceRocket)
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: