|Anonymous | Login | Signup for a new account||2020-05-26 10:16 UTC|
|Main | My View | View Issues | Change Log | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000834||TestLink||Test Specification||public||2007-05-07 17:28||2012-10-23 18:09|
|Product Version||1.7.0 RC 2|
|Fixed in Version|
|Summary||0000834: Option to fill DOC-ID with automatically generated ID|
|Description||The DOC-ID must be filled in by TestLink itsel, using a unique number. Optional a template could be used, to make it possible to generate numbers like "USREQ-0023"|
|Additional Information||When testcases are created, Testlink gives the testcases automatically a number. But the DOC-ID used in the Requirement Specification must be filled in by the user. When Teslink generates the DOC-ID, the user doesn't have to worry about how to create a unique DOC-ID.|
|Tags||No tags attached.|
|QA Team - Task Workflow Status||TBD|
doc-id can be some external id, that user must have the possibility to assign it.
Your request can be add as a configuration option, with default feature the actual behaviour
It make sense for me.
DOC-ID could be filled automatically based on TL configured prefix (by default REQ) + project prefix + unique number. The implementation could be similar TCs.
User overwrite this generated ID of course.
There is a minor issue regarding this implementation that need to be clarified:
If we want to use same pattern that for test cases, a new counter must be added to test project, but in this way this UNIQUE NUMBER will be incremented each time a requirement will be created no matter inside what REQ SPEC on tree.
is this ok ?
Another question: if feature must be simple this counter will be increased NO MATTER is user uses or not this generated doc id.
is this a problem '
When this two details will be clarified development can be done
Reminder sent to: mhavlat
your check and comments of last note is needed
edited on: 2010-03-03 20:35
In my eyes there are only 2 solutions for this issue:
Solution 1: (dirty)
using id of requirements table (controlled by nodes_hierarchy)
-> there will be gaps in the numbering of auto generated ids
step 1: User creates requirement: REQ-ProjectPrefix-1
step 2: User creates test case: ProjectPrefix-1
step 3: User creates another requirement: REQ-ProjectPrefix-3 (here internal id has been incremented because of test case creation)
Solution 2: (clean)
adding an external id like used for test cases
-> no gaps in numbering but another DB id to handle
Constraint (has to be handled for solution2):
There will be a problem when switchting between "auto-generated-IDs" and "manually-generated-IDs"
User starts writing Requirements in default mode ("manually-generated-IDs"). He creates 3 Reqs with those ReqDocIDs:
Req1, Req2, ReqABC
Then user wants to use "auto-generated-IDs"
He creates another 2 Reqs with those Auto generated ids:
-> the whole set of req_doc_ids would be: Req1, Req2, ReqABC, Req-TestprojectPrefix-23, Req-TestprojectPrefix-25
Solution for Constraint:
Both fields "external_id" and "req_doc_id" have to be filled no matter what mode is chosen (auto or manual ids)
If mode = auto-generated-IDs:
1. set external_id AND req_doc_id to the same value
2. show ONLY external ids on requirement tree and in req-documents (but on GUI call it req_doc_id)
3. Do NOT allow to change "req_doc_id" (in this case external_id) on gui
If mode = manually-generated-IDs:
1. set external_id as on auto-generated-IDs mode AND set req_doc_id to manual chosen value
2. Show ONLY req_doc_id on requiurement tree and in req-documents
3. Allow to change req_doc_id
-> Switching from one mode to the other will work fine.
1. Switching from "auto-generated-IDs" to "manually-generated-IDs" will show auto generated ids (stored in req_doc_id) for requirements created before switching but can be changed manually
2. Switching from "manually-generated-IDs" to "auto-generated-IDs" will show auto generated ids (stored in external_id) for requirements created before switching but can be changed manually
My advice: Implement solution2 or reject this issue
|Please keep in mind that requirement specifications do now also have a DOC ID.|
|I like solution 2|
|I like solution 2 also... IMHO this is an essential feature for TestLink to make the requirements functionality usable. While manually entering a doc id may be useful in some cases, the current behaviour of forcing users to always enter their own doc id (which requires them to use a consistant format and remember what id's have already been used) is not practical.|
>> IMHO this is an essential feature for TestLink to make
>> the requirements functionality usable
Feature is usable, because req management was thinked as a way to integrate in a ligth form with Req Mgt Systems.
>> which requires them to use a consistant format and remember what id's have
>> already been used) is not practical.
same effort is required when creating any other kind of item like test suite, test plan etc.
Current solution is simple and flexible.
May be in future releases we can consider implement this.
Right now is out of scope for release 1.9
edited on: 2010-09-15 13:31
how about a little improvement:
DocID field could be filled with latest added req doc id for this project. (must be enabled via config)
User1 creates req with Document ID "REQ-1"
User2 wants to create another req
1. Field Document ID can be filled with "REQ-1"
implemented with issue 0003777
|I think that would be very confusing. I think an auto-filled value should be one that could be used without any modification by the user.|
please check this issue.
Target Version 2.1 and later (planned)
the change is no solution but a workaround.
Any news in the testlink team on this?
A good way of doing this would be that the requirements specification has a prefix and all subsequent requirements get a number relatively to this.
I.e. requirements specification - prefix "myReqSpec" --
all subsequent specs in this reqSpec would be called
"myReqSpec_1, myReqSpec_2" or the number itself could just be an automatically created arbitrary number as "myReqSpec_25478"
|2007-05-07 17:28||remco_nl||New Issue|
|2007-05-08 16:35||fman||Note Added: 0001644|
|2007-05-08 16:36||fman||Summary||DOC-ID must be filled in by TestLink => Option to fill DOC-ID with automatically generated ID|
|2009-02-26 16:44||mhavlat||Note Added: 0005643|
|2009-02-26 16:44||mhavlat||Status||new => acknowledged|
|2009-02-26 18:43||fman||Status||acknowledged => assigned|
|2009-02-26 18:43||fman||Assigned To||=> fman|
|2010-03-01 01:53||fman||Note Added: 0009249|
|2010-03-01 01:53||fman||Note Added: 0009250|
|2010-03-03 04:38||fman||Relationship added||has duplicate 0003238|
|2010-03-03 19:50||Julian||Note Added: 0009280|
|2010-03-03 19:52||Julian||Note Edited: 0009280|
|2010-03-03 20:35||Julian||Note Edited: 0009280|
|2010-03-04 02:16||Julian||Note Added: 0009284|
|2010-03-15 22:08||Julian||Relationship added||has duplicate 0003284|
|2010-03-16 00:50||bchabot||Note Added: 0009405|
|2010-06-15 21:59||NivlacNZ||Note Added: 0010320|
|2010-06-16 08:49||fman||Note Added: 0010328|
|2010-09-15 09:28||Julian||Note Added: 0011367|
|2010-09-15 11:54||Julian||Relationship added||parent of 0003777|
|2010-09-15 13:31||Julian||Note Edited: 0011367||View Revisions|
|2010-09-15 15:55||howea||Note Added: 0011369|
|2010-09-15 17:35||Julian||Note Added: 0011375|
|2011-04-15 17:26||Julian||Relationship added||has duplicate 0002315|
|2011-04-21 08:28||Julian||Relationship added||has duplicate 0004434|
|2012-10-23 15:44||medienwolf||Note Added: 0017720|
|2012-10-23 18:09||fman||Task Workflow Status||=> TBD|
|Copyright © 2000 - 2020 MantisBT Team|