Bugzilla – Full Text Bug Listing
| Summary: | [ui] Site nickname entered by user is overwritten when repo is refreshed | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Henrik Lindberg <henrik.lindberg> | ||||||
| Component: | p2 | Assignee: | Susan McCourt <susan> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | irbull, john.arthorne, susan | ||||||
| Version: | 3.5 | Flags: | john.arthorne:
review-
susan: review+ |
||||||
| Target Milestone: | 3.5 RC1 | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Henrik Lindberg
Definitely not the intention. The nickname is supposed to win, and the producer-name considered only when a nickname is not provided... Will investigate. Henrik, I can't reproduce this problem as described. Could you provide some more information? When I try to add http://testserver:8080/decelerate, I get this error for the site, so I'm unable to get any further. Unknown Host: http://testserver:8080/decelerate/site.xml Unknown Host: http://testserver:8080/decelerate/site.xml testserver I thought that maybe I have to have 3.4 site enabled for this site to work, but I still get this error after adding/enabling the 3.4 site. I tried other sites where there is a producer name. For example, I added http://www.taubit.de/eclipse/twitterclipse and named it MyTwitter. After checking for updates, it was still called "MyTwitter". When I did the same thing and did not name the repo, the name would refresh to "twitterclipse" (the producer repo name). I also double checked the code to ensure that we don't ever overwrite the nickname unless it's not been specified. There may be some more subtle bug here, but I'll need to know: - what sites you started with - how/when/where you added the site (prefs, install new software, paste, drag?) - where you looked to find out that the nickname had been replaced (prefs, install new software) (In reply to comment #2) > Henrik, I can't reproduce this problem as described. Could you provide some > more information? > > When I try to add http://testserver:8080/decelerate, I get this error for the > site, so I'm unable to get any further. > > Unknown Host: http://testserver:8080/decelerate/site.xml > Unknown Host: http://testserver:8080/decelerate/site.xml > testserver > Sorry, typo - I used http://testserver:8080/proxy/decelerate (the "proxy" part was missing in my initial post). > I tried other sites where there is a producer name. For example, I added > http://www.taubit.de/eclipse/twitterclipse and named it MyTwitter. After > checking for updates, it was still called "MyTwitter". When I did the same > thing and did not name the repo, the name would refresh to "twitterclipse" (the > producer repo name). > > I also double checked the code to ensure that we don't ever overwrite the > nickname unless it's not been specified. > > There may be some more subtle bug here, but I'll need to know: > - what sites you started with > - how/when/where you added the site (prefs, install new software, paste, drag?) > - where you looked to find out that the nickname had been replaced (prefs, > install new software) > I think I did the following: Removed all update sites under prefs. Added site in "install new software" - then canceled out of the dialog as it took a long time to load. Then ran "check for updates" Then looked under prefs. I wil try to reproduce and make notes about steps. I noticed the problem twice. Could perhaps have occurred when I again removed all repositories (using prefs) to try a second (and third time). I probably added and removed the "decelerate" site and used all involved dialogues back and forth - also using "test connection" to stress it. Unless it happens every time, I don't think this needs to be fixed for 3.5 Thanks for the steps, Henrik. I'll keep trying. (In reply to comment #4) > Unless it happens every time, I don't think this needs to be fixed for 3.5 > Agree this is not a showstopper, but I plan to investigate a little further. I think this might be related to some name-related oddities Pascal saw in bug 274334. I saw this too. Sometimes is would happen after I hit "Test Connection". (In reply to comment #6) > I saw this too. Sometimes is would happen after I hit "Test Connection". > Uhhh....doh! That's the problem. When the repo is refreshed, it is removed and re-added and the old user nickname is lost. The reason this isn't blatantly obvious is that in the preference page, if the user made any other changes to any repos, the repos are updated with what is visible in the pref page, so the old nickname gets reset again. So the trick to reproduce the problem is 1 - add a repo and a name in the prefs 2 - OK 3 - open the prefs again 4 - "Test Connection" on the repo 5 - OK 6 - open the prefs again name is gone. If you do anything else between 4 and 5 (including accidentally clicking in the name field of a repo), you won't see the problem because the repo page has changed and it will update the manager with what is in the page. Created attachment 135396 [details]
patch
This patch sets the nickname back into a repo that is refreshed. Whatever name is showing in the UI (nickname or producer name) is set back as the nickname.
John, can you please review. Here is a slight clarification of the steps to reproduce. 1 - Prefs>Available Software Sites. Add a repo that is not already in the list and specify a nickname. 2 - OK 3 - open the prefs again 4 - Select the newly added repo and push "Test Connection" 5 - OK 6 - open the prefs again The nickname is now gone. If the producer specified a name it is there, otherwise it is blank. If you do anything else between steps 3 and 5 (including accidentally clicking in the name field of a repo), the problem won't occur. I think this should be fixed in the repository manager. It seems unreasonable that all clients of the refresh API need to add back the property like this. I will come up with a patch. Created attachment 135664 [details]
Repository manager fix
fixed in HEAD >20090513. I verified that the new test cases fail without the fix, pass with the fix, and that the fix also corrects the scenario in comment #9. I agree fixing it in the manager is a better solution. |