Closed Bug 323180 Opened 14 years ago Closed 14 years ago

Publish Remote Calendar doesn't remember .ics file location


(Calendar :: Sunbird Only, defect)

Not set


(Not tracked)



(Reporter: pfarrell, Assigned: ssitter)




(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051104 Mozilla Sunbird/0.3a1

When you publish a remote calandar, the dialog box for saving the .ics
file is not filled in. This used to work  in 0.2.

Not only is it user unfriendly, but it is error prone to make
someone retype from scratch the full url:
or worse.

Reproducible: Always

Steps to Reproduce:
1. Select calendar to publish
2. rightclick Publish entire calendar
3. dialog box pops up for 'publishing url' but it is empty

Actual Results:  
'publishing url'  is empty

Expected Results:  
should remember publishing url from time calendar was 
subscribed or reloaded.
I already planned to fix this while working on the lightning publish dialog so I'll take this bug.
Assignee: mostafah → ssitter
Ever confirmed: true
*** Bug 318015 has been marked as a duplicate of this bug. ***
Attached patch patch, v1 (obsolete) — Splinter Review
- Store the publish url in calendar property 'remote-ics-path', the same property that the current Lightning code uses already
- fix some overlong lines
- do some cleanup in loadCalendarPublishDialog()
- remove the (non-working) usage of calendar.publish.path preference (as discussed on irc)
- remove useless publish tab in options dialog (as discussed on irc)
Attachment #208673 - Flags: first-review?(jminta)
Comment on attachment 208673 [details] [diff] [review]
patch, v1

This is a bowl of spaghetti.  There's a lot of different things here, some of which may want to be in separate bugs.  I've mentioned the two that stand out to me below.  Mostly, I just want this patch to be clear about what it does and does not accomplish, so that we have good, clean follow-up bugs where necessary.

    if( args.publishObject )
       gPublishObject = args.publishObject;
       if ( args.publishObject.remotePath )
-          document.getElementById( "publish-remotePath-textbox" ).value = args.publishObject.remotePath;
+          remotePathTextbox.value = args.publishObject.remotePath;
It's not really your code, but if you're touching this, I wonder whether this else {} can ever be reached given current code? since the only line left in there is gPublishObject = new Object();, we might want to look into removing all of that.

       <button id="calendarAlarmButton"   orient="vertical" class="buttonBoxButton" type="radio" group="categories" label="&calendar.alarms.label;"   url="alarmPrefs.xul"/>
-      <button id="calendarPublishbutton" orient="vertical" class="buttonBoxButton" type="radio" group="categories" label="&calendar.publish.label;"  url="publishPrefs.xul"/>
       <button id="calendarViewButton"    orient="vertical" class="buttonBoxButton" type="radio" group="categories" label="&calendar.views.label;"    url="viewPrefs.xul"/>

If you're going to remove it, you should do a better cleanup.  Take it out of, and out of the calendar extension as well.  You could go all out and remove the style rules from and file a bug for the image with the pref icons to be fixed.
Attachment #208673 - Flags: first-review?(jminta) → first-review-
Attached patch patch, v2Splinter Review
Without spaghetti. Just store/restore publish path.
Leave the rest for separate bugs (to be filed.)
Attachment #208673 - Attachment is obsolete: true
Attachment #208676 - Flags: first-review?(jminta)
Comment on attachment 208676 [details] [diff] [review]
patch, v2

r=jminta as long as you file the follow-ups.  Removing publishPref.xul should be a priority.
Attachment #208676 - Flags: first-review?(jminta) → first-review+
Patch checked in.  Leaving bug open until the followups are filed.
(In reply to comment #7)
> Patch checked in.  Leaving bug open until the followups are filed.

Filed Bug 323731 for the preference/options dialog stuff.
(In reply to comment #8)
> Filed Bug 323731 for the preference/options dialog stuff.
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.