Bug 432307 - Unknown component type due to changes in propagated component names
Summary: Unknown component type due to changes in propagated component names
Status: CLOSED FIXED
Alias: None
Product: Jubula (Archived)
Classification: Technology
Component: Core (show other bugs)
Version: unspecified   Edit
Hardware: PC All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Miklos Hartmann CLA
QA Contact: Oliver Goetz CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 470025
  Show dependency tree
 
Reported: 2014-04-08 11:02 EDT by Marvin Mueller CLA
Modified: 2017-02-09 06:00 EST (History)
4 users (show)

See Also:


Attachments
No Component Type exist (128.02 KB, application/pdf)
2016-12-21 09:13 EST, Elena Pister CLA
no flags Details
Unknown comp name (83.22 KB, image/png)
2017-01-18 02:58 EST, Elena Pister CLA
no flags Details
Bug 432307 (50.94 KB, image/png)
2017-02-09 05:59 EST, Elena Pister CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marvin Mueller CLA 2014-04-08 11:02:42 EDT
Given a test case "a" which is has and ub_click module in it and its component name is propagated and a new component name is created in the component names view. And also a test case "b" which is referencing "a" and also giving it a new component name. This component name should be mapped.

Steps to reproduce:
1. changing the new component name in "a" from ub_click module to a new one
2. going into object mapping and un assign the component name from its technical component

You now have a unknown component type for the new component name which was used in the "b" test case.

I am not complete sure if this is the right behavior for this scenario. 
The unknown component type seems to be correct here since there is also a component name pair which has a non existing component type. But maybe this should occur even sooner since we are looking for the component name component type in multiple places and each should be valid and if one of them is not valid the type should be unknown.

We have also seen other places where a unknown component type did occur but we are not able to reproduce it.
Comment 1 Alexandra Schladebeck CLA 2014-05-05 08:25:53 EDT
I've discussed with Achim - we are going to define cases where component name types are set / chenged. Based on this information, we can check the current behaviour and the implementation.
Comment 2 Markus Tiede CLA 2015-07-21 02:38:44 EDT
@AS: Did you already define the cases mentioned in comment 1? If not could you please do so?
Comment 3 Alexandra Schladebeck CLA 2015-07-24 10:27:17 EDT
Haven't done it yet.
Comment 4 Alexandra Schladebeck CLA 2016-02-11 02:54:01 EST
I am not currently working on this, reassigning to default.
Comment 5 Miklos Hartmann CLA 2016-11-22 02:39:51 EST
Probably this is resolved in the Refactor.
Comment 6 Alexandra Schladebeck CLA 2016-11-24 08:09:05 EST
Let's go with that assumption for now - closing.
Comment 7 Elena Pister CLA 2016-12-19 11:06:24 EST
If component (XYZ) was renamed in the TC or we unmap the component from the technical component the component (XYZ) shows first a empty component type in the properties view. As soon the user does save the changes, the type does appear as soon the user does save his changes.
Comment 8 Elena Pister CLA 2016-12-21 09:13:45 EST
Created attachment 266011 [details]
No Component Type exist
Comment 9 Elena Pister CLA 2016-12-21 09:15:29 EST
Unfortunately I missunderstood the bug, and the bug still does exist in the version 8.4 (see attachment)
Comment 10 Miklos Hartmann CLA 2016-12-21 12:51:46 EST
Hm, I don't see any problem on the attached screenshot. In fact I also misunderstood the ticket first, but now I tried to reproduce it in 8.3, and I could not.

To clarify things, here is how 8.4 should work (and I think 8.3 and earlier versions were also working the same way, just maybe a bit more buggily) - if this is not our intention, or anything needs to change, let me know:

 - We are talking about two different things here - one is the type of a Component Name and the other is the type of a Component Names Pair. CNs are shown in the CNBrowser, and Component Name Pairs are shown in the Component Names View. Component Names can have "Unknown types" - this happens if they are used simultaneously in conflicting places (e.g Table and Tree). When I say "used", that means that when we follow the path from where one such CN appears down to Test Steps, in one path the CN ends up in a Test Step which has a type Tree and in another path it has a type Table. CNs should never have empty types, or nonexisting types. Also, if a CN is never used (that is, it is not mapped or there are no paths from the CN down to any Test Step *), then it should have the type "Graphics Component".

 - Component Name Pairs have their own type - this is calculated by following the paths from where the pair appears down to every Test Step. So CNs have a "global" type whereas Pairs have "local" types. If someone changes a referenced TCs CNPairs, some chains may broke - as it happened in the Description and in Elena's screenshot. In such cases it can happen that some CNPairs become "detached" - no Test Step is accessible from them. These pairs do not influence the type of the CNs in them (this case is marked by the * in the previous paragraph), and they are marked as "No Component type exists" in the Component Names View.

Currently I am not aware of any cases where these rules are broken, possibly except for some refreshing issues, but of course there are always a non-0 possibility of more serious bugs appearing. So Elena, could you please clarify what exactly is wrong on your screenshot?
Comment 11 Alexandra Schladebeck CLA 2017-01-13 08:22:17 EST
Assigning to Elena to have a look at.
Comment 12 Elena Pister CLA 2017-01-18 02:58:06 EST
Created attachment 266338 [details]
Unknown comp name

I still could reproduce on 17.01.17 the error with unknown component types and I send the project to Miklos to have a look at.
Comment 13 Miklos Hartmann CLA 2017-01-18 03:07:05 EST
To be honest, I don't think that the bug Elena discovered is the same as the original one, anyway, I hopefully fixed it with https://git.eclipse.org/r/#/c/88872/
Comment 14 Elena Pister CLA 2017-02-09 05:59:21 EST
Created attachment 266742 [details]
Bug 432307

Marvin B. and me tested it and now it works like it has to be, that means that, the old CN does show an unknown CNType message and the new CN is fine (see attachment). That why I close now the ticket.
Comment 15 Elena Pister CLA 2017-02-09 06:00:08 EST
closed as fixed referring to comment 14