DOORS Version: 9.5.2.1
I'll try to break this down as simple as I can. First, I'll start with the data. Assume I have a module, Module, in DOORS. Module is comprised of:
Tree Structure
Assume that Object Text for headings and sub-headings are blank, and assume Object Text for the remaining Level 3 objects is the same as the name of the object itself. For example, Object Heading is blank for Object_1.1.0-1, but its Object Text is "Object_1.1.0-1".
- Module
- 1 Heading1 // Object Heading: "Heading1" ; Object Number: 1
| - 1.1 Sub-Heading1.1 // Object Heading: "Sub-Heading1.1" ; Object Number: 1.1
| | + Object_1.1.0-1 // Object Heading: "" ; Object Number: 1.1.0-1
| | + Object_1.1.0-2 // Object Heading: "" ; Object Number: 1.1.0-2
| | | .
| | | .
| | | .
| | + Object_1.1.0-A // Object Heading: "" ; Object Number: 1.1.0-A
| |
| - 1.2 Sub-Heading1.2 // Object Heading: "Sub-Heading1.2" ; Object Number: 1.2
| + Object_1.2.0-1 // Object Heading: "" ; Object Number: 1.2.0-1
| + Object_1.2.0-2 // Object Heading: "" ; Object Number: 1.2.0-2
| | .
| | .
| | .
| + Object_1.2.0-B // Object Heading: "" ; Object Number: 1.2.0-B
|
- 2 Heading2 // Object Heading: "Heading2" ; Object Number: 2
- 2.1 Sub-Heading2.1 // Object Heading: "Sub-Heading2.1" ; Object Number: 2.1
| + Object_2.1.0-1 // Object Heading: "" ; Object Number: 2.1.0-1
| + Object_2.1.0-2 // Object Heading: "" ; Object Number: 2.1.0-2
| | .
| | .
| | .
| + Object_2.1.0-C // Object Heading: "" ; Object Number: 2.1.0-C
|
- 2.2 Sub-Heading2.1 // Object Heading: "Sub-Heading2.1" ; Object Number 2.2
+ Object_2.2.0-1 // Object Heading: "" ; Object Number: 2.2.0-1
+ Object_2.2.0-2 // Object Heading: "" ; Object Number: 2.2.0-2
| .
| .
| .
+ Object_2.2.0-D // Object Heading: "" ; Object Number: 2.2.0-D
And so on and so forth . . .
Attributes
*Object Heading and Text*, Version, Data
Object Heading and Text seems to be a DOORS thing, so I won't explain that here. Data here is generic (and, in reality, represents more than one attribute). Some data is applicable to some versions while other data is applicable to other versions. The data for different versions may intersect while some data for other versions are mutually exclusive. Version is a single string that delimits the different versions by new lines, "\n". So, let's assume that Version is:
v1\nv2\nv3 . . . v\nvX
or, in a more readable format:
v1
v2
v3
.
.
.
vX
What's more, Version for one object may be (comma-separated here for readability) v1, v2, v3, . . ., vX while for another it might be v1, v3 and for another perhaps just v2. Any combination of available versions, really.
The Problem
What I'm attempting to do seems to me like it should be easy. A no-brainer. Just to pick an example, let's say I want to apply a filter whereby I view only Sub-Heading1.2 and its children, and that only for Version v3. I've tried many variations on the theme, but I can only seem to accomplish one or the other. Either I successfully isolate data for a single section or a single version, but I cannot get both. When I apply a filter for a single section, say Sub-Heading1.2 and its children, and then AND that with "includes v3"; I will get that section, but it refuses to show only that section only for v3.
In any programming language, a and b and c evaluates to true IF AND ONLY IF a and b and c. What I'm seeing in DOORS seems to me to be more like (a and b) or c.
With a DOORS database described as above, how can I view only the objects in a given range (or an object and its descendants) only for a given version? I know DXL exists as a potential solution, but a GUI solution is preferable.
Your issue is
Include Descendants
. This options specifically ignores the filter. What it is really saying is, "Show me everything that matches my filter, and all of their descendants".Using your example above, what you want for a filter is:
This will give you what you are looking for. Be sure NOT to
Include Descendants
as this will negate the second rule in the filter.Good luck!