On Mon, 2015-05-04 at 14:30 +0200, Jay Strict wrote:
> But maybe it is too much of an effort...?
Hi,
not necessarily too much. The problem is that evolution uses the UID
(and eventually RID - recurrence ID) as an identifier of the event,
thus it can operate with it in the UI, and even with the local cache.
Is the calendar public, thus anyone can use it, or it's a semi-private
calendar? Being it a public calendar maybe someone can look on it. All
there matters is the version of the .ics file. The RFC I gave a link
to describes version 2.0. Earlier versions didn't have the UID
mandatory. Maybe a change in the On The Web calendar could be done to
add artificial UID properties for older versions of the .ics files.
> [On a side note, let me state that I feel it is a bug in Evolution
> that Evolution does display the error messages *only* in the log
> files. Regarding the GUI one gets the impression that the .ics file
> was imported just fine. Would you agree that this is a bug? Should I
> report it to the bug tracker?]
It depends on the point of view. Say you've 100 events in the .ics
file. Each being affected by a different issue, some with missing UID,
some with other issues. How would you report such issue to the user?
Collecting all the errors and sending them all at once, cluttering the
UI? The other thing is that with the On The Web calendars you usually
do not have any way to influence the content, as in your case. I know
it's no strong argument, I'm just thinking aloud. I agree that there
could be a notice that not all events (tasks or memos) were shown from
the .ics file (this answers one of my above questions too).
Bye,
Milan
_______________________________________________
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list
