Logo etsi

ETSI's Bug Tracker
Main | My View | View Issues | Change Log | Roadmap | Monitor project
  
Notice: information submitted on the ETSI issue Tracker may be incorporated in ETSI publication(s) and therefore subject to the ETSI IPR policy.

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006088Part 01: TTCN-3 Core LanguageNew Featurepublic16-05-2012 12:2809-08-2012 13:57
ReporterJacob Wieland - Spirent 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Summary0006088: superset/subset/permutation/complement should also be possible with dynamic lists
DescriptionAt the moment, the superset/subset constructions are very restricted in their usefulness as the number of different templates, i.e. the size of the set to be matched against, given to them need to be known already statically.

However, there are situations where the set to be matched against can only be determined dynamically during the course of a testcase. For this, in current TTCN-3, complex for-if-match constructions need to be used to replace simple subset/superset expressions to arrive at the same semantic result.

While it is possible to extract such matching constructs into functions, these have the drawbacks that they cannot be used as matching mechanisms and also need to be type-safe (so they need to be redefined for every set element type or using generics).

To amend these drawbacks, the following construct could be introduced:

subset <set_of_elements>

where <set_of_elements> is a list value or template (i.e. of a record of or set of type of the element type of the subset construct).

Examples:

subset { 1, 2, 3 } is the same as subset (1, 2, 3)

type set of integer int_list;

function is_subset(int_list numbers1, template int_list numbers2) return boolean {
  return match(numbers1, subset numbers2);
}

function is_element(integer num, int_list numbers) return boolean {
   return match({num}, subset numbers2);
}

function equals(int_list numbers1, int_list numbers2) return boolean {
  return
    match(numbers1, subset numbers2) and
    match(numbers1, superset numbers2);
}

Restrictions:

If a template is given to the subset/superset matching mechanism as argument, the template shall not resolve to the matching mechanisms Any, complement, subset, superset (basically, only an actual list of templates is allowed).

The matching mechanism AnyElementsOrNone directly inside the set-of template given to subset/superset is not allowed.

For consistency's sake, all similar constructions (i.e. permutation/complement, the 'from' clause in receive statements and the 'to' clause in send statements) should also allow such dynamic list templates.
TagsNo tags attached.
Clause Reference(s)B.1.2.2, B.1.2.6, B.1.2.7
Source (company - Author)Testing Technologies - Jacob Wieland
Attached Filesdoc file icon CR_6088.doc [^] (80,384 bytes) 11-07-2012 09:08
doc file icon CR_6088_v2.doc [^] (118,784 bytes) 11-07-2012 15:53
doc file icon CR_6088_v3.doc [^] (141,312 bytes) 12-07-2012 09:14
doc file icon CR_6088_v4.doc [^] (146,944 bytes) 12-07-2012 12:02
doc file icon CR_6088_v5.doc [^] (147,456 bytes) 12-07-2012 17:38
doc file icon CR_6088_v6.doc [^] (130,048 bytes) 12-07-2012 18:01
doc file icon CR_6088_v7.doc [^] (137,216 bytes) 13-07-2012 15:22
doc file icon CR_6088_v8doc.doc [^] (144,896 bytes) 09-08-2012 13:39

- Relationships
related to 0006165closed Add recof2setof predefined function 

-  Notes
(0010724)
Gyorgy Rethy (reporter)
09-07-2012 16:58

 In general I agree. As subset/superset can be used for set ofs, permutation for record ofs, complement to any type, the simple syntax subset mytemplate (if e.g. mytemplate is a record of) may cause confusions. I propose to identify at the syntactical level that this construct is using only the elements of the argument, e.g.

subset all from mytemplate;
subset (5, all from mytemplate, 7);
permutation (3, all from mytemplate);

A little bit longer syntactically but more readable and more clearly reflects the intention.
(0010743)
Gyorgy Rethy (reporter)
10-07-2012 11:53

 STF discussion 2012-07-10:
Proposal agreed in principle, work out a proposed text.
(0010750)
Jacob Wieland - Spirent (reporter)
10-07-2012 12:53

 I think the "all" is confusing in this construct, as in a subset, only some of the elements from the list should be in the matching template.

Thus, I propose either to take only the from, i.e.

subset from X, superset from X (would be mz favourite, also shorter)

