MantisBT - TestLink
View Issue Details
0004700TestLinkRequirement Managementpublic2011-08-15 09:352012-09-01 19:59
normalfeature requestalways
1.9.3 (2011 Q3 - bug fixing) 
1.9.4 (2012 Q3 - bug fixing) 
0004700: Req Search Improvements - search on log message and provide link/url to multiple results
Req Search Improvements - search on log message and provide link/url to multiple results

similar to req spec search
No tags attached.
Issue History
2011-08-15 09:35fmanNew Issue
2011-08-15 09:36fmanAssigned To => fman
2011-08-15 09:36fmanStatusnew => assigned
2011-08-15 09:54fmanNote Added: 0015665
2011-08-15 10:06JulianNote Added: 0015666
2011-08-15 10:10fmanNote Added: 0015667
2011-08-15 10:11fmanProduct Version => 1.9.3 (2011 Q3 - bug fixing)
2011-08-15 11:48JulianNote Added: 0015668
2011-08-15 14:09fmanNote Added: 0015669
2011-08-15 14:13JulianNote Added: 0015670
2011-08-15 14:15JulianNote Edited: 0015670bug_revision_view_page.php?bugnote_id=15670#r1412
2011-08-16 14:29fmanNote Added: 0015673
2011-08-16 14:30fmanNote Added: 0015674
2011-08-16 19:12JulianNote Added: 0015682
2011-08-17 10:02JulianRelationship addedparent of 0004705
2011-08-17 21:28fmanTag Attached: TO BE FIXED on 2.0
2011-09-03 14:34fmanTag Detached: TO BE FIXED on 2.0
2011-09-03 14:40fmanTag Attached: TO BE FIXED on 2.0
2011-09-03 15:53fmanNote Added: 0015793
2011-09-03 15:53fmanTag Detached: TO BE FIXED on 2.0
2012-04-14 17:47fmanStatusassigned => resolved
2012-04-14 17:47fmanFixed in Version => 1.9.4 (2012 Q3 - bug fixing)
2012-04-14 17:47fmanResolutionopen => fixed
2012-09-01 19:59fmanNote Added: 0017346
2012-09-01 19:59fmanStatusresolved => closed

2011-08-15 09:54   
Reminder sent to: Julian

I need your help (or your requirement): search has to be done ONLY at VERSION level or at revisions LEVEL ?

All attributes has to be searched at SAME LEVEL, i.e. can not search on CF at VERSION level, but log message at REVISION level.

please add details in order to allow me to develop this.
2011-08-15 10:06   
>Search has to be done ONLY at VERSION level or at revisions LEVEL ?

is this an OR or can it be done in both ways ?

Example: Search Scope "Tests"

-> Req1:Requirement1 [v1r2] [v2r3] [v2]
-> show "v2" if the matching revision is the last revision of this version

Maybe a checkbox could make the behaviour more clear:

[ ] also consider requirement revisions for search

If it is only possible to search for versions OR revisions i think revisions would be the better choice if we could indicate a last revision of a requirement

For Example: Req1:Requirement1 [v1r2] [v2r3] [v2r5final]
2011-08-15 10:10   
>Search has to be done ONLY at VERSION level or at revisions LEVEL ?
1. SEARCH ONLY on Versions => JUST last revision that lives on REQ_VERSIONS table
2. SEARCH ON ALL revisions => search on REQ_VERSIONS AND REVISIONS tables.

On first implementation I prefer do not add ANY USER CHOICE in way to search.
Right NOW we are doing 1. SEARCH ONLY on Versions.

For output
Req1:Requirement1 [v1r2] [v2r3] [v2r5] WITHOUT the final word
2011-08-15 11:48   
OK, so i would prefer to search versions and revisions but we need to indicate that "a revision is also the final version" otherwise user will not be able to see which revision has "more value" or if there might be a newer revision for this version.

The best usability would indeed have the option where user may decide whether to only search versions OR versions incl. revisions, because i can imagine that many results will be found if revisions are searched.

Use Case:
Each version of a requirement is used for imnplementing the feature:
Requirement "Video-Codec support" for a multimedia player:
V1: implement support for XVID
V2: implement support for MKV
V3: implement support for ...

I think in most cases for tracability the last revision holds the most important information, but there might also be reasons to search on revision level too (who did add the wish to support multiple audio lines for MKV -> revision would hold that information)

So in general i do think this checkbox is a good idea.

Let me know what you think.
2011-08-15 14:09   
>> Let me know what you think
that i hate lot of user choice because make development and user interface very complicated.
Once you add option on one place you end having to rework lot of other features for pressures on same option be added.

I will try to see what can be done.

Just for the records: on req spec search there is no final word in any place. then ? we need to add it ?
2011-08-15 14:13   
(edited on: 2011-08-15 14:15)
You mean to indicate that it is the last available revision ?
Good idea... but there we cannot call it final as a new revision still can be created.

If we add a unique string to indicate "final requirement version revisions" and "last requirement specification revisions" we can use exttable feature to filter by this string -> we do not need the checkbox i mentioned because an acceptable workaround using existing features exist.

2011-08-16 14:29   
1.9 [^]
2011-08-16 14:30   
Reminder sent to: Julian

can you do some tests ?
I have done just few quick tests (I'm becoming lazy tester)
NOTHING done for the final word (need to be talked again)
2011-08-16 19:12   
i will do more intense tests tomorrow.

first quick check:

1. why is the order displayed this way:
[v:1 r:2] [v:1 r:1] = descending
-> on req spec search: (rev:1) (rev:2) = ascending

2. i would prefer this format: [v1r1] because less space wasted and we use this notation already on diff page:
"Differences between version 1 revision 1 (v1 r1) and version 1 revision 2 (v1 r2) of requirement Req1 : Req1" -> do not think space between version and revision is needed
2011-09-03 15:53   
2.0 [^]
2012-09-01 19:59   
1.9.4 released