Open Bug 315307 Opened 14 years ago Updated 2 months ago

remote calendar location cannot be edited in edit calendar/calendarProperties

Categories

(Calendar :: Dialogs, defect)

defect
Not set

Tracking

(Not tracked)

People

(Reporter: copperheadclgp, Unassigned)

References

Details

(Keywords: good-first-bug)

Attachments

(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050923 Thunderbird/1.0.7

If I attempt to move the .ICS file location for Lightning by going to the "Calendar" tab, then right-click on "My Calender", "Edit Calendar" and browsing to the correct file, as soon as I "ok" out of those windows, the location is put back to "C:\Documents and Settings\Deborah D. Finch\Application Data\Thunderbird\Profiles\06hxepun.default\Calendar\CalendarDataFile.ics" EVEN THOUGH this file no longer exists.

This is confusing as it could lead the user to doubt whether their change has taken effect.  

Reproducible: Always

Steps to Reproduce:
See description - no special steps
I'm seeing this, too, confirming

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051104 Mozilla Sunbird/0.3a1
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: ICS file cannot be moved/relocated → ICS file location cannot be edited in edit calendar/calendarProperties
Forgot to cc myself and mention that I made the summary more accurate.
Assignee: shaver → dmose
OS: Windows XP → All
Hardware: PC → All
Target Milestone: --- → Lightning 0.1
Version: unspecified → Trunk
Status: NEW → ASSIGNED
Summary: ICS file location cannot be edited in edit calendar/calendarProperties → remote calendar location cannot be edited in edit calendar/calendarProperties
Attached patch patch, v2Splinter Review
This patch does two things: 

* it adds a "preference key" to the calICalendar object so that everything that holds onto a persistent calendar has an id that refers only to that calendar and its metadata and won't change if the location (ie URI) of the calendar changes.  It corresponds to the id field of the calendar in the cal_calendars table.

* it gives calCalendarManager.{set,get}CalendarPref special knowledge of the two non-id fields in the cal_calendars table, since these are really actually just preferences that happen to live somewhere else.

It then wires up the dialog to take advantage of this new infrastructure such that "Edit Location" actually works.
Attachment #206268 - Attachment is obsolete: true
Attachment #206448 - Flags: first-review?(mvl)
Comment on attachment 206448 [details] [diff] [review]
patch, v2

>-        pp.id = calendarID;
>+        pp.id = prefKey;

prefKey is used as a key, but not only for prefs. Why not just call it 'key' or 'id'?

>Index: resources/content/calendarProperties.js
> function onOKCommand()
> {
>+   if (!newUri.equals(gCalendar.uri)) {
>        gCalendar.uri = newUri;
>+       calManager.setCalendarPref(gCalendar, 'uri', newUri.spec);
>+   }

You set the .uri, and the uri pref. Why both? If that's needed, this looks a bit fragile.
Comment on attachment 206448 [details] [diff] [review]
patch, v2

see comment 5, about the uri's
Attachment #206448 - Flags: first-review?(mvl) → first-review-
*** Bug 302674 has been marked as a duplicate of this bug. ***
Make the location field readonly until a proper fix is available. Thus the bug can be removede from the Lightning 0.1 release blocker list.
Attachment #209885 - Flags: first-review?(dmose)
Comment on attachment 209885 [details] [diff] [review]
make the location field readonly [checked-in]

r=dmose
Attachment #209885 - Flags: first-review?(dmose) → first-review+
Comment on attachment 209885 [details] [diff] [review]
make the location field readonly [checked-in]

Patch checked in; thanks Stefan!
Attachment #209885 - Attachment is obsolete: true
No longer blocks: lightning-0.1
Target Milestone: Lightning 0.1 → Lightning 0.2
*** Bug 328725 has been marked as a duplicate of this bug. ***
*** Bug 246739 has been marked as a duplicate of this bug. ***
Not going to make the 0.3 train.
Target Milestone: Lightning 0.3 → Sunbird 0.4
Component: Lightning Only → General
QA Contact: lightning → general
Same issue for Sunbird 0.3. For those of us who have to dual boot, using a FAT partition to store Sunbird calender data was ideal. When booted to Linux (ext3) or booted to Windows (NTFS), each Sunbird installation pointed to the same calender (on the FAT partition). Events created, while booted to one OS, were seen on both OS's. I see this as a show stopper for Sunbird 0.3. I've gone back to Sunbird 0.2. Thanks. Ric @ eof1@psu.edu.
I'm having this with Sunbird 0.3 es-ES under Win2k. I manually edited the profiles.ini file to point to an absolute path and started Sunbird. It recreated the profile in the standard location and restored the profiles.ini file to the default.
Thanks.
Duplicate of this bug: 367575
This doesn't block 0.5, but once mvl gets his calendar-id in, we may be able to slip it in under the wire.
Cleaning up incorrectly assigned bugs; search for dmosecleanup to get rid of this bugmail.
Assignee: dmose → nobody
Status: ASSIGNED → NEW
Not going to make the 0.5 train.
Target Milestone: Sunbird 0.5 → ---
I'd like to suggest that if this isn't fixed soon, the text not be displayed in an input box at all, just print it on the dialog, as having the box makes it look like it should be editable.
Attachment #209885 - Attachment description: make the location field readonly → make the location field readonly [checked-in]
Attachment #209885 - Attachment is obsolete: false
Flags: wanted-calendar0.9?
Version: Trunk → unspecified
Flags: wanted-calendar0.9? → wanted-calendar0.9-
Duplicate of this bug: 501663
Four years later : did you loose the guy who wrote the label ?

There's a hack you can use the sqlite ff manager extension, open your storage.db and make manually the changes, but this is a not a solution.
In 1.0pre you can already change the URL via "Tools > Options > Advanced > Config Editor". Search for the preference "calendar.registry.<uuid>.uri" with <uuid> being a random string. Or manually edit prefs.js in your profile folder while Thunderbird/Sunbird is closed.
I've just see this this afternoon. 
So are we really sure the patch putting url read-only is needed with today technology ?

Afterwall in 2006 we don't use sqlite db storage.
I would really like to see this in 1.0.

Gnome Evolution can handle such things very well.
(In reply to comment #23)
> In 1.0pre you can already change the URL via "Tools > Options > Advanced >
> Config Editor". Search for the preference "calendar.registry.<uuid>.uri" with
> <uuid> being a random string.

Just a thought: could the input box in the dialog just work in the same way? I mean codewise. If the config editor can change this setting permanently, maybe rewriting the dialog box with the editor behaviour in mind solves that easily.
Might work, would require some testing. we would have to check all code locations that use the URI to see if a refresh is all thats needed to make use of the new URI. This should be quite easy to do. Anyone willing to write a patch and test?
Whiteboard: [good first bug]
I had not seen this solution, for me it worked straigt forward.

1. Go to "Tools > Options > Advanced > Config Editor"
2. Type "calendar.registry.*.uri" as filter string (note the asterisk!)
3. Change the calendars you want to change
4. Trigger reload of remote calendars
I might try to fix this really soon. ;-)
Assignee: nobody → mschroeder
Whiteboard: [good first bug]
Status: NEW → ASSIGNED
Duplicate of this bug: 697996
I've been playing with this. Unfortunately, it's not enough to be able to edit the dialog box, even if getting the data written to prefs.js were easier (which it's not). As with calendar creation, we need to validate the uri entered (edited) in the box, and throw an error to the user if the uri makes no sense. I suppose the best way would be to reuse/access parseUri() in calendarCreation.js, but I'm not getting to work as I'd like.

Anyone else care to take a stab at this aging bug?

(I got interested in this as I was wondering why a particular remote calendar of mine wasn't working, and discovered that I had a typo - missed the "s" in ".ics" - and then found that I couldn't just edit the field in the UI to adjust the calendar uri, but had to hack it in prefs.js. That method, though, doesn't validate the uri - or ensure that it is unique, even if it is structurally sound.)
Component: General → Dialogs
Flags: wanted-calendar0.9-
Michael Duelli's suggestion does not work in Lightning 1.9.1 (on TB 17.0.6). Any other solutions that do not involved removing/adding the calendars?
I can confirm that editing about:config edit works perfectly fine here.
(In reply to mihaic from comment #32)
> Michael Duelli's suggestion does not work in Lightning 1.9.1 (on TB 17.0.6).
> Any other solutions that do not involved removing/adding the calendars?

Correction: it does work after restarting Thunderbird.
Please add this feature as a small typo needs to create calendar from stratch.
It is also a problem, if you have to sync it to a local file and then sync it elsewhere and if you had to move your profile to a new pc.
Assignee: mschroeder → nobody
Status: ASSIGNED → NEW
Duplicate of this bug: 1502858

I think we should look into this. Seems like low hanging fruit, and could also help people if they need to change the URL e.g. after bug 1579020.

You need to log in before you can comment on or make changes to this bug.