or

subset any from X / superset all from X

The additional mix-syntax is unnecessary, as it can easily be done by using
the & operator, i.e.

subset from { 5, 7 } & mytemplate

permutation from { 3 } & mytemplate
(0010771)
Gyorgy Rethy (reporter)
10-07-2012 15:08

 actually "all" means that all elements of the referenced template is used in the subset/superset etc. for example:
type record of integer ROI;
template ROI t_roi := { 1,2,3}

template SOI t_roi:= subset all from t_roi; //is equivalent to subset (1,2,3), i.e. all elements of t_roi became elements of t_soi.

this will match of course values {1}, {1,2}... etc.
(0010773)
Jacob Wieland - Spirent (reporter)
10-07-2012 18:08

 I understand, but I think it is not intuitive language-wise and therefore confusing. Using only the 'from', less so - at least to me.
(0010789)
Tomas Urban (developer)
11-07-2012 09:20

 I added a draft of core language specification changes. From the number of proposals we picked the one that uses the "all from" inside parentheses, e.g. subset(all from t1, 1, 2). There are several reasons for this solution:
1. The syntax remains very similar to the original one
2. It can be used for template lists too, e.g.: (1, 2, all from t2)
3. It has a good readability meaning "include all elements from the source template"
4. We don't have to deal with the problem whether "from" should be preceded by any, all or nothing in the proposed shorthand form of the notation.

--> assigned to Jens for review
(0010824)
Jacob Wieland - Spirent (reporter)
11-07-2012 10:57

 I actually cannot think of a use case where the mixed notation would be necessary. In my experience either the whole dynamic list is to be used as the basis for subset/superset or a fixed list (as we can do now).

If the mixed notation shall be used, then I would opt for 'all X' instead of 'all from X', as it is shorter and has the same intuition.
(0010827)
Jens Grabowski (manager)
11-07-2012 11:14

 For me "all from" is as expressive as "all". However, in any case the meaning of "all from" or "all" needs to be explained informally in Clause 15.7.2. Apart from this, I am fine with the text.
(0010829)
Jacob Wieland - Spirent (reporter)
11-07-2012 11:23

 In the examples for subset/superset, the paranthesis is missing, though the syntax allows the construct only with paranthesis.
(0010836)
Gyorgy Rethy (reporter)
11-07-2012 14:03

 1) Actually one may want to compose a list from more than one list variables. Also, it is quite possible to have a mixed case, when some of the elements are static (e.g. IDs assigned by the user are known in beforehand) and some are dynamic (IDs assigned by the network). So, the possibility to refer to the elements of a list inside a () is useful.

2) Add also permutation to the resolution.

3) "all t_mytemplate" is not expressive to me at all, it would not be intuitive for the users. We should go either for "all from" or "from" to have an intuitive syntax.
(0010839)
Tomas Urban (developer)
11-07-2012 15:59

 I made several changes according to your requests:
1. The chapter on permutations was added
2. I added a note to the chapter 15.7.2 explaining the basic principle of the "all from" clause, but the reader still has to refer to Annex B to find out all the details. I hope it is fine.
3. I switched on change tracker
4. I added parenthesis to the superset and subset examples

There's two changes in the BNF too. Superset, subset and template list can contain one element only if it is all from. And complemented list template BNF was accidentally left unchanged.
(0010857)
Gyorgy Rethy (reporter)
12-07-2012 09:15
edited on: 12-07-2012 09:26

 I have made some editorial changes in CR_6088_v3.doc to better express that individual elements and all from references can be mixed and some other minor editorials.

Some restrictions could need further considerations. For example, permutation may contain AnyElementsOrNone, even several of them (actually, it makes no difference if there is a single or multiple *-s is/are within a permutation), it is not obvious for me why it cannot be included by referencing from other record/set of templates.
(0010872)
Jacob Wieland - Spirent (reporter)
12-07-2012 11:35

 "Superset, subset and template list can contain one element only if it is all from."

Why? What's wrong with subset (X), superset (X) ?
(0010873)
Jacob Wieland - Spirent (reporter)
12-07-2012 11:37

 "Some restrictions could need further considerations. For example, permutation may contain AnyElementsOrNone, even several of them (actually, it makes no difference if there is a single or multiple *-s is/are within a permutation), it is not obvious for me why it cannot be included by referencing from other record/set of templates.
