Mantis Bugtracker          
testlink.org

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004700TestLinkRequirement Managementpublic2011-08-15 09:352012-09-01 19:59
Reporterfman 
Assigned Tofman 
PrioritynormalSeverityfeature requestReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version1.9.3 (2011 Q3 - bug fixing) 
Fixed in Version1.9.4 (2012 Q3 - bug fixing) 
Summary0004700: Req Search Improvements - search on log message and provide link/url to multiple results
DescriptionReq Search Improvements - search on log message and provide link/url to multiple results

similar to req spec search
TagsNo tags attached.
Database (MySQL,Postgres,etc)Any
Browser
PHP Version
TestCaseID
QA Team - Task Workflow Status
Attached Files

- Relationships

-  Notes
(0015665)
fman (administrator)
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.
regards
(0015666)
Julian (reporter)
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]
(0015667)
fman (administrator)
2011-08-15 10:10

>Search has to be done ONLY at VERSION level or at revisions LEVEL ?
Means
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
(0015668)
Julian (reporter)
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.
(0015669)
fman (administrator)
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 ?
(0015670)
Julian (reporter)
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.

(0015673)
fman (administrator)
2011-08-16 14:29

1.9
http://gitorious.org/testlink-ga/testlink-code/commit/b799a4d3d1b3e66e115b63bb39ddc1ce9b77218c [^]
(0015674)
fman (administrator)
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)
(0015682)
Julian (reporter)
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
(0015793)
fman (administrator)
2011-09-03 15:53

2.0
http://gitorious.org/testlink-ga/testlink-code/commit/6e30bbff183df71659ad1f08774410730572ecf2 [^]
(0017346)
fman (administrator)
2012-09-01 19:59

1.9.4 released

- Issue History
Date Modified Username Field Change
2011-08-15 09:35 fman New Issue
2011-08-15 09:36 fman Assigned To => fman
2011-08-15 09:36 fman Status new => assigned
2011-08-15 09:54 fman Note Added: 0015665
2011-08-15 10:06 Julian Note Added: 0015666
2011-08-15 10:10 fman Note Added: 0015667
2011-08-15 10:11 fman Product Version => 1.9.3 (2011 Q3 - bug fixing)
2011-08-15 11:48 Julian Note Added: 0015668
2011-08-15 14:09 fman Note Added: 0015669
2011-08-15 14:13 Julian Note Added: 0015670
2011-08-15 14:15 Julian Note Edited: 0015670 View Revisions
2011-08-16 14:29 fman Note Added: 0015673
2011-08-16 14:30 fman Note Added: 0015674
2011-08-16 19:12 Julian Note Added: 0015682
2011-08-17 10:02 Julian Relationship added parent of 0004705
2011-08-17 21:28 fman Tag Attached: TO BE FIXED on 2.0
2011-09-03 14:34 fman Tag Detached: TO BE FIXED on 2.0
2011-09-03 14:40 fman Tag Attached: TO BE FIXED on 2.0
2011-09-03 15:53 fman Note Added: 0015793
2011-09-03 15:53 fman Tag Detached: TO BE FIXED on 2.0
2012-04-14 17:47 fman Status assigned => resolved
2012-04-14 17:47 fman Fixed in Version => 1.9.4 (2012 Q3 - bug fixing)
2012-04-14 17:47 fman Resolution open => fixed
2012-09-01 19:59 fman Note Added: 0017346
2012-09-01 19:59 fman Status resolved => closed



Copyright © 2000 - 2018 MantisBT Team
Powered by Mantis Bugtracker