|Anonymous | Login | Signup for a new account||2018-03-18 07:51 UTC|
|Main | My View | View Issues | Change Log | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0008180||TestLink||Bug Tracking System - Redmine Integration||public||2018-01-16 10:50||2018-02-24 15:43|
|Product Version||1.9.16 (2016 Q4)|
|Fixed in Version||1.9.17 (2018 Q1)|
|Summary||0008180: Support dynamic values in the custom fields for Redmine for issue creation|
|Description||We would like to use some custom fields in redmine for some test case execution informations: build, platform etc.|
The feature http://forum.testlink.org/viewtopic.php?f=55&t=7779 [^] allows us to use redmine issue description field for that, but it is not so good for reporting/analysing etc.
Our idea is to use the same placeholders as in the mentioned feature description from for forum with some more placeholders for values without labels:
In the static configuration section for custom fields of redmine the mentions placeholders can be used for values.
So we get our test case execution properties automatically into redmine at the issue creation.
|Steps To Reproduce||Sample configuration for redmine custom fields on testlink side:|
<custom_field id="19" name="Testlink Build">
|Additional Information||Implemented in two commits:|
The first commit unfortunately is combined with another feature (always adding two links to TestLink at creating issue in bugtracking system instead of one - direct link to execution report was added in addition to the link to test case execution)
|Tags||No tags attached.|
|QA Team - Task Workflow Status||READY FOR TESTING|
Please provide clear distinct PULL REQUEST, in order to allow a CLEAR HISTORY of commits on the base code LOG.
I do not think that will be a lot difficult for you
Thanks a lot
edited on: 2018-01-17 07:31
For someone experienced with git its not as hard to use the infos. I have to find time to do extra work.
The issue here is that our commits have to be splitted and that some of changes are based on the other ones. I had to reimplement the changes to split them correctly. It tooks time and brings no gain for us. If you would want to accept both changes, than it would be much easier. Otherwise the separate pull requests would also conflict with one another.
>> For someone experienced with git its not as hard to use the infos. I have to find time to do extra work.
Ok, I understand you do not want to help more than this, but next time think about using a better workflow that will made integration easier.
Same keys used for replacement on notes (original implementation), and for Custom Fields for Redmine, except EXECNOTES
Need to be tested
|2018-01-16 10:50||kostgr_2||New Issue|
|2018-01-16 23:15||fman||Note Added: 0027155|
|2018-01-17 07:31||kostgr_2||Note Added: 0027160|
|2018-01-17 07:31||kostgr_2||Note Edited: 0027160||View Revisions|
|2018-01-17 09:44||fman||Note Added: 0027161|
|2018-01-20 19:08||fman||Relationship added||related to 0006864|
|2018-01-20 20:28||fman||Note Added: 0027164|
|2018-01-20 20:28||fman||Assigned To||=> fman|
|2018-01-20 20:28||fman||Status||new => work in progress|
|2018-01-20 20:28||fman||QA Team - Task Workflow Status||=> TBD|
|2018-01-20 20:28||fman||Product Version||=> 1.9.16 (2016 Q4)|
|2018-02-24 15:42||fman||Status||work in progress => assigned|
|2018-02-24 15:42||fman||QA Team - Task Workflow Status||TBD => READY FOR TESTING|
|2018-02-24 15:42||fman||Status||assigned => resolved|
|2018-02-24 15:42||fman||Fixed in Version||=> 1.9.17 (2018 Q1)|
|2018-02-24 15:42||fman||Resolution||open => fixed|
|2018-02-24 15:43||fman||Relationship added||child of 0007817|
|Copyright © 2000 - 2018 MantisBT Team|