"

What do you mean? That a record of containing a permutation shall be allowed as a reference referred to be the all-from construct?
(0010879)
Gyorgy Rethy (reporter)
12-07-2012 12:01

 See CR_6088_v4.doc.

Regarding the "can contain one element only if it is all from" question, do you refer to the TemplateList BNF productions?
It seems to me that this also could be simplified to

TemplateListItem {"," TemplateListItem }
but it is not changed in the draft CR_6088_v4.doc. Let the others also look at this.

Regarding the restrictions, actually I mean that we have had restrictions for the individual elements in the description part and now restrictions for the elements brough in by referencing a template has been added to the new Restrictions paragraph. But actually the same restriction apply for both, the mechanisms, how a member got inside a subset/superset/permutation etc. is unimportant. The more, restrictions shall be writen in one place only to avoid possible inconsistencies.

Therefore:
- existing restrictions I have moved to the Restrictions paragraph
- applied the current constrains for the members to the elements referenced by the all from contructs too (in one Restirictions item); actually, for template list and complemented list this means that there is no restriction of the members as there was no restriction before.
(0010882)
Tomas Urban (developer)
12-07-2012 12:32

 The problem is that the mechanism how items get into the target template is actually important. There are several symbols that can appear only inside record of values such as AnyElementsOrNone or permutation. These symbols were explicitely forbidden in the argument of the "all from" clause for these reasons:
1. AnyElementsOrNone: because it is not possible to reasonably transform it into a single element template as it represents a group of elements in the record of template.
2. Permutation: because it is a matching symbol for several elements and because of consistency with other rules that don't allow access to items inside permutation.

Proposal: in addition to general restrictions on the set of symbols that can/cannot appear in the constructed template, there could be an additional restriction saying that the template in the all from clause cannot contain AnyElementsOrNone and permutation.

If the proposal is not accepted, it should be said how is AnyElementsOrNone interpretted, because it is not the same as AnyValueOrNone. Additionally, the restriction b in B.1.2.1 and B.1.2.2 should be changed because it referers to the deleted restriction c.

Regarding the subset and superset template:
The rules are taken from the current BNF, which doesn't allow to construct subset and superset with one item. I agree that it is quite strange and should be changed.
(0010885)
Gyorgy Rethy (reporter)
12-07-2012 14:13
edited on: 12-07-2012 14:14

 Tomáš, let's separate your comment to two parts:
1) regarding the matching mechanisms bound to a type, your comment is partly correct: subset/superset should be disallowed if the referencing type is a record of. However, a permutation is practically converting a record of into a set of. So, referencing a permutation from a set of could be allowed without any problems, just the rules has to be specified ("lift over" just the elements of a permutation into the set of). But if this is considered to be too complicated, I can leave with disallowing this as well.

But I don't see a problem in the non-cross-type cases, e.g. permutation is allowed for record of (complemented) lists:
({permutattion (1,2,3)},{4,5,6})

why the user should not be able to construct the same like
template MyrecOf t_MyrecOf := {permutation(1,2,3)}
template MyrecOf t_MyrecOf2 := (all from t_MyrecOf, {4,5,6})

2) AnyElementsOrNone
Seems we have a terminological issue here.
- In subset and superset AnyValueOrNone are forbidden, obviously this is converted to forbidding AnyElementsOrNone in case of all from references. So, I think this is just an editorial work to do (I mean there is no new restriction is introduced).
- In template (complemented) lists AnyValueOrNone is allowed, so an AnyElementOrNone within a referenced record of or set of is implcitly transformed to AnyValueOrNone. This should be written in the text but I cannot see a technical reason to forbid this.
- Referencing a record/set of with AnyElementsOrNone from within a permutation shouldn't be a problem as AnyElementsOrNone is also allowed in permutation.
(0010890)
Tomas Urban (developer)
12-07-2012 15:50

 György,

I am afraid i cannot agree with the conclusions you made. The "all from" notation is used for moving individual elements, not the whole template into the target. Let's take the example you wrote, but without the permutation mark:
template MyrecOf t_MyrecOf := { 1,2,3 };
The "all from" shall be used to create a template of the member type (integer) of the value in the argument and not a template of the same type (MyrecOf):
template integer t_int := (all from t_MyrecOf, 4, 5, 6);

