Closed macosforgebot closed 13 years ago
macosforgebot
commented
13 years ago mail@… originally submitted this as comment:1:ticket:414
I have one more information: The mail that is send out to other attendees still has the correct line breaks. So they get reset somewhere later...
macosforgebot
commented
13 years ago mail@… originally submitted this as comment:2:ticket:414
Another finding is that the
double on each save. This means when saving \\n I get \\\\n} back and it continues.
macosforgebot
commented
13 years ago mail@… originally submitted this as comment:3:ticket:414
it is not just the VEVENT it seems to happen in every VOBJECT (I tried the VTODO).
I double checked that I am using vobject library as of revision 219 and the three patches from source:/CalendarServer/trunk/lib-patches/vobject/ are applied.
macosforgebot
commented
13 years ago mail@… originally submitted this as comment:4:ticket:414
I tried to debug this yesterday on IRC with dre.
Testing this with iCal is somehow difficult. Entering an event with iCal the line breaks stay correct, BUT enabling the HTTP debugging in iCal I think the even is not even read again. I can see the PUT Request, but then just the ETag is compared and the event is not reread from the server.
Looking at an iCal created event from Lightning or iOS shows again the \n in the text ...
macosforgebot
commented
13 years ago @wsanchez originally submitted this as comment:5:ticket:414
macosforgebot
commented
13 years ago @wsanchez originally submitted this as comment:6:ticket:414
macosforgebot
commented
13 years ago @dreness originally submitted this as comment:7:ticket:414
Replying to mail@…:
I tried to debug this yesterday on IRC with dre.
Testing this with iCal is somehow difficult. Entering an event with iCal the line breaks stay correct, BUT enabling the HTTP debugging in iCal I think the even is not even read again. I can see the PUT Request, but then just the ETag is compared and the event is not reread from the server.
Looking at an iCal created event from Lightning or iOS shows again the \n in the text ...
New description:
(sorry for the spam, my first attempt at replying was wrong so I had to roll the ticket back)
I'm not able to reproduce this using current trunk (r6917), iCal (Version 4.0.4 (1395) in Mac OS X 10.6.5, and iOS 4.2.1. Creating and event with iCal and iOS both seem to produce the same correct behavior, and I'm also able to edit the events later without seeing any additional unexpected line breaks.
A multi-line description is displayed as followed by CalDAVClientLibrary:
DESCRIPTION:First line\nSecond line\nThird line added later.
Looking in the DB, it also appears correct:
caldav=# select icalendar_text from calendar_object;
icalendar_text
----------------------------------------------------------------
BEGIN:VCALENDAR\r +
VERSION:2.0\r +
CALSCALE:GREGORIAN\r +
PRODID:-//Apple Inc.//iCal 4.0.4//EN\r +
BEGIN:VTIMEZONE\r +
TZID:America/Los_Angeles\r +
BEGIN:STANDARD\r +
DTSTART:20071104T020000\r +
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU\r +
TZNAME:PST\r +
TZOFFSETFROM:-0700\r +
TZOFFSETTO:-0800\r +
END:STANDARD\r +
BEGIN:DAYLIGHT\r +
DTSTART:20070311T020000\r +
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU\r +
TZNAME:PDT\r +
TZOFFSETFROM:-0800\r +
TZOFFSETTO:-0700\r +
END:DAYLIGHT\r +
END:VTIMEZONE\r +
BEGIN:VEVENT\r +
UID:CDA73304-180F-48A7-9078-643993E715E5\r +
DTSTART;TZID=America/Los_Angeles:20110214T120000\r +
DTEND;TZID=America/Los_Angeles:20110214T130000\r +
CREATED:20110214T191732Z\r +
DESCRIPTION:this is a note\nand another line\r +
DTSTAMP:20110214T201324Z\r +
SEQUENCE:4\r +
SUMMARY:ical generated event\r +
END:VEVENT\r +
BEGIN:X-CALENDARSERVER-PERUSER\r +
UID:CDA73304-180F-48A7-9078-643993E715E5\r +
X-CALENDARSERVER-PERUSER-UID:andre\r +
BEGIN:X-CALENDARSERVER-PERINSTANCE\r +
TRANSP:OPAQUE\r +
END:X-CALENDARSERVER-PERINSTANCE\r +
END:X-CALENDARSERVER-PERUSER\r +
END:VCALENDAR\r +
BEGIN:VCALENDAR\r +
VERSION:2.0\r +
CALSCALE:GREGORIAN\r +
PRODID:-//Apple Inc.//iCal 3.0m//EN\r +
BEGIN:VTIMEZONE\r +
TZID:America/New_York\r +
BEGIN:STANDARD\r +
DTSTART:20071104T020000\r +
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU\r +
TZNAME:EST\r +
TZOFFSETFROM:-0400\r +
TZOFFSETTO:-0500\r +
END:STANDARD\r +
BEGIN:DAYLIGHT\r +
DTSTART:20070311T020000\r +
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU\r +
TZNAME:EDT\r +
TZOFFSETFROM:-0500\r +
TZOFFSETTO:-0400\r +
END:DAYLIGHT\r +
END:VTIMEZONE\r +
BEGIN:VEVENT\r +
UID:78C21AD7-EF28-4FEB-B515-92CCB26D8E71\r +
DTSTART;TZID=America/New_York:20110214T160000\r +
DTEND;TZID=America/New_York:20110214T170000\r +
DESCRIPTION:First line\nSecond line\nThird line added later.\r+
DTSTAMP:20110214T201826Z\r +
LAST-MODIFIED:20110214T201826Z\r +
SEQUENCE:0\r +
SUMMARY:iOS generated event\r +
END:VEVENT\r +
BEGIN:X-CALENDARSERVER-PERUSER\r +
UID:78C21AD7-EF28-4FEB-B515-92CCB26D8E71\r +
X-CALENDARSERVER-PERUSER-UID:andre\r +
BEGIN:X-CALENDARSERVER-PERINSTANCE\r +
TRANSP:OPAQUE\r +
END:X-CALENDARSERVER-PERINSTANCE\r +
END:X-CALENDARSERVER-PERUSER\r +
END:VCALENDAR\r +
(2 rows)Also, I just learned that this exact issue was encountered at CalConnect last week with an Android client. Turned out they were not handling "\n" properly on their side. They were expecting an uppercase N, not lowercase.
-dre
macosforgebot
commented
13 years ago @dreness originally submitted this as comment:8:ticket:414
The server is behaving properly here so we'll close this ticket; please file a bug with any clients that don't treat \n as line break.
macosforgebot
commented
13 years ago mail@… originally submitted this as comment:9:ticket:414
as written in the comments above I have -- different than you -- \\n in the database.
Therefore the clients show \n this is expected.
Please remember that the mail which is sent out as invitation still is correct.
macosforgebot
commented
13 years ago @dreness originally submitted this as comment:10:ticket:414
Replying to mail@…:
as written in the comments above I have -- different than you --
\\nin the database.Therefore the clients show
\nthis is expected.Please remember that the mail which is sent out as invitation still is correct.
Does this problem reproduce on your end when using only iOS or iCal clients?
macosforgebot
commented
13 years ago mail@… originally submitted this as comment:11:ticket:414
Yes it does. For more information ave a look at comment:4.
macosforgebot
commented
13 years ago @dreness originally submitted this as comment:12:ticket:414
Replying to mail@…:
Yes it does. For more information ave a look at comment:4.
Can you please check the encoding of your caldav database? You can use the psql --list command for this, e.g.:
part5:~ admin$ psql -U admin caldav -l
List of databases
Name | Owner | Encoding | Collation | Ctype | Access privileges
------------+--------+-----------+-----------+-------+-------------------
augments | admin | SQL_ASCII | C | C |
caldav | caldav | SQL_ASCII | C | C |
phppgadmin | admin | SQL_ASCII | C | C |
postgres | admin | SQL_ASCII | C | C |
proxies | admin | SQL_ASCII | C | C |
template0 | admin | SQL_ASCII | C | C | =c/admin +
| | | | | admin=CTc/admin
template1 | admin | SQL_ASCII | C | C | =c/admin +
| | | | | admin=CTc/admin
(7 rows)We're looking for SQL_ASCII.
Thx, -dre
macosforgebot
commented
13 years ago mail@… originally submitted this as comment:13:ticket:414
I have the following in my database:
fm@thinkpad:~/rpmbuild # LANG=en_US psql -U postgres caldav -l
List of databases
Name | Owner | Encoding | Collation | Ctype | Access privileges
-----------+-------------+----------+-------------+-------------+-----------------------
caldav | caldav | UTF8 | de_DE.UTF-8 | de_DE.UTF-8 | But after upgrading my system PyGreSQL vom 3.8.1 to 4.0.0 it seems to work, so for me this issue is currently solved.
macosforgebot
commented
13 years ago @wsanchez originally submitted this as comment:14:ticket:414
mail@… originally submitted this as ticket:414
I have reproduced this with an iPhone and with Lightning.
Response:
looking in the database, the event has
\\nand accessing the vcard via the webinterface results in\\ntoo.Which path does this data take and where could it be modified?