168176 - Use calendar NAME or X-WR-CALNAME property when setting up Calendar

Status: NEW

(Calendar :: General, enhancement)

Description

[ajbu]

iCal adds a property 'X-WR-CALNAME' to the VCALENDAR object to store the 
calendar name. Would be nice if calendar could read this as suggested name or 
automagicly adds the name.
Published calendars could also use this.
This must probably go into libxpical

BEGIN:VCALENDAR
CALSCALE:GREGORIAN
X-WR-TIMEZONE;VALUE=TEXT:US/Pacific
PRODID:-//Apple Computer\, Inc//iCal 1.0//EN
X-WR-CALNAME;VALUE=TEXT:US Holidays
X-WR-RELCALID;VALUE=TEXT:908D18FE-C416-11D6-BA97-003065F198AC
VERSION:2.0
BEGIN:VEVENT
UID:908CB02E-C416-11D6-BA97-003065F198AC
DTSTAMP:20020822T225358Z
SUMMARY:New Year's Day
RRULE:FREQ=YEARLY;INTERVAL=1;BYMONTH=1
DTSTART;VALUE=DATE:20020101
DTEND;VALUE=DATE:20020102
END:VEVENT

Comment 1

[Mike Potter]

->Mostafa.
Not sure if this should be done for 1.0 or not...

Comment 2

[Brant Gurganus]

Default QA Contact for Calendar has changed.  If you wish to remain the QA
contact for this bug, feel free to change it back.

Comment 3

[Luke Hankins]

I'm not sure how people publish to random scripts that would find this useful.  
(publish.php from phpicalendar, for example.)  Am I missing something obvious?

Comment 4

[Michiel van Leeuwen (email: mvl+moz@)]

*** Bug 246902 has been marked as a duplicate of this bug. ***

Comment 5

[Mostafa Hosseini]

Since bug 246902 has a slightly different request I'll repeat the summary:

when an *.ics file that is created using calendar and then copied onto an iPod
the entries all appear under other on the iPod, this is down to Apple's iCal
program putting the following in the ics files and calendar not :-

X-WR-CALNAME:foobar

Any chance of an enhancement in calendar to do the same thing.

Reproducible: Always
Steps to Reproduce:
1. create a new calendar 
2. copy the *.ics file over onto the iPOd
3. view the calendar page on the iPod
4. every new calendar goes under other

Actual Results:  
all the different cal files appear under an entry called other as X-WR-CALNAME
is missing from the ics file

Expected Results:  
Insert a line with the following :-

X-WR-CALNAME:foobar

or just ignore a line starting X-WR-CALNAME: so people can just take a text
editor to the ics files

Comment 6

[ajbu]

Funny, I just bought an iPod, and installed Calendar as it seems perfect for
editing iPod calendars. took me some hours to figure out how iPod's multiple
calendar feature works, and then came out to my own bug filed two years ago...

This field would be very usefull for the iPod, as the iPod connects to the PC as
an USB drive, and the calendars are simply a directory with ICS files, Calendar
can work on the iPod directly.

It would probably be not much work for me to implement this.

Question is how
1) Always add this tag? : Seems a bit ugly to add an Apple tag, but doesn't harm
and is cleanest/transparent for the user
2) An option 'add iPod tag' in the New Calendar Window? : This option might be
confusing for the users and makes the GUI more complex
3) Have users edit the .ics file manually? : 
If 3, should the name be updated when the calendar name is edited from the Edit
Calendar window?

Personally I would think 1) is the cleanest, althought it seems awkward to add a
Apple tag.

Other suggestions?
As I want this for myself I am willing to implement this.

Comment 7

[Andy Kniveton]

I'd go for option 1, but make it a preference in the menu's somewhere.

i.e create "iCal Calendar name support" Y/N radio buttons

Worst case I'd be happy to take a text editor to the ics file if Calendar just
ignored any line starting "X-WR-CALNAME;VALUE="

Comment 8

[Mostafa Hosseini]

I opt for a hidden setting on the calendar itself. If it were to be the old way
this would be an RDF attribute but since interfaces are changing nowadays make
sure this attribute is set using the correct interface.
BTW, welcome back ajbu!

Comment 9

[Matthew (lilmatt) Willis]