In the example you described, you define a template of the same record of type. The result you wanted to get can be easily achieved without the "all from" clause:
template MyrecOf t_MyrecOf := {permutation(1,2,3)};
template MyrecOf t_MyrecOf2 := (t_MyrecOf, {4,5,6}); // produces ({permutation(1,2,3)}, {4,5,6})

I hope that we can agree that the "all from" clause produces a set of items of the member type. The problem with the permutation is that it is a matching mechanisms that is rather related to the enclosing record of than to the elements itself. So the issue is how to get those individual elements from there?

Having:
template MyrecOf t_MyrecOf := {permutation(1,2,3)};
template integer t_int := (all from(t_MyrecOf), 4, 5, 6);
the possible results would be either:
(permutation(1,2,3), 4, 5, 6) // if we consider the whole permutation is a single item
or
(1, 2, 3, 4, 5, 6)

I don't like either. The first one is both semantically and syntactically incorrect so it would produce an error anyway. The second one produces a correct template, but it would require additional rules describing that the permutation envelope has to be dropped when "all from" is used. Besides, who would use such rules? What would be a practical application of such a feature? I find it much simpler to forbid permutations in these cases.

The situation with AnyElementsOrNone is a little bit more complicated. You suggest that it shall be transformed into AnyValueOrNone. I don't think it is consistent with the rest of the specification, because no such transformation is actually currently defined and allowed. Besides, there are hidden problems when transforming the element in its literal form. Consider this:

type record of charstring RoC;
template RoC t_roc := {"abc", * length(2)};
template charstring t_c := (all from t_roc);

It would produce ("abc", * length(2)). In this case, the original meaning was altered. In the first template, * length(2) means two strings of any length and in the second one, it means any string with length two or omitted value. The situation would be even worse in case of integers, where * length(2) would be semantically incorrect as a length restriction cannot be applied to an integer template. This might be of course fixed by an additional rule saying that the length attribute shall be dropped during this transformation.

In addition to that, AnyValueOrNone is forbidden for subsets and supersets. Complement templates containing it would not match anything. It might find a good use in permutation though, but this produces another problem, because in this case the transformation AnyElementsOrNone -> AnyValueOrNone is not necessary. For these reasons, I would prefer if AnyElementsOrNone remained forbidden in the argument of the "all from" clause.

If both permutations and AnyElementsOrNone were not allowed in the record of values used in the "all from" clause, we would have a nice uniform rule for all places, where the clause can be used.
(0010899)
Jacob Wieland - Spirent (reporter)
12-07-2012 16:42

 I agree with Tomáš assessment.

Allowing permutation or AnyElmementsOrNone inside the referenced template introduces uncertainties. As long as no one really needs this feature, it should be forbidden to avoid confusion.
(0010902)
Gyorgy Rethy (reporter)
12-07-2012 17:37
edited on: 12-07-2012 18:05

 OK, I have got now where my misunderstanding was. Your explanation is correct, and the original restrictions were also correct, with one exception; we should consider one important case.
Let's define a message template like:
template MyRec t_message := {
  iD := 1,
  iEList := { //record of record, used to check the first two IEs, the rest is unimportant
    {iEID := 1, IEvalue := "Tinky-Winky"},
    { iE2 := 2, IEvalue := "Poo"},
    * }
}
and the user wants to use this to define another template for the IEList where the order of the elements is arbitrary, because the SUT may send them in different orders:
template MyRec.iEList t_IEList_unordered := { permutation (all from t_message.iEList)}

Actually, this is the use case our users need to solve (this was the reason for CR 6165). If disallowing AnyElementsOrNone when all from is used inside a permutation, this use case whould be not be possible, while there is no technical reason for disallowing it. So, in this case, we have a user need that shall overwhelm simplicity and uniformity.

Except this one open issue is remaining: is there a specific reason, why TemplateList is not changed simply to
TemplateList := "(" (TemplateListItem {"," TemplateListItem}+ )
?

In principle the order of "direct" elements and elements referenced by all from clauses should be a user's choice.

Pls. check CR_6088_v5.doc that I corrected according to the above, except the BNF that I haven't changed.
(0010904)
Tomas Urban (developer)
12-07-2012 18:02

 I have no problem with referencing AnyElementsOrNone in permutation, so this is fine for me. Maybe we should add an expample to the draft too.

