Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 228260 - Changing the file name of a test asset in the Test Navigator updates the logical name.
Summary: Changing the file name of a test asset in the Test Navigator updates the logi...
Status: CLOSED DUPLICATE of bug 290254
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: TPTP (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P2 normal (vote)
Target Milestone: ---   Edit
Assignee: Bozier jerome CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-04-22 15:02 EDT by Paul Slauenwhite CLA
Modified: 2016-05-05 11:02 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Slauenwhite CLA 2008-04-22 15:02:42 EDT
Changing the file name of a test asset in the Test Navigator updates the logical name.

[See https://bugs.eclipse.org/bugs/show_bug.cgi?id=162407#c17]:

Jerome, if the user is renaming the physical name of a test asset, we should
not rename the logical name, since they are separate names.  Maybe we could ask
the user if they would like the rename the logical name at the same time, but
we should not assume they want them to be the same.
 
The solution is to add a line in "refactoring" page of rename wizard saying
"updating logical name" and checked by default.
Comment 1 Paul Slauenwhite CLA 2008-04-22 15:03:05 EDT
Jerome, please provide a sizing.
Comment 2 Bozier jerome CLA 2008-04-28 04:55:56 EDT
tryed the proposed solution (adding a line inside refactoring page to separate logical renaming from physical renaming)
it works well for pure renaming but there is a problem concerning the updating of linked ressource
updating mecanism for linked ressource update at same time the logical and the physical name
so, separating them would need to split this public API to have 4 update method instead of 2 :
. update self when logical name change
. update self when physical name change
(instead of "update self when logical and physical name change")

. update resource when linked logical name change
. update resource when linked physical name change
(instead of "update resource when linked logical and physical name change")

also, there is a need to link the choice of the user inside refactoring wizard :
if user unselect "change logical name", it should automatically unselect "update logical name"
if user unselect "change physical name", it should automatically unselect "update physical name"

so, it's less trivial that it seems. 
estimated time to do it :
around 1 to 2 week + API change
Comment 3 Paul Slauenwhite CLA 2008-04-28 12:52:28 EDT
(In reply to comment #2)
> tryed the proposed solution (adding a line inside refactoring page to separate
> logical renaming from physical renaming)
> it works well for pure renaming but there is a problem concerning the updating
> of linked ressource
> updating mecanism for linked ressource update at same time the logical and the
> physical name
> so, separating them would need to split this public API to have 4 update method
> instead of 2 :
> . update self when logical name change
> . update self when physical name change
> (instead of "update self when logical and physical name change")
> 
> . update resource when linked logical name change
> . update resource when linked physical name change
> (instead of "update resource when linked logical and physical name change")
> 
> also, there is a need to link the choice of the user inside refactoring wizard
> :
> if user unselect "change logical name", it should automatically unselect
> "update logical name"
> if user unselect "change physical name", it should automatically unselect
> "update physical name"
> 
> so, it's less trivial that it seems. 
> estimated time to do it :
> around 1 to 2 week + API change
> 

Jerome, please update the Orig. Est. field with your estimate.
Comment 4 Bozier jerome CLA 2008-05-05 04:26:38 EDT
update estimated hours
Comment 5 Paul Slauenwhite CLA 2008-05-21 14:21:44 EDT
Deferring to future as approved by the TPTP PMC (http://dev.eclipse.org/mhonarc/lists/tptp-pmc/msg04926.html).
Comment 6 Paul Slauenwhite CLA 2008-07-22 07:32:31 EDT
Deferring to 4.5.2 given the lack of resources to complete in 4.5.1.
Comment 7 Paul Slauenwhite CLA 2009-01-27 13:25:51 EST
Deferring to TPTP 4.5.3 since TPTP 4.5.2 development is closed (http://www.eclipse.org/tptp/home/project_info/releaseinfo/4.5.2/schedule.html) and P2 defects are not considered candidates during release shut-down.
Comment 8 Paul Slauenwhite CLA 2009-09-23 09:05:42 EDT
This scenario will be covered under 290254.

*** This bug has been marked as a duplicate of bug 290254 ***