Bugzilla

Thanks Philipp.  Sounds good on ical.js.  This bug has been on the back burner while I've been focusing on calendar integration.  From your comments it sounds like I'm on the right track with the dialog and what it should do.  I think my question was basically: does clicking "accept redirect" in the dialog mean:

(a) Make the target URI of the redirect the new URI for the calendar, forget the old one, and use the new one going forward.

(b) Accept just a one-time redirect, the user will see the dialog again the next time the calendar data is synced, and show a second dialog asking if the user wants to accept the new URI "permanently" as the new URI for the calendar, as a separate question.

I think (a) is better, because simpler, and seems to be what you have in mind.  Let me know if that's not the case.  

(I think I was uncertain about what you meant with the phrase "If they do accept the redirect, you may also need to see if the calendar URI needs to be adapted".  Namely, the "may" which I read as you "may or may not" need to do anything more than just a one-time redirect, and then the "also need to see if", did that mean present a second dialog to ask the user if ("see if") the calendar URI should be updated to the target of the redirect.  I think I've got it straight now, but that's where I got confused.  Thanks again for clarifying.)

> The previous dialog always prompted the user

Huh, there was a previous dialog?  I hadn't seen one, must be missing it somehow.

Thanks Philipp.  Sounds good on ical.js.  This bug has been on the back burner while I've been focusing on calendar integration.  From your comments it sounds like I'm on the right track with the dialog and what it should do.  I think my question was basically: does clicking "accept redirect" in the dialog mean:

(a) Make the target URI of the redirect the new URI for the calendar, forget the old one, and use the new one going forward.

(b) Accept just a one-time redirect, the user will see the dialog again the next time the calendar data is synced, and also show a second dialog asking if the user wants to accept the new URI "permanently" as the new URI for the calendar, as a separate question.

I think (a) is better, because simpler, and seems to be what you have in mind.  Let me know if that's not the case.  

(I think I was uncertain about what you meant with the phrase "If they do accept the redirect, you may also need to see if the calendar URI needs to be adapted".  Namely, the "may" which I read as you "may or may not" need to do anything more than just a one-time redirect, and then the "also need to see if", did that mean present a second dialog to ask the user if ("see if") the calendar URI should be updated to the target of the redirect.  I think I've got it straight now, but that's where I got confused.  Thanks again for clarifying.)

> The previous dialog always prompted the user

Huh, there was a previous dialog?  I hadn't seen one, must be missing it somehow.