Regarding the BNF: I think the problem occurs because both superset and subset rules refer to the rules for template list. Currently the BNF allows 2+ elements in template lists, because if a single element were allowed, it would lead to conflicts with an expression inside parentheses. Notice that "all from" doesn't suffer from this conflict (and for that reason, 1 element only is allowed). I think the best way to resolve it is to share the BNF rules for the part in parentheses with complemented template list. I modified the draft this way. Please check if it is fine.
(0010909)
Jacob Wieland - Spirent (reporter)
13-07-2012 10:11

 I also agree that for permutation it makes sense. For subset or superset, though, it seems pointless or confusing.

The subset of an infinite set is any set, so that makes no sense. And the superset of a possibly infinite set is what?

So, basically, we should strive for something like: the same restrictions that apply to the direct elements of a matching mechanism construction must also apply to the elements of the template referred to by the all from-construct in such a construction.
(0010912)
Gyorgy Rethy (reporter)
13-07-2012 11:00
edited on: 13-07-2012 11:07

 Technically is fine with me, I have some editorials (to CR_6088_v6.doc):
-------
1.A ListOfTemplates -> 1. ListOfTemplates
-------
9.PermutationList ::= "(" PermutationListItem {"," PermutationListItem} ")"
PermutationListItem ::= (TemplateBody | AllElementsFrom)

could be simplified to
9.PermutationList ::= "(" TemplateListItem {"," TemplateListItem } ")"
(some time ago we have decided to simplify the BNF by removing transitional "purpose-specific" productions like
TemplateIdentifier := Identifier)
---------
TemplateList would be used in MatchingSymbol only, where it could be replaced by ListOfTemplates as well and the production TemplateList could simply be deleted
---------
wording of item b) in clauses B.1.2.6, B.1.2.7 and B1.3.3 [actually, in B.1.2.7 and B.1.3.3 item ID to be corrected from a) to b)] could be simplified (rext below is given for B.1.2.6, the other clauses could use the same schema)
from
b) The member type of the set of type associated with the superset template and the member type of the record of or set of type associated with the template in the all from claused shall be compatible.
to
b) The member type of the set of associated with the superset template and the member type of the template in the all from clause shall be compatible.
---------
(0010933)
Tomas Urban (developer)
13-07-2012 15:34

 I made the requested changes and corrected a couple of typos. There's only one minor difference compared to György's last editorial proposals. I simplified the rule for permutation in a slightly different way. It uses the same style as complement, subset and superset now:
-->
7.PermutationMatch ::= PermutationKeyword ListOfTemplates
(0011003)
Ina Schieferdecker (reporter)
09-08-2012 13:39

 Streamlining the BNF and some editorial changes: v8
(0011004)
Ina Schieferdecker (reporter)
09-08-2012 13:40

 Please check.
(0011005)
Tomas Urban (developer)
09-08-2012 13:47

 I am OK with the latest changes.
Assigned to Ina for implementation.
(0011008)
Ina Schieferdecker (reporter)
09-08-2012 13:56

 as proposed.

