Mantis Bugtracker          
testlink.org

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000834TestLinkTest Specificationpublic2007-05-07 17:282012-10-23 18:09
Reporterremco_nl 
Assigned Tofman 
PrioritynormalSeverityfeature requestReproducibilityalways
StatusassignedResolutionopen 
PlatformOSOS Version
Product Version1.7.0 RC 2 
Fixed in Version 
Summary0000834: Option to fill DOC-ID with automatically generated ID
DescriptionThe 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 InformationWhen 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.
TagsNo tags attached.
Database (MySQL,Postgres,etc)
Browser
PHP Version
TestCaseID
QA Team - Task Workflow StatusTBD
Attached Files

- Relationships
parent of 0003777closedJulian Allow to insert last req doc id when creating requirement in Document ID field for consecutive numbering 
has duplicate 0003238closedfman Option to generate Document IDs automatically 
has duplicate 0003284closedfman Auto Id for Requirement 
has duplicate 0002315closedfman Field 'Document ID' for Requirement 
has duplicate 0004434closed Autonumber for Document ID 

-  Notes
(0001644)
fman (administrator)
2007-05-08 16:35

IMHO:
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
(0005643)
mhavlat (reporter)
2009-02-26 16:44

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.
(0009249)
fman (administrator)
2010-03-01 01:53

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
(0009250)
fman (administrator)
2010-03-01 01:53

Reminder sent to: mhavlat

your check and comments of last note is needed
thanks
(0009280)
Julian (reporter)
2010-03-03 19:50
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

Example:
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)
-> GAP!


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"

Example:
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:
Req-TestprojectPrefix-23, Req-TestprojectPrefix-25

-> 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

(0009284)
Julian (reporter)
2010-03-04 02:16

Please keep in mind that requirement specifications do now also have a DOC ID.
(0009405)
bchabot (reporter)
2010-03-16 00:50

I like solution 2
(0010320)
NivlacNZ (reporter)
2010-06-15 21:59

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.
(0010328)
fman (administrator)
2010-06-16 08:49

>> 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
(0011367)
Julian (reporter)
2010-09-15 09:28
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)

Example:
User1 creates req with Document ID "REQ-1"

User2 wants to create another req
1. Field Document ID can be filled with "REQ-1"

//edit:
implemented with issue 0003777

(0011369)
howea (reporter)
2010-09-15 15:55

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.
(0011375)
Julian (reporter)
2010-09-15 17:35

please check this issue.
Target Version 2.1 and later (planned)

the change is no solution but a workaround.
(0017720)
medienwolf (reporter)
2012-10-23 15:44

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"

- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker