getlinkedissues

[reprev]

Hey,

Now that I've finally made the upgrade to Jira 4.2 I'm hoping to once
again use this excellant extended plugin.

I am hoping to use getlinkedissues() but I can't find any way to
differentiate the results returned as to whether they're inbound or
outbound.

For example, with a "Blocked" link, some issues are "Blocking" others,
and some are "Blocked By" others. But the soap call returns all linked
issues, and I can't see a way of sorting the results so I know which
are "Blocking" and which are "Blocked By" the issueID given.

Any ideas?

Thanks!
jon.

[Ath]

Jon,

I recall having the same question when I worked on (improved to not
return it's own issueId) this function, and eventually got distracted
by something else, and since nobody asked... :-(
The best possible solution IMHO is to add 2 methods,
getLinkedInbound() and getLinkedOutbound() with the same parameters
and returntype, but retrieving only the links of a specific direction
(now it's a concatenated list of both types, Inbound first, then
Outbound, with no separator). Another solution could be to add an
empty or null RemoteIssue between the 2 lists, so you can detect their
direction with some extra code.
Personally I like the 2 extra methods best, but please comment if you
want something different. I'm quite flexible :-)
I'll work on this the next few days, I have some time available. It
should become version 1.0.4

HTH

[Mayer, Jonathan]

That's very kind of you Ath - certainly the creation of the two new methods would be idea for me.

Jon,

HTH

--
You received this message because you are subscribed to the Google Groups "jira-extended-webservice" group.
To post to this group, send email to jira-extende...@googlegroups.com.
To unsubscribe from this group, send email to jira-extended-webs...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jira-extended-webservice?hl=en.

[Ath]

Jon, all,

I've added 3 methods:
- getLinkedInward
- getLinkedOutward
- updateUser (donated by Matt Doar through the issue-tracker)

Uploaded a compiled jar with version 1.0.4-SNAPSHOT.

Parameters for getLinkedInward & getLinkedOutward are equal to
getLinkedIssues, except only fetch the related kind of links. Be aware
that SubTasks are also a kind of Link, with both an Inward and Outward
direction... I wasn't able to provide more info on the type of link,
I'll try to investigate that later (need the source of Jira
SoapService for that)

HTH

[Mayer, Jonathan]

Many thanks for your hard work Ath, I'll let you know how it goes. A similar method that works for sub tasks would be very helpful but no rush!

Take care,
Jon.

[Mayer, Jonathan]

Works like a charm - thanks Ath! It's really improved the usefulness of the tool I've been writing.

Thanks,
Jon.

-----Original Message-----
From: jira-extende...@googlegroups.com [mailto:jira-extende...@googlegroups.com] On Behalf Of Ath

Sent: 11 December 2010 14:31

[Ath]

Jon,

Good to here it works as expected. AFAICS, it works just as well on
SubTasks, I just created a subtask issue from a normal issue, and
linked from the subtask to another normal issue, and requesting all
links from the subtask issue, displays the link to the main issue as
an inward link, and the link to the other issue as an outwasrd link,
just as I set it from the normal web interface.
You can select the subtasks, and get their links, by first querying
for all sub-tasks using "issuetype = Sub-task" in your query, and with
this list, get all links to/from these issues.
What more or else would you want? (besides the actual IssueLinkType[]
I already suggested, but can't provide yet)

HTH

[Mayer, Jonathan]

Thanks Ath,

Given a parent pkey or ID, is there an easy way to get a list of the parent's sub tasks? I know I can create subtasks via this extended webservice, but not list them. Would I have to do something along the lines of a JQL query instead? If not, that might be another logical addition to this webservice.

[Ath]

Jon,

I added another method that should fit your needs, I hope.
This is the full java interface description for it:
--------------
/**
* Retrieve link and link-type info of type <code>linkType</code> (or
all if
* null) that issueId <code>issueIdFrom</code> links to.
*
* @param token
* user token from login
* @param issueIdFrom
* issue on which the link info should be gotten
* @param linkType
* name of the link type to fetch, "" for all types
* @param separator
* a separator string to be used between the info items,
defaults
* to "|" if null or empty
* @return An array of strings with the following format, separated
by
* parameter <code>separator</code> or "|" if null or empty:</
br>
* (Any information already known is left out, like the
* source-issueKey. Field-comments in round brackets.)
*
* <pre>
* link.issueKey |
* link.issueId |
* link.id |
* link.isSystemLink ("Y" or "N") |
* linkTypeMnemonic ("I" or "O") |
* linkType.Id |
* linkType.Name |
* linkType.Inward (description) |
* linkType.Outward (description) |
* linkType.Style |
* linkType.isSubTaskLinkType ("Y" or "N") |
* </pre>
*
* The string is always ended with a separator so it can be
* externally 'recognized' if required.</br> Example result
* (2-string array) (requested issueIdFrom = ATH-1.getId()):
*
* <pre>
* ATH-3|10010|10020|N|I|10011|Related|relates also to|related to||N|
* ATH-2|10001|10060|Y|O|10000|jira_subtask_link|jira_subtask_inward|
jira_subtask_outward|jira_subtask|Y|
* </pre>
*
* The first one is a standard 'Related' inward link from
* ATH-3.</br> The second one is a SubTask link from ATH-1 to
ATH-2,
* where ATH-2 is the SubTask. The SubTask is both a
SystemLink and
* a SubTaskLinkType.
* @throws RemoteException
*/
public String[] getLinkedInfo(String token, Long issueIdFrom,
String linkType, String separator) throws RemoteException;
-------------------

Didn't want to create a new Type containing both IssueLink and
IssueLinkType info, so 'solved' it with a String array and a
configurable separator.
I tested it on my local Jira 4.0.1 and 4.2.1 installs.

Regards,
Ath

[Mayer, Jonathan]

Looks good, thanks again!

[Mayer, Jonathan]

Hiya Ath et al,

Are there any options for extending this service to include some token management stuff?

It would be useful to have something like "isTokenActive()", as well as some way of extending the token timeout length from the default to a couple of hours.

Is anything like this possible?

Thanks :)
Jon.

-----Original Message-----
From: jira-extende...@googlegroups.com [mailto:jira-extende...@googlegroups.com] On Behalf Of Ath

Sent: 18 December 2010 15:28

[Ath]

Hi Jon,

AFAIK, the lifetime of a token can only be sustained if it does some
action at the server. You could build a timer that does just that?
If there's a service method isTokenActive, I've been unable to find
it, but then, I don't need it. My app is just waiting for a message,
then connect, submit and disconnect, as we're only creating new issues
based on data from a 3rd party system, that the standard Jira e-mail
processor can't handle.
If you have a not-so-busy connection/app/service, then disconnecting
between requests would be feasible, if you make many requests, then
the token time-out shouldn't apply...
You could do a simple request to see if the token is still valid,
handle the exception if it isn't and re-connect.

HTH

[Mayer, Jonathan]

Yup, that does sound like a more simple way to tackle the problem. I'll have a play.

Appreciate your input mate.