(In reply to comment #8)
> I opt for a hidden setting on the calendar itself. If it were to be the old way
> this would be an RDF attribute but since interfaces are changing nowadays make
> sure this attribute is set using the correct interface.

Mostafa,
I'm not sure if I understand what you want us to do.
Do you mean create a hidden pref for MozCal that when set to true adds a
X-WR-CALNAME entry to every event in that calendar using the calendar's name?

Comment 10

[Michiel van Leeuwen (email: mvl+moz@)]

X-WR-CALNAME is aprt of the vcalendar, not vevent. SO what should happen is that
unkown propertyies of the vcalendar should not be removed when writing the calendar.
The second step will be to add the proprty to new calendars, if needed.

Comment 11

[Mostafa Hosseini]

(In reply to comment #10)
> X-WR-CALNAME is aprt of the vcalendar, not vevent. SO what should happen is that
> unkown propertyies of the vcalendar should not be removed when writing the
calendar.
I agree. That's the best solution for the case where that property and the like
already exist

> The second step will be to add the proprty to new calendars, if needed.
For this I was suggesting a hidden pref, for now anyway. Other suggestions are
welcome.

Comment 12

[jcollins]

This addition would also be useful when using the generated calendar with apps
such as phpicalendar.  It seems that it looks to use the 'X-WR-CALNAME' property
for the color legend.  Not sure if this is proper, but it's what it's looking
for.  Otherwise it strips the /'s out of the URL and uses that (which frankly is
hideous).

Comment 13

[Matthew (lilmatt) Willis]

Reassigning all automatically assigned bugs from Mostafa to nobody@m.o

Bugspam filter: TorontoMostafaMove

Comment 14

[Matthew (lilmatt) Willis]

(In reply to comment #10)
> X-WR-CALNAME is part of the vcalendar, not vevent. So what should happen is
> that unkown properties of the vcalendar should not be removed when writing the
> calendar.

The above is bug 353369

Comment 16

[Daniel Boelzle [:dbo]]

(In reply to comment #14)
> (In reply to comment #10)
> > X-WR-CALNAME is part of the vcalendar, not vevent. So what should happen is
> > that unkown properties of the vcalendar should not be removed when writing the
> > calendar.
> 
> The above is bug 353369
That bug is specifically about import/export and X-props. When subscribing to an ICS file, that bug doesn't appear, X-props are properly roundtripped by the ics provider.

Comment 17

[Daniel Boelzle [:dbo]]

Attachment: patch - v1

If I don't get this bug wrong, it's just setting X-WR-CALNAME and X-WR-TIMEZONE when writing. This patch changes some code in composite, too, because I've encountered exception like |cal.ASSERT| is not a function which looked quite strange. Changing all parameters to be different from |cal| seems to fix the problem.
W.r.t. subscribing to an ics URL it would be cool if the calendar wizard could prefill the name of the calendar in the dialog. However since reading is asynchronous (implies calICalendar::name), this might be more work.

Comment 18

[Philipp Kewisch [:Fallen][📱📆]]

Comment on attachment 359742 [details] [diff] [review]
patch - v1

Looks good, r=philipp.

Comment 19

[Daniel Boelzle [:dbo]]

Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/5edf99040107>

-> FIXED

Comment 20

[Daniel Boelzle [:dbo]]

Sorry, not yet fixed. Leaving reading X-WR-CALNAME for future patches...

Comment 21

[Philipp Kewisch [:Fallen][📱📆]]

These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".

Comment 22

[funni.clonk]

I am shocked that for 21 years it has not been possible to evaluate a property from iCalendar. 🤯 There is a property "NAME" as well as X-WR-CALNAME. The second property is even evaluated by Outlook, a Microsoft application that I usually abhor. Instead, for 21 years, one has been happy with the last part of the path from the request URI being set as the calendar name in Thunderbird.
Instead, it is being argued here that it is a custom X-property, not according to the ical standard. You do not stop at the stop sign as you should, but roll slowly over it. You'll say "That's what the others do!" So why not also with X-WR-CALNAME?

Comment 25

[Magnus Melin [:mkmelin]]

Looks like the code would be the calls leading up to https://searchfox.org/comm-central/rev/bc30f4824bfb5cab668d0be4a939291ea66d3e1c/calendar/providers/ics/CalICSProvider.sys.mjs#417.