-
Bug
-
Resolution: Not a bug
-
Medium (View bug fix roadmap)
-
None
-
4.0 - Beta 1
-
None
-
4
-
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.
[JRASERVER-17509] A SOAP API method using an issue id seems odd
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
So you don't know either 
. Luckily for us, Fisheye does:
Just to humour me, could you ask Andreas K. why he thinks that the issue id will be useful for customers?
~Matt
Who on earth are the users who want to use that method?
Those people who stop their abstraction level at the issue id level
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?
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()
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