Closed Bug 429488 Opened 16 years ago Closed 16 years ago

Email drag and drop populates attendee list and causes failure to save event.

Categories

(Calendar :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: brian.utterback, Assigned: dbo)

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.8.1.14pre) Gecko/20080330 Firefox/2.0.0.14pre
Build Identifier: Lightning 0.8 (build 2008040403)

In the 0.8 version of Lightning, the ability to drag and drop an email message to the Calendar icon was added. I dragged and dropped an email, and new event dialog popped up, with the text of the email in the comments section. The "To:" field of the email was used to populate the attendees mailing list. There was no way to edit this field and remove the incorrect entry. When saving the event, I got an error that said: 

"There has been an error readint data for calendar: mycal. Howvever, this error is believed to be minor, so the program will attempt to continue. 

Error number: 0x804a023c
Description: Currently used when attendee or organizer specified does not have a valid email address."

After hitting "OK" there is no further message, but the event is not saved. In this case the calendar server is Java Calendar Server using WCAP. 

There doesn't seem to be any information about what format the email should be in to correctly populate the fields. It is ironic that the only field actually parsed and populated was the attendee field, which prevented the event from being saved at all.

Reproducible: Always

Steps to Reproduce:
1. Drag and drop email to calendar were email as "To:" that is a mailing list. 
2. Verify that "To:" field is used to populate "attendee" field.
3.
(In reply to comment #0)
...
> field of the email was used to populate the attendees mailing list. There was
> no way to edit this field and remove the incorrect entry. When saving the
> event, I got an error that said: 
You could open the invitation pane, e.g. pressing the "Invite Attendees", and remove attendees, don't you?
The error message 0x804a023c above is specific to the WCAP calendar provider.

Does this happens with other calendars (e.g. local storage or ics file) too?
Flags: wanted-calendar0.9+
jrobertpayne: please don't set flags to +, this is reserved for release drivers. If you want this bug fixed for the next version, you can request it by setting the flag to ?
Flags: wanted-calendar0.9+
Can't confirm this for webdav or local. As for editing, pressing the invite-button or choosing options-invite attendees works but there's no context-menu for editing when pressing the names in the event-dialog.
Component: Lightning Only → Provider: WCAP
QA Contact: lightning → wcap-provider
Hi,

I can confirm that we are also affected by this problem.

We are running the last Sun calendar version:
Sun Java(tm) System Calendar Server 6.3-8.01 (built May  5 2008)

I can reproduce the problem as described with Lightning 0.8 and 0.9pre

I try to drag and drop an e-mail (containing the address Marc.Twain@unige.ch) to the calendar icon and I save it immediately.

Here's what I have on my calendar logs: 

[03/Jul/2008:16:26:19 +0200] oscar cshttpd[9735]: General Warning: calparser:  No Available Email address in ldap for calid: Marc.Twain@unige.ch
[03/Jul/2008:16:26:19 +0200] oscar cshttpd[9735]: General Error: WCAP: storeevents command called. ac_storecomponents() returned with 60.

And on our ldap server:

[03/Jul/2008:16:26:18 +0200] conn=812 op=1413 msgId=1414 - SRCH base="dc=unige,dc=ch" scope=2 filter="(icsCalendar=Marc.Twain@unige.ch)" attrs="uid mail icsCalendar cn objectClass memberURL uniqueMember givenName sn owner icsSecondaryowners groupid icsDefaultacl icsTimezone icsDoublebooking icsAutoaccept aclGroupAddr icsExtendedUserPrefs icsStatus icsFreeBusy"
[03/Jul/2008:16:26:18 +0200] conn=812 op=1413 msgId=1414 - RESULT err=0 tag=101 nentries=0 etime=0
[03/Jul/2008:16:26:18 +0200] conn=812 op=1414 msgId=1415 - SRCH base="dc=unige,dc=ch" scope=2 filter="(|(uid=Marc.Twain@unige.ch)(&(cn=Marc.Twain@unige.ch)(|(objectClass=groupofuniquenames)(objectClass=icsCalendarResource)(objectClass=person))))" attrs="uid mail icsCalendar cn objectClass memberURL uniqueMember givenName sn owner icsSecondaryowners groupid icsDefaultacl icsTimezone icsDoublebooking icsAutoaccept aclGroupAddr icsExtendedUserPrefs icsStatus icsFreeBusy"
[03/Jul/2008:16:26:19 +0200] conn=812 op=1414 msgId=1415 - RESULT err=0 tag=101 nentries=0 etime=1
[03/Jul/2008:16:26:19 +0200] conn=812 op=1415 msgId=1416 - SRCH base="dc=unige,dc=ch" scope=2 filter="(|(groupid=Marc.Twain)(&(cn=Marc.Twain)(objectClass=groupofuniquenames)))" attrs="uid mail icsCalendar cn objectClass memberURL uniqueMember givenName sn owner icsSecondaryowners groupid icsDefaultacl icsTimezone icsDoublebooking icsAutoaccept aclGroupAddr icsExtendedUserPrefs icsStatus icsFreeBusy"
[03/Jul/2008:16:26:19 +0200] conn=812 op=1415 msgId=1416 - RESULT err=0 tag=101 nentries=0 etime=0

We can see that the first search in our ldap server is for a calendar called Marc.Twain@unige.ch (icsCalendar=Marc.Twain@unige.ch). Marc Twain's calendar name is mtwain (it is his username). His icsCalendar attribute is mtwain. So the first search fails.

The second search (uid=Marc.Twain@unige.ch)(&(cn=Marc.Twain@unige.ch) fails also because Marc Twain's uid is mtwain.

Here's why we have this problem with Ligthning.

I hope I was clear. If don't just ask me more details ...

PL

PS: This is a major issue for us. I hope this bug could be fixed: thanks !

As additional information I can mention that I quite sure that the computation for the free-busy with Lightning as something wrong.

In the previous case, the computation for the free-busy for Marc.Twain@unige.ch is done by considering Marc.Twain@unige.ch as a calid which is wrong.

Just look to the function get_freebusy.wcap (http://docs.sun.com/app/docs/doc/819-4655/fxzbx?a=view): when you use the parameter calid a calid can be supplied in two formats: 

    *

      string - calendar identifier
    *

      mailto:rfc822addr - An email address appended to “mailto:”. The address is mapped to a user with an LDAP lookup, and then the user’s default calendar ID is used. Returns: X-SICS-EMAIL and X-NSCP-CALPROPS-RELATIVE-CALID

Is the problem is here ???

PL
Flags: wanted-calendar0.9?
Flags: blocking-calendar0.9?
Still additional informations:

After setting user_pref("calendar.wcap.log_level", 3); in my pref.js, here's what I have what drap'n dropping the message to calendar:

### WCAP log entry: 2008/07/04 11:12:57 Europe/Zurich isDate=0
[calWcapRequest id=739e89ea-d91d-4e9a-aa70-b9df1dda909b-26, parent-id=<none> ([context-id: d36615be-9455-4fc1-93e7-9ae8e56d9416, uri: https://bouchero@webcal.unige.ch:444/, userId=bouchero, default calendar]
adoptItem() call: 999)
attached requests:
#739e89ea-d91d-4e9a-aa70-b9df1dda909b-27        calWcapNetworkRequest id=739e89ea-d91d-4e9a-aa70-b9df1dda909b-27, parent-id=739e89ea-d91d-4e9a-aa70-b9df1dda909b-26 (https://webcal.unige.ch:444/storeevents.wcap?appid=mozilla-calendar&id=dCUJOw84Lz8&dtstart=20080704T100000Z&X-NSCP-DTSTART-TZID=X-NSCP-ORIGINAL-OPERATION=X-NSCP-WCAP-PROPERTY-REPLACE^UTC&dtend=20080704T110000Z&X-NSCP-DTEND-TZID=X-NSCP-ORIGINAL-OPERATION=X-NSCP-WCAP-PROPERTY-REPLACE^UTC&isAllDay=0&rrules=&rdates=&exrules=&exdates=&attendees=RSVP=TRUE^PARTSTAT=NEEDS-ACTION^ROLE=REQ-PARTICIPANT^Mark.Twain%40unige.ch&orgCalid=bouchero&summary=999&categories=&desc=%0D%0A--%20%0D%0A%0D%0AAvec%20mes%20meilleures%20salutations%2C%0D%0A%0D%0APierre-Luc%20Boucheron%0D%0ADivision%20Informatique%0D%0AUni-Dufour%0D%0AUniversity%20of%20Geneva%0D%0ARue%20G%C3%A9n%C3%A9ral-Dufour%0D%0A1211%20Gen%C3%A8ve%204%0D%0ASwitzerland%0D%0AT%C3%A9l%3A%20%2B41%2022%2037%2097578%0D%0AFax%3A%20%2B41%2022%2037%2097986%20%0D%0A%0D%0A&location=&icsUrl=&priority=0&icsClass=PUBLIC&status=0&transparent=0&attachments=&alarmStart=-P2D&alarmEmails=Pierre-Luc.Boucheron%40unige.ch;0786898106%40sms.switch.ch&tzid=UTC&storetype=1&mod=4&method=2&replace=1&fetch=1&relativealarm=1&compressed=1&recurring=1&emailorcalid=1&fmt-out=text%2Fcalendar&calid=bouchero), isPending=true, status=NS_OK, isPending=true, status=NS_OK]
attachSubRequest()

### WCAP log entry: 2008/07/04 11:12:57 Europe/Zurich isDate=0

...

Depending on what I can read on the documentation about the "Calendar Server WCAP Attendee Parameter" (http://docs.sun.com/app/docs/doc/819-4655/6n6pshlfb?a=view)

PARSTAT=ACCEPTED^RSVP=TRUE^mailto:abc@xyz.com

storeevents.wcap?id=${SESSIONID of org}&calid=org
                  &dtstart=20020201T200200Z
                  &dtend=20020201T210000Z
                   summary=invite_attA_attB
                  &method=2
                  &attendees=PARTSTAT=ACCEPTED^RSVP=TRUE^org;
                             PARTSTAT=NEEDS-ACTION^RSVP=TRUE^attA;
                             PARTSTAT=NEEDS-ACTION^RSVP=TRUE^attB
                  &fmt-out=text/xml



And on the iCalendar rfc:

http://www.ietf.org/rfc/rfc2445.txt
ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT:MAILTO:
      jsmith@host.com

I imagine that correct storeevents.wcap sended command must contain something like:

... /storeevents.wcap?appid=mozilla-calendar& ...&attendees=RSVP=TRUE^PARTSTAT=NEEDS-ACTION^ROLE=REQ-PARTICIPANT^mailto:Mark.Twain%40unige.ch&orgCalid=bouchero...

i.e. the "mailto:" string must be add before the e-mail address ...

What do you think about this ???

PL
Yes, PL, that seems to be the bug in the dnd code.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted-calendar0.9?
Flags: wanted-calendar0.9+
Flags: blocking-calendar0.9?
Attached patch fixSplinter Review
Assignee: nobody → daniel.boelzle
Status: NEW → ASSIGNED
Attachment #328392 - Flags: review?(philipp)
Attachment #328392 - Flags: review?(philipp) → review+
this is a general bug, not wcap related
Assignee: daniel.boelzle → nobody
Status: ASSIGNED → NEW
Component: Provider: WCAP → General
QA Contact: wcap-provider → general
Target Milestone: --- → 0.9
Assignee: nobody → daniel.boelzle
OS: SunOS → All
Hardware: Sun → All
Checked in on HEAD and MOZILLA_1_8_BRANCH => FIXED.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
(In reply to comment #11)
> Checked in on HEAD and MOZILLA_1_8_BRANCH => FIXED.
> 

Confirmed: the problem is now solved.

Thank you very much for all the great work you (and all the Calendar team) do.

I (and a lot of other people I'm sure) really do appreciate.

Thanks again.

PL
VERIFIED per comment#12
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.