- Issue History
Date Modified Username Field Change
16-05-2012 12:28 Jacob Wieland - Spirent New Issue
16-05-2012 12:28 Jacob Wieland - Spirent Clause Reference(s) => B.1.2.2, B.1.2.6, B.1.2.7
16-05-2012 12:28 Jacob Wieland - Spirent Source (company - Author) => Testing Technologies - Jacob Wieland
09-07-2012 16:58 Ina Schieferdecker Project TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
09-07-2012 16:58 Gyorgy Rethy Note Added: 0010724
10-07-2012 11:53 Gyorgy Rethy Note Added: 0010743
10-07-2012 11:53 Gyorgy Rethy Assigned To => Gyorgy Rethy
10-07-2012 11:53 Gyorgy Rethy Status new => assigned
10-07-2012 11:53 Gyorgy Rethy Target Version => Edition 4.5.1
10-07-2012 11:59 Gyorgy Rethy Relationship added related to 0006165
10-07-2012 12:53 Jacob Wieland - Spirent Note Added: 0010750
10-07-2012 15:08 Gyorgy Rethy Note Added: 0010771
10-07-2012 15:09 Gyorgy Rethy Assigned To Gyorgy Rethy => Tomas Urban
10-07-2012 18:08 Jacob Wieland - Spirent Note Added: 0010773
11-07-2012 09:08 Tomas Urban File Added: CR_6088.doc
11-07-2012 09:20 Tomas Urban Note Added: 0010789
11-07-2012 09:21 Tomas Urban Assigned To Tomas Urban => Jens Grabowski
11-07-2012 10:57 Jacob Wieland - Spirent Note Added: 0010824
11-07-2012 11:14 Jens Grabowski Note Added: 0010827
11-07-2012 11:14 Jens Grabowski Assigned To Jens Grabowski => Tomas Urban
11-07-2012 11:23 Jacob Wieland - Spirent Note Added: 0010829
11-07-2012 14:03 Gyorgy Rethy Note Added: 0010836
11-07-2012 15:53 Tomas Urban File Added: CR_6088_v2.doc
11-07-2012 15:59 Tomas Urban Note Added: 0010839
11-07-2012 16:00 Tomas Urban Assigned To Tomas Urban => Jens Grabowski
12-07-2012 09:14 Gyorgy Rethy File Added: CR_6088_v3.doc
12-07-2012 09:15 Gyorgy Rethy Note Added: 0010857
12-07-2012 09:26 Gyorgy Rethy Note Edited: 0010857
12-07-2012 11:35 Jacob Wieland - Spirent Note Added: 0010872
12-07-2012 11:37 Jacob Wieland - Spirent Note Added: 0010873
12-07-2012 12:01 Gyorgy Rethy Note Added: 0010879
12-07-2012 12:02 Gyorgy Rethy File Added: CR_6088_v4.doc
12-07-2012 12:32 Tomas Urban Note Added: 0010882
12-07-2012 14:13 Gyorgy Rethy Note Added: 0010885
12-07-2012 14:14 Gyorgy Rethy Note Edited: 0010885
12-07-2012 15:50 Tomas Urban Note Added: 0010890
12-07-2012 16:42 Jacob Wieland - Spirent Note Added: 0010899
12-07-2012 17:37 Gyorgy Rethy Note Added: 0010902
12-07-2012 17:38 Gyorgy Rethy File Added: CR_6088_v5.doc
12-07-2012 17:41 Gyorgy Rethy Note Edited: 0010902
12-07-2012 17:43 Gyorgy Rethy Note Edited: 0010902
12-07-2012 18:01 Tomas Urban File Added: CR_6088_v6.doc
12-07-2012 18:02 Tomas Urban Note Added: 0010904
12-07-2012 18:05 Gyorgy Rethy Note Edited: 0010902
13-07-2012 10:11 Jacob Wieland - Spirent Note Added: 0010909
13-07-2012 11:00 Gyorgy Rethy Note Added: 0010912
13-07-2012 11:07 Gyorgy Rethy Note Edited: 0010912
13-07-2012 15:22 Tomas Urban File Added: CR_6088_v7.doc
13-07-2012 15:34 Tomas Urban Note Added: 0010933
13-07-2012 15:34 Tomas Urban Assigned To Jens Grabowski => Ina Schieferdecker
13-07-2012 15:34 Tomas Urban Status assigned => resolved
13-07-2012 15:34 Tomas Urban Resolution open => fixed
09-08-2012 13:39 Ina Schieferdecker Note Added: 0011003
09-08-2012 13:39 Ina Schieferdecker File Added: CR_6088_v8doc.doc
09-08-2012 13:40 Ina Schieferdecker Status resolved => assigned
09-08-2012 13:40 Ina Schieferdecker Assigned To Ina Schieferdecker => Tomas Urban
09-08-2012 13:40 Ina Schieferdecker Note Added: 0011004
09-08-2012 13:47 Tomas Urban Note Added: 0011005
09-08-2012 13:48 Tomas Urban Assigned To Tomas Urban => Ina Schieferdecker
09-08-2012 13:56 Ina Schieferdecker Note Added: 0011008
09-08-2012 13:56 Ina Schieferdecker Status assigned => closed
09-08-2012 13:57 Ina Schieferdecker Fixed in Version => Edition 4.5.1

MantisBT 1.2.14 [^]
Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker