353369 - X- properties inside VCALENDAR are not roundtripped on import/export

Status: NEW

(Calendar :: Import and Export, defect)

Description

[Matthew (lilmatt) Willis]

X-* properties inside VCALENDAR, but not inside a VEVENT or VTODO, are lost when importing and then exporting an ICS file which contains them.

Comment 1

[Matthew (lilmatt) Willis]

Attachment: Original ICS from iCal.app

Comment 2

[Matthew (lilmatt) Willis]

Attachment: ICS as exported from Sunbird

Note the missing X-WR-CALNAME, X-WR-RELCALID and X-WR-TIMEZONE

Comment 3

[Dan Mosedale (:dmosedale, :dmose)]

This should be easy to fix; marking as blocking.

Comment 4

[Dan Mosedale (:dmosedale, :dmose)]

It turns out that fixing this would be non-trivial.  Additionally, "Import" and "Export" lose data in many programs for many different reasons.  As long as the provider doesn't lose this data when subscribing, I think that's sufficient for 0.3.

Comment 5

[Matthew (lilmatt) Willis]

After speaking with Cyrus Daboo at Calconnect, it's clear that this is a bug that we do in fact want to fix.

Bug 308538 is for the same problem, but in VALARM, and I suspect we'll eventually run into something similar with VTIMEZONE.

One possible avenue would be to refactor the X-Props -> Property Bag code currently used by VEVENT and VTODO so that it could be used not only by VCALENDAR, but VALARM, VTIMEZONE, and VWHATEVER.

Comment 6

[Michael Büttner (no reviews TFN)]

taking this one.

Comment 7

[Matthew (lilmatt) Willis]

Note that other properties aren't serialized, such as METHOD.

See the iTIP email service for details.

Comment 8

[Matthew (lilmatt) Willis]

Not going to make the 0.5 train.

Comment 9

[Philipp Kewisch [:Fallen][☁️📆]]

Afaik we have no API to actually get/set calendar-specific ICAL attributes. We need to agree on something here first.

Unfortunatly we already have get/setProperty that do different things. We could go with get/setICALProperty() maybe. Opinions?

Comment 10

[Daniel Boelzle [:dbo]]

I think the only relevant use case is lossless roundtripping from/to storage (Home) calendar. How about using the meta-data API for this purpose, mapping property names to metadata ids.

Comment 11

[Daniel Boelzle [:dbo]]

Hmm, thinking further about this, mapping property names to metadata ids doesn't work, because properties may occur multiple times. But I think we can serialize all top-level ical properties and save them under a single metadata id, e.g. |icalProperties|.

Comment 12

[Daniel Boelzle [:dbo]]

I tend to think it may not be sensible to roundtrip those properties at all when importing. I think top-level properties are part of a specific calendar. When merging *multiple* calendars together into a single one this may not make sense, e.g. multiple X-WR-TIMEZONE or X-WR-CALNAME properties in the same calendar.

On the other hand, I think this bug/feature makes sense when caching a single calendar, preserving its top-level X-props.

Opinions? Should we refine this bug?

Comment 13

[Bas van den Bosch]

This bug is about import/export, imho the x-props don't have to be preserved as Lightning takes over the whole calendar. As for subsribing to external storages, in these cases the x-props should be preserved as the storages may be accessed from different clients. Caching is the same as subscribing so the x-props should be preserved but this is outside the scope of this bug imho.

Comment 14

[Daniel Boelzle [:dbo]]

Indeed, and since ics subscriptions already preserve top-level properties, caching is the only bug left. Right?

Comment 15

[Philipp Kewisch [:Fallen][☁️📆]]

Shouldn't block 1.0, especially since we aren't very far with discussion here and there is noone to drive this.

Comment 16

[Daniel Boelzle [:dbo]]

Just to rephrase my recent thoughts on this and agree with Bas: I don't think we want this for importing (proposing WONTFIX), though the feature would be nice w.r.t. caching (should be different bug IMO).