108.02 KB, text/plain
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:22.214.171.124) Gecko/2008072820 Firefox/3.0.1 Build Identifier: Ligthning 0.9pre 2008081218 Hi, I have discovered this after having restored a full calendar backup from one of my users... If I load this event in my SUN calendar server: <UID>00000000000000000000000000000000485f708b000022e50000001a00002607</UID> <DTSTAMP>20080827T142338Z</DTSTAMP> <SUMMARY>2 Didier Grandjean 2</SUMMARY> <START>20080624T130000Z</START> <END>20080624T140000Z</END> <CREATED>20080623T094443Z</CREATED> <LAST-MOD>20080827T141535Z</LAST-MOD> <PRIORITY>0</PRIORITY> <SEQUENCE>2</SEQUENCE> <CLASS>PUBLIC</CLASS> <LOCATION>Rue des Battoirs</LOCATION> <ORGANIZER CN="Pierre-Luc BOUCHERON" X-NSCP-ORGANIZER-UID="bouchero:TEST-pour-PLB" X-S1CS-EMAIL="Pierre-Luc.Boucheron@unige.c h">bouchero:TEST-pour-PLB</ORGANIZER> <STATUS>CONFIRMED</STATUS> <TRANSP>OPAQUE</TRANSP> <CATEGORIES>Appointment</CATEGORIES> <X-NSCP-DTEND-TZID>Europe/Paris</X-NSCP-DTEND-TZID> <X-NSCP-ORIGINAL-DTSTART>20080624T130000Z</X-NSCP-ORIGINAL-DTSTART> <X-NSCP-LANGUAGE>en</X-NSCP-LANGUAGE> <X-NSCP-DTSTART-TZID>Europe/Paris</X-NSCP-DTSTART-TZID> <X-NSCP-TOMBSTONE>0</X-NSCP-TOMBSTONE> <X-NSCP-ONGOING>0</X-NSCP-ONGOING> <X-NSCP-ORGANIZER-EMAIL>Pierre-Luc.Boucheron@unige.ch</X-NSCP-ORGANIZER-EMAIL> <X-NSCP-GSE-COMPONENT-STATE X-NSCP-GSE-COMMENT="PUBLISH-COMPLETED">65538</X-NSCP-GSE-COMPONENT-STATE> </EVENT> when I open it with ligthning, his category is displayed like this: AppointmentX-NSCP-DTEND-TZIDEurope/Paris and I am not able to change this when saving again this event. What's make me think there is a problem in Ligthning is if you load the same event after having move the <X-NSCP-DTEND-TZID> tag after the tag <X-NSCP-ORIGINAL-DTSTART> (for example) there is no problem when you display the category of this event in ligthning. What do you think about this ??? PS: I hope I was clear ... ??? Reproducible: Always Steps to Reproduce: 1. 2. 3.
The WCAP provider uses ical parsing for calendar data, not XML. What program are you using for import/export?
Hi Daniel, We are using the standard import/export tools available with Sun Calendar server (i.e. csimport and csexport). They are generaly available in /opt/SUNWics5/cal/sbin: # ./csimport -v -c bouchero:TEST-pour-PLB calendar /var/tmp/event.xml Communication Express is also able to import/export in XML csexport is the tool we use to backup every calendar's user each 3 hours. It output every user data (calendar right / event / task) in XML (it's the only format available) and csimport to restore a task / event or the full calendar. It's after a full calendar restore with csimport of one of our user I have discovered the problem I have describe before. Note that the problem also occurs when you import the XML event using Communication Express. PL
Maybe I am missing something, but if you use cs tools only, why do you file a bug against lightning/sunbird then? You report that cs seems to return mixed up CATEGORIES entries, most probably caused by the import/export. You could verify that by taking a log (see <https://wiki.mozilla.org/Calendar:WCAP_Provider#Logging>).
(In reply to comment #3) > Maybe I am missing something, but if you use cs tools only, why do you file a > bug against lightning/sunbird then? > You report that cs seems to return mixed up CATEGORIES entries, most probably > caused by the import/export. You could verify that by taking a log (see > <https://wiki.mozilla.org/Calendar:WCAP_Provider#Logging>). Thanks Daniel for your answer. I really understand your interrogation. But I have decided to fill a lightning bug because even Convergence and Communication Express are not affected by this bug. However I agree that the source of the problem may perhaps yield in the csexport/csimport tools. I'll try to add as attachment the log file. The affected event is the one which as this summary: "2 Didier Grandjean 2" I don't think there is something around mixed up categories entries BEGIN:VEVENT^M UID:00000000000000000000000000000000485f708b000022e50000001a00002607^M DTSTAMP:20080902T074044Z^M SUMMARY:2 Didier Grandjean 2^M DTSTART:20080624T130000Z^M DTEND:20080624T140000Z^M CREATED:20080623T094443Z^M LAST-MODIFIED:20080829T145640Z^M PRIORITY:0^M SEQUENCE:3^M CLASS:PUBLIC^M LOCATION:Rue des Battoirs^M ORGANIZER;CN="Pierre-Luc BOUCHERON"^M ;X-NSCP-ORGANIZER-UID=bouchero:TEST-pour-PLB^M ;X-S1CS-CALID="bouchero:TEST-pour-PLB"^M :mailto:Pierre-Luc.Boucheron@unige.ch^M STATUS:CONFIRMED^M TRANSP:OPAQUE^M CATEGORIES:Affaire^M X-NSCP-DTEND-TZID:Europe/Paris^M X-NSCP-ORIGINAL-DTSTART:20080624T130000Z^M X-NSCP-LANGUAGE:fr^M X-NSCP-DTSTART-TZID:Europe/Paris^M X-NSCP-TOMBSTONE:0^M X-NSCP-ONGOING:0^M X-NSCP-ORGANIZER-EMAIL:Pierre-Luc.Boucheron@unige.ch^M X-NSCP-GSE-COMPONENT-STATE;X-NSCP-GSE-COMMENT="PUBLISH-COMPLETED":65538^M END:VEVENT^M However the X-NSCP-DTEND-TZID tag start with a space ... The problem is may be here ??? Thanks, PL
(In reply to comment #4) > However the X-NSCP-DTEND-TZID tag start with a space ... > The problem is may be here ??? This looks exactly like the issue. According to the iCalendar standard a line break followed by a space defines that this is one content line that has been just folded to multiple lines. <http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-08#section-3.1> Therefore the iCalendar parser sees only one line CATEGORIES:AffaireX-NSCP-DTEND-TZID:Europe/Paris and displays it that way. --> server issue
Sunbird/Lightning correctly parses the server's output (folded line). This seems to be a server or csimport bug => marking INVALID.
Hi, Thanks Stefan & Daniel for your diagnotic. I agree with you. I'll open a case @SUN to get fix this cs problem. Thanks for your help. PL
FYI: I've already forwarded the problem, a bug will be opened to be fixed.
Paradise on earth !!! Many thanks for this action Daniel. When avalaible can you send me the bugid ??? PL