|Anonymous | Login | Signup for a new account||2019-02-16 20:25 UTC|
|Main | My View | View Issues | Change Log | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006920||TestLink||Bug Tracking System - JIRA Integration||public||2015-01-31 12:48||2015-04-13 17:53|
|Priority||normal||Severity||feature request||Reproducibility||have not tried|
|Product Version||1.9.12 (2014 Q3)|
|Fixed in Version||1.9.14 (2015 Q3)|
|Summary||0006920: Allow JIRA REST has similar configuration as JIRA SOAP|
|Description||In JIRA REST interface, it only allows to configure projectkey, issuetype, etc. It would be more powerful to allows this interface to configure affectsVersions, customField as well.|
Initial modification attached (tested). Hope it helps.
|Tags||No tags attached.|
|QA Team - Task Workflow Status||READY FOR TESTING|
|Attached Files||jirarestInterface.class.zip [^] (11,753 bytes) 2015-02-01 05:40|
|I am sorry that I forgot to remove another feature from this modification. Will try to do that later.|
Please provide comments on code regarding what TICKET is related to changes
without user documentation (minimal) nobody is going to be able to use this
|Category is wrong|
edited on: 2015-01-31 17:35
1. Please always check the TICKET with Available fixes
2. Always do searches without HIDE STATUS filter set
3. due to features
0006867 closed fman JIRA REST - getIssueTypes() [Delete]
0006870 closed fman JIRA REST - getComponents() [Delete]
0006868 closed fman JIRA REST - getPriorities() [Delete]
0006869 closed fman JIRA REST - getVersions() [Delete]
0006866 closed fman JIRA REST API - Dynamic configuration to tracker management [Delete]
# , IMHO this implementation can be avoided.
Check always the main 3 channels for info
Mantis, forum, twitter
I did check fix for these tickets, however, this doesn't work for my case.
In our setup, there are some mandatory fields configured in JIRA, for instance, versions and some custom fields, etc. We have to have some static configuration interface for these fields and the config file is a good choice. If we use the dynamic configuration, we have to change the TestLink GUI to set values for these mandatory fields. Giving that different companies may have different mandatory fields, it may be more flexible to config it in the configuration file, just like TestLink did for JIRA SOAP interface.
|I update the code and attached it in jirarestInterface.class.zip. The new code would allow user to configure any REST fields in the config file. So now user can use "name" for these fields, instead of "id" since it's quite hard for user to get "id" for some JIRA fields.|
|The template has also been modified to guide user to set multi-selection field and single-selection field in xml format.|
>> So now user can use "name" for these fields, instead of "id" since it's quite hard for >> user to get "id" for some JIRA fields.
can you provide example please ?
From what I've seen:
" <issuetype><name>Type Name</name></issuetype>\n" .
" <!-- Critical: Placeholder <versions></versions> at the end is required to indicate \n" .
" that this is a field can be assigned multiple values -->\n" .
" <versions><name>Affects Version Name</name></versions><versions></versions>\n" .
" <!-- Critical: Placeholder <customfield_10081></customfield_10081> at the end is \n" .
" required to indicate that this custom field can be assigned with multiple values -->\n" .
" <customfield_10081><value>Field Value</value></customfield_10081><customfield_10081></customfield_10081>\n" .
" <customfield_10009><value>Field Value</value></customfield_10009>\n" .
"</fields> \n" .
for customs fields still codes are used.
Then where is the improvement?
edited on: 2015-02-01 09:42
For custom field in REST interface, "value" is actually "name" while "id" is the database id.
<!-- Template jirarestInterface -->
<!-- Hardware Version Used -->
<!-- Previous Result: Allowed values are: 10035[Passed], 10036[Failed], 10037[New Test], 10038[Unknown], 10039[Not Applicable]-->
<!-- Test Type: Allowed values are: 10032[Ad Hoc test], 10497[Automated test], 10033[Customer/ISV reported], 10496[Test case], 10034[Other] -->
<!-- Non-compliance: Allowed values are: 10160[System Requirements], 10161[Intended Behavior] -->
<!-- Team Found: 10015[DVT], 10024[Field Trial], 10122[SI&T]-->
|I see your point. You mean the field itself not the value assigned to it. For instance, customfield_10009. Yes, I haven't figure out to use the "field display name" instead of the field name specified by REST interface. I assume that will not happen since "field display name" can be duplicated.|
That's why I explain always that sentence like ' .... So now user can use "name" for these fields, instead of "id" since it's quite hard for user to get "id" for some JIRA fields.... '
need IMHO be written in a different way, because tend to create the sensation that developer has done a lazy work.
Things can always be improved, but in some circunstances, is not a terrible problem that codes/id are used instead of verbose strings.
All depends always on amount of work to do, available doc, and so on to get a result.
I appreciate your help/collaboration.
Thanks for helping on clarification.
The actual improvement here is that this modification would allow user to pre-configure any fields presented on JIRA REST interface in a static way. This could be helpful if there are some mandatory/required fields during creating a JIRA issue.
The idea of using "Dynamic configuration" is a very great idea. However, looks like the current implementation on "6866 closed fman JIRA REST API - Dynamic configuration to tracker management" only supports to configure affect versions, components, priorities, etc. It would be more helpful to tell the user which fields are mandatory and provide them with a way to configure them dynamically. Looks like this can be achieved with "createmeta" method presented on https://developer.atlassian.com/display/JIRADEV/JIRA+REST+API+Example+-+Create+Issue. [^] It can return the mandatory (JIRA called "required") fields and possible options to user to dynamically configure the REST interface during creating an issue.
|2015-01-31 12:48||swang3||New Issue|
|2015-01-31 12:48||swang3||File Added: jirarestInterface.class.php|
|2015-01-31 12:50||swang3||File Added: jirarestInterface.class.php.html|
|2015-01-31 12:53||swang3||Note Added: 0022597|
|2015-01-31 17:03||fman||Note Added: 0022598|
|2015-01-31 17:29||fman||Note Added: 0022599|
|2015-01-31 17:29||fman||QA Team - Task Workflow Status||=> TBD|
|2015-01-31 17:29||fman||Category||API - REST => Bug Tracking System - JIRA Integration|
|2015-01-31 17:34||fman||Note Added: 0022600|
|2015-01-31 17:35||fman||Note Edited: 0022600||View Revisions|
|2015-01-31 17:36||fman||Note View State: 0022600: public|
|2015-01-31 17:36||fman||Status||new => feedback|
|2015-02-01 05:37||swang3||Note Added: 0022602|
|2015-02-01 05:37||swang3||Status||feedback => new|
|2015-02-01 05:40||swang3||File Added: jirarestInterface.class.zip|
|2015-02-01 05:43||swang3||Note Added: 0022603|
|2015-02-01 05:45||swang3||Note Added: 0022604|
|2015-02-01 09:22||fman||Note Added: 0022607|
|2015-02-01 09:23||fman||Assigned To||=> fman|
|2015-02-01 09:23||fman||Status||new => feedback|
|2015-02-01 09:23||fman||File Deleted: jirarestInterface.class.php.html|
|2015-02-01 09:23||fman||File Deleted: jirarestInterface.class.php|
|2015-02-01 09:42||swang3||Note Added: 0022608|
|2015-02-01 09:42||swang3||Status||feedback => assigned|
|2015-02-01 09:42||swang3||Note Edited: 0022608||View Revisions|
|2015-02-01 09:53||swang3||Note Added: 0022610|
|2015-02-01 16:39||fman||Note Added: 0022612|
|2015-02-02 05:53||swang3||Note Added: 0022618|
|2015-04-09 18:17||fman||Issue cloned: 0007050|
|2015-04-09 18:17||fman||Relationship added||related to 0007050|
|2015-04-13 17:53||fman||QA Team - Task Workflow Status||TBD => READY FOR TESTING|
|2015-04-13 17:53||fman||Status||assigned => closed|
|2015-04-13 17:53||fman||Resolution||open => fixed|
|2015-04-13 17:53||fman||Fixed in Version||=> 1.9.14 (2015 Q3)|
|Copyright © 2000 - 2019 MantisBT Team|