Closed Bug 455837 Opened 16 years ago Closed 16 years ago

Support for re-enabling disabled calendars

Categories

(Calendar :: General, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: dbo, Assigned: dbo)

Details

Attachments

(1 file)

Some providrs (wcap, gdata) switch off a calendar if the login prompt has been canceled, t avoid further bugging the user with login prompts. Users are ady aware unless they have a look at their calendar list.
I propose that we add an auto-enable mechanism evaluated at startup, which turns on disabled calendars (due to login cancelations) on again. Said another way: A canceled login prompt would turn the calendar off for that particular process run only.
Attached patch patch - v1Splinter Review
Assignee: nobody → daniel.boelzle
Attachment #339209 - Flags: review?(philipp)
Furthermore I'd propose we provide mechanisms to auto-enable during the session. For example:

* User has previosly entered a password or has the password saved in the password manager.
* Server borks, rejects the password.
* User cancels login dialog, the calendar is disabled
* On a refresh, the provider tries to login again, but nsIInterfaceRequestor returns a different implementation of the auth prompt, that tries the password from the password manager once and  if that succeeds then enables the calendar.

Surely something that could be done in a separate bug though.

What I am wondering about this bug is how intuitive it will be. Maybe a string like "This Calendar will automatically be reenabled after restart" would be good.
Status: NEW → ASSIGNED
(In reply to comment #2)
> Furthermore I'd propose we provide mechanisms to auto-enable during the
> session. For example:
> 
> * User has previosly entered a password or has the password saved in the
> password manager.
> * Server borks, rejects the password.
> * User cancels login dialog, the calendar is disabled
> * On a refresh, the provider tries to login again, but nsIInterfaceRequestor
> returns a different implementation of the auth prompt, that tries the password
> from the password manager once and  if that succeeds then enables the calendar.

How would you detect when server borking has ended? IMO the problem is that you generally don't know why the user has rejected the login.
If the server is auto-disabled when the user cancels the login, then the login could still be tried with the old credentials without popping up the login dialog and if the server then responds with a success then it could be reenabled. The downside is that the user may not want the client to retry with old credentials, i.e if he entered a (wrong) password that belongs to a different account but would not like to keep sending the old login info over the network. Maybe it could only be done when the password was saved in the password manager.
Yes, and moreover if the user simply doesn't want to log in (maybe she doesn't want to cause network traffic), then we shouldn't do that in the background.
Attachment #339209 - Flags: review?(philipp) → review+
pushed to comm-central: <http://hg.mozilla.org/comm-central/rev/d3427aaaa3f8> => FIXED.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0
Target Milestone: 1.0 → 1.0b1
You need to log in before you can comment on or make changes to this bug.