Closed Bug 456170 Opened 11 years ago Closed 11 years ago

Cannot change authentication information for GData Provider

Categories

(Calendar :: Provider: GData, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: nemecek, Assigned: Fallen)

Details

(Whiteboard: [gdata-0.5])

Attachments

(1 file)

User-Agent:       Opera/9.52 (Windows NT 5.1; U; en-GB)
Build Identifier: http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/0.9-candidates/rc2/windows-xpi/

When you insert a wrong E-Mail Address while subscribing to a Google Calendar with GData Provider, you cannot change this information afterwards using the login prompt. 

Reproducible: Always

Steps to Reproduce:
1. Start adding a new Calendar in Calendar view 
2. Select "On the Network"
3. Choose "Google Calendar" and provide the private link to your calendar 
4. You are now asked to provide username and password. Provide a wrong username here and continue. 
5. Give the child a name, colour, ... 
6. The calendar has now been created. 
Actual Results:  
7. Since the credentials are wrong, you are prompted to supply "User Name" and "Password" again. 
8. Even if you change the "User Name" to the correct on now, the changes are not stored and you'll get prompted for your login data again. 
9. After some retries the calendar gets marked as "momentarily inavailable"

Expected Results:  
1: After the first login prompt the credentils should be validated. If they cannot be verified, the user should be prompted again and the supplied data should not be saved. 

2: If the user changes the "User Name" in the login prompt, this change should be saved. At the moment it seems to be ignored. 

It makes no difference if you select to store the password using the "Password Manager".
Attached patch Fix - v1Splinter Review
Argh, small fix but switching users is somehow broken. I was able to actually switch the user even without this fix, but there were errors in the error console. This is a regression from bug 430254.

I need this in the provider 0.5, so my plan is to check this in at least on moz1.8 and head (and comm-central), I'm indifferent about checking it on on sunbird_0_9_branch. For AMO I'll likely use either a "nightly" that has not been switched back to branch builds but contains this patch (requires i check in on sb0.9 branch), or apply the fix manually.


ause, dbo, any thoughts?
Assignee: nobody → philipp
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #339652 - Flags: review?(daniel.boelzle)
Comment on attachment 339652 [details] [diff] [review]
Fix - v1

r=dbo, please check it in on SUNBIRD_0_9_BRANCH, too, since you will do your release from that branch.
Attachment #339652 - Flags: review?(daniel.boelzle) → review+
Checked in on HEAD and MOZILLA_1_8_BRANCH and SUNBIRD_0_9_BRANCH

-> FIXED

With this checkin, I've also incremented the version number to 0.5
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
OS: Windows XP → All
Hardware: PC → All
Resolution: --- → FIXED
Whiteboard: [gdata-0.5]
Target Milestone: --- → 0.9
You need to log in before you can comment on or make changes to this bug.