Closed Bug 356569 Opened 18 years ago Closed 17 years ago

[proto subscriptions] No ability to view other people's calendars (i.e. calendars I have subscribed to)

Categories

(Calendar :: General, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: moreau, Assigned: dbo)

References

Details

(Whiteboard: [gdata-0.4])

Attachments

(2 files, 3 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061003 Firefox/2.0
Build Identifier: Lightning 0.3; WCAP Enabler 0.3; Thunderbird 2 alpha 1

Using WCAP, I see my own remote calendar. However, I have also subscribed to other people calendars. However, there is no way for me to see them.

Reproducible: Always

Steps to Reproduce:
1. New Calendar...
2. Select WCAP
3. Set location to remote server: http://...
4. How do I set the name of the calendar I have subscribed to? There is no field



Expected Results:  
1. Ability to type in the name of a calendar I have subscribed to (i.e. not my own calendar, but a calendar of a person I frequently deal with).
2. Login-in using my credentials, not those of the person I was to browse the calendar
Summary: No ability to view calendars that have been subscribed to → No ability to view other people's calendars (i.e. calendars I have subscribed to)
Same observations, one calendar host = one credential ..
I had to use DNS aliases to do the trick :(

Help !
You can already see other people's WCAP calendars by using the URL schema described here: http://wiki.mozilla.org/Calendar:WCAP_Provider#Subscribing_To_Your_Calendar

However, this has nothing to do with your server based subscription list. The good news is that Thomas is currently working on making WCAP subscriptions fully available in Lightning so I'll pass this bug to him.
Assignee: nobody → thomas.benisch
Status: UNCONFIRMED → NEW
Ever confirmed: true
Component: Provider: WCAP → General
Summary: No ability to view other people's calendars (i.e. calendars I have subscribed to) → [proto subscriptions] No ability to view other people's calendars (i.e. calendars I have subscribed to)
i can reproduce this also in linux.

i dont think you can use that schema to see other wcap calendars because it asks you credentials of the owner, not the invited people. if i try to put my own credentials thunderbird hangs.


evolution handle this by using a single credentials method. this way you must subscribe using JES web interface, then you see all of subscriptions as several sub-calendars in you own calendar.

Maybe my description of the original issue was not quite accurate. Up to now I was using Sun Java System Calendar Express, i.e. a Web interface to Sun's calendar server.

Using this system, there are 2 ways I can see other people calendars (both require that I first login as myself):
1. First I subscribe to someone else's calendar, then I can select this calendar in a drop down list and view it. This is what I think I have captured in my original issue description.

2. Even if I haven't subscribed to someone else's calendar, I can still display his/her calendar by tweaking the URI in the address bar. For example, here's the URI for my own calendar:
http://calendar/command.shtml?view=weekviewdate=20070117T091829&calid=moreau
(I omitted some of the fields for clarity)
To easily (YMMV) see fred's calendar, I can simply replace "moreau" with "fred". I don't need to subscribe to fred's calendar first.

This is actually this 2nd functionality that I am most interested in. Compared to 1., it's one less step.

@Stephan, I don't think I can do this using the URL Schema you reference.
(In reply to comment #4)
You'll find more details of our current proposal at
http://wiki.mozilla.org/Calendar:Calendar_Subscription

The idea is to subscribe to someone else's calendar by
using a dialog with search functionality. All subscribed
calendars are added to the calendar tree. As the subscription
list is stored on the server, all your subscriptions are
also shown at the next application startup.

Whereas the Sun Web Interface allows you to view one
calendar only, we have foreseen to view multiple calendars
at the same time.

Your idea of a fast access to other people calendars is
really nice. We will keep it in mind, but we definitely
won't implement such a functionality for the initial
version.

In addition, we have not foreseen that a user can modify
the URL, especially changing the calid. This will lead to
a lot of problems.
Thomas, your new design sounds cool. A further improvement to your subscribe dialog -at least from a user POV- would be to reuse Thunderbird's existing GUI for subscribing to IMAP folders or newgroups, which you'll probably have thought about already.

Viewing multiple calendars at the same time is a great and indeed necessary feature. The issue is how to not clutter the display; it typically gets a bit crowded.

URIs are meant to be tweaked. Isn't that what a savvy Web user will do every now and then to get faster to a location or resolve a broken link? ;-)
Assignee: thomas.benisch → michael.buettner
(In reply to comment #5)
> You'll find more details of our current proposal at
> http://wiki.mozilla.org/Calendar:Calendar_Subscription62

It would be nice if this feature worked for all calendar types, not just ones like WCAP.

For example, consider the case where there are several .ics calendars in a single folder on a webDAV server.  It would be great to be able to selectively subscribe to them in the same way.  In the case of .ics, the dialog could show a list of calendars instead of a list of people.
Berend said he would like to take this one, so here it is...
Assignee: michael.buettner → Berend.Cornelius
Proposing as a 0.7 blocker.
Flags: blocking-calendar0.7?
i've +'ed

this also happens in linux, should OS be changed?
Flags: blocking-calendar0.7? → blocking-calendar0.7+
muzzol, please do not plus bugs. This should only be done by release drivers.
Flags: blocking-calendar0.7+ → blocking-calendar0.7?
sorry :(

is there any problem if i vote this bug?

im very interested in resolving it.
Ulf and I decided this is a core feature for WCAP and needs to block
Flags: blocking-calendar0.7? → blocking-calendar0.7+
QA Contact: wcap-provider → general
I currently don't see anybody with spare time to do it; not on roadmap for 0.7.
Flags: blocking-calendar0.7+ → blocking-calendar0.7?
First work patch for WCAP. This patch auto-registers all subscribed calendars on first logon iff pref "calendar.wcap.subscriptions" is true. Technically, all calendars belonging to the same account/session share the same uuid in calendar pref "shared_context". Unsubscribing the "default" calendar (i.e. the one the user has configured via wizard) will unsubscribe all related calendars of that account.
Assignee: Berend.Cornelius → daniel.boelzle
Status: NEW → ASSIGNED
The auto registration requires that calCalendarManager late-initializes its calendar list; it currently calls the provider from within its ctor, which is bad. Philipp already suggested this change in some other bug IIRC.
This patch also avoids unnecessary db reads by using calCalendarManager's cache in getCalendars().
Attachment #279110 - Flags: review?(philipp)
Attached patch minding suppressAlarms up front (obsolete) — Splinter Review
Testing WCAP subscriptions, it became most apparent to me that testing for suppressAlarms late in the game right before firing a potential alarm slows down startup enormously, because you commonly have far more subscribed calendars (which you don't want alarms for) than owned ones (you want alarms for).
I currently don't see a valid reason why this shouldn't be tested up front, since suppressAlarms is kind of static.
Attachment #279111 - Flags: review?(philipp)
Comment on attachment 279110 [details] [diff] [review]
late calendar list init

 
>+    getCalendars: function cmgr_getCalendars(count) {
>+        this.assureCache();        
Trailing whitespaces. Looks fine otherwise. r=philipp
Attachment #279110 - Flags: review?(philipp) → review+
Attachment #279111 - Flags: review?(philipp) → review+
Patches checked in on HEAD and MOZILLA_1_8_BRANCH.
Target Milestone: --- → 0.7
The fact that registered calendars are added to the composite by default in onregisterCalendar() is quite unfortunate and slows down the app enormously w.r.t. WCAP. We should negotiate the default for "in-composite". IMO a calendar pref fits best for that, e.g. "in-composite-default". There's only a minor problem: prefs can only be saved once the calendar is registered...
I would prefer that we change the overall calendar prefs handling the way that clients call on the calendar instance instead of the calendar manager, e.g. we should add

calICalendar::getCalendarPref()
calICalendar::setCalendarPref()

That way, calendar instances could easily override and provide prefs even though they are still unregistered, but could still fall back to calICalendarManager::getCalendarPref(this, ...).

Moreover, I think we are facing a growing number of prefs, thus a generic calICalendar::getCalendarPref makes IMO more sense than adding more and more attributes, especially w.r.t. optional prefs. I think this topic relates to our calendar capabilities story, which we should continue.

Back to WCAP; because of the above in-composite problem, I am switching off subscription auto registration for wcap (unless people set pref calendar.wcap.subscriptions => true).
Attached patch revising calendar prefs handling (obsolete) — Splinter Review
This patch makes prefs management more flexible, moving it from calendar manager to the providers and granting a variant API. That way, providers could e.g. save prefs on the server. Unless we've figured out the moz prefs scheme for calendar registration (bug 378754), providers could continue to save prefs using the calendar manager's storage.sdb. When we've nailed down the moz prefs model, we'll switch the providers to directly read/write into/from moz prefs, e.g. keys like

calendars.<id>.id
calendars.<id>.url
calendars.<id>.calendar-main-in-composite
...

@Philipp: I am not sure whether we should go with async prefs reading/writing, as this complicates a lot of client code and existing attributes (e.g. calICalendar::name) already come in a sync fashion. The providers could as well store the pref locally, but write back to the server asynchronously.
Attachment #279109 - Attachment is obsolete: true
Attachment #279110 - Attachment is obsolete: true
Attachment #279111 - Attachment is obsolete: true
Attachment #285236 - Flags: review?(philipp)
Daniel, Philipp:
Why are we using this bug to do double duty?  You've got patches on here that were checked in, and now there is a new patch.  Shouldn't the new patch have been in a follow-on bug?  I'm a bit confused by this, especially since this bug has a ? blocking flag.  It makes me think that this new patch also needs to go into 0.7.

Please clarify.  Thanks.
The added patch is just another piece needed to resolve comment #20. This bug is ongoing, and not blocking 0.7.
Flags: blocking-calendar0.7? → blocking-calendar0.7-
Blocks: 376585
Comment on attachment 285236 [details] [diff] [review]
revising calendar prefs handling

Add documentation that explicitly returning null in getPref() should instruct the caller to use a sensible default

Instead of getPref, use getProperty as discussed.

I think we should go ahead and get the prefs out of the calendar manager and into the moz prefs. I generally don't like functions with an underscore, but I understand the need for it here.

Just a totally unrelated, random thing that comes to mind: For multiple calendar windows, we have multiple composite calendars, but only one calendar pref that tells us if the calendar is in composite. We definitively need to investigate multiple window support at some point.
Attachment #285236 - Flags: review?(philipp) → review+
(In reply to comment #24)
> Just a totally unrelated, random thing that comes to mind: For multiple
> calendar windows, we have multiple composite calendars, but only one calendar
> pref that tells us if the calendar is in composite. We definitively need to
> investigate multiple window support at some point.
W.r.t. to 0.8 we should at least use different composite calendars for today pane and calendar view, thus there is no correlation, e.g. run by "todaypane-in-composite".
Keywords: checkin-needed
Whiteboard: [checkin-needed after 0.7]
- updating patch to reflect philipp's comments
- carrying r+ forward
Attachment #285236 - Attachment is obsolete: true
Attachment #286138 - Flags: review+
OS: Windows XP → All
Hardware: PC → All
Target Milestone: 0.7 → 0.8
Checked in on HEAD and MOZILLA_1_8_BRANCH.

WCAP auto-provisions/registers an accounts subscriptions now once. The dialog will be handled in bug 376585.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [checkin-needed after 0.7]
Status: RESOLVED → VERIFIED
Whiteboard: [gdata-cvs]
Attachment #279110 - Attachment is obsolete: false
Flags: blocking-calendar0.7-
Whiteboard: [gdata-cvs] → [gdata-0.4]
You need to log in before you can comment on or make changes to this bug.