|
[
Permlink
| « Hide
]
Sarah McGlinchey added a comment - 11/Oct/05 08:38 AM
Is there going to be a timeline set on this issue?
Sarah,
Unfortunately we do not have a delivery data for this issue. As mentioned in teh support request that you have created it is possible to run search requests via HTTP and get results in XML format. We are hoping to add support for Basic Authentication in JIRA 3.4 - Thanks, Also just for reference, the source of the RPC plugin that provides SOAP support in JIRA is free available:
http://confluence.atlassian.com/display/JIRAEXT/JIRA+RPC+plugin 
So if one has the resources in house this feature can be added to JIRA's SOAP API. Anton Is there an ETA on this issue? My company would greatly benefit from this sort of addition . . .
Nick Hi Anton,
Anton I'm currently using the JDBC layer to conduct searches and the SOAP api for updates. I didn't realize it was possible to "run search requests via HTTP and get results in XML format." How is that done? Thanks Hi Wayne,
The easiest way to get the correct URL for your search request is to build the request you are after through the web interface. Once happy, you can copy the 'XML' links URL from the top of the issue navigator page. Submitting this URL will bring back an XML view of your search request. If you have more usage questions please feel free to raise a request at https://support.atlassian.com Hi Dylan,
Thanks for the information. It does work, though the parameters are a bit cryptic. I'm not sure I would know how to derive those parameters without building the query first using the query builder. In this sense I'm not sure it offers much over the existing soap api's getIssuesFromFilter method. Is there any documentation on what those parameters are for the xml query? Wayne Hi Wayne,
At the moment there is no detailed documentation on this. We try to name the parameters such that they make sense. Which part are you finding most confusing? Cheers, A longer term solution we are hoping to provide is to equip JIRA with a query language and allow to execute queries remotely.
At the moment, I do not have the implementation date for this. Hi Anton,
I'm not sure I find it confusing, I just find it difficult to automate. For example if I look for all issues in the atlassian bamboo component, with fix for set to 2.0 and in the open state the xml URL looks like this: Notice that the fixfor variable is set to 12213. How can that be derived in a program? Thanks Hi Wayne,
Would you be able to give me more information as to what needs to be derived? The fact that the Bamboo version named "2.0" has id of 12213? Cheers, Hi Anton,
Yes, that is what I am asking.
If I want to run an XML query from within a program that searches for all issues with a fixfor value of "2.0", how would I know that translates to Thanks May I ask why the discovery of this needs to be dynamic?
Once the Version is created in JIRA its id will never change, so the value can be hardcoded. Otherwise the script will need to pull down versions data from JIRA using SOAP, or screen scrape the information from a place like the Versions Tab: Cheers, OK, I think that answer my question. If you look at my original comment, we use JDBC to query and the soap api to update.
I choose the version field as an example. At the moment we query for all open sub-tasks in a project, but we will probably want to add things like all open issues in a project with a particular fix for version. We also want to query on custom fields, states, date ranges, all kinds of things the soap API does not currently support. One solution is to extend the soap api. Or continue using JDBC for direct SQL access. I was just looking into our options. Thanks Any news on this? When you do a custom search in Jira, are the underlying objects using a specific format for the search, like the XML format discussed above for an http request? It seems to me this would be pretty easy to implement. I really need this for SVN integration!!!!
Hi Tom,
At the moment, we do not have an implementation date for this. I believe the first step would be implementing JRA-1560 and then exposing the solution via RPC. However, JRA-1560 is not planned for JIRA 4.0 as we are addressing 2 most popular feature requests ( Cheers, I think it is important then that when the class is redesigned for JRA-1560, a function to accept the search criteria in XML format is a must. Then implementing this feature would be extremely easy. I think it is also important for a programmer to easily pick up the "options" available for selection. Right now you have to do a call per search item. Returning a single XML with all of them would be easier to deal with when trying to assemble the search criteria.
For example: Projects, Issue Type, Reporter, Assignee, Status, Resolutions, Priorities, etc. They should still all be available separately, but also in one call to make life simple. You make want to break it up for Standard fields and custom fields. It seems to me that adding a method such as
RemoteField[] fields = new RemoteField[]; shouldn't be so hard. Is this part of the general lack of effort on the API, due to other more popular issues, I know, I know Matt,
I have to agree. I was thinking more along the lines of a REST interface with key / value (field name or id / search value) in XML. But adding an API to dis-assemble that information and passing it to the existing capabilities with the Find feature should be straight forward. I understand how they need to balance between what we want added, what is sorely needed in the product, and the complexity of implementing. I think this one is low on the complexity side With respect, I think the HTTP-->XML approach is a hack (deriving version id's is a prime example), and that enabling a general-purpose query function via SOAP is a reasonable request, and would go a long way towards making JIRA viable as a back-end engine. It claims to be a platform, and it comes oh so close, so make it a platform! As it stands, the contortions that appear to be necessary to make a remote call to find "all issues where project=x and version=y and blah blah blah" seem way to painful. Each proposed integration technology doesn't quite make it, and I'm not sure I can get where I need to go even by mixing them together.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Build search queries remotely
