459683 - Organizer not added to attendee list during event creation

Status: RESOLVED FIXED

(Calendar :: General, defect, P1)

Description

[Ciny Joy]

User-Agent:       Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.8.1.11) Gecko/20080118 Firefox/2.0.0.11
Build Identifier: Lightning 0.9

1.create event with attendee in Lightning
2.view invitation using attendee's Apple iCal
orgs's status show as "uncertain" which should be "accepted" 

the event created in lightning:

BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
DTSTART:19700308T020000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:19701101T020000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
CREATED:20080922T170137Z
LAST-MODIFIED:20080922T170218Z
DTSTAMP:20080922T170218Z
UID:a11bc712-1e27-412a-ab71-9ab555fa3d3c
SUMMARY:test from lighting
ORGANIZER;RSVP=TRUE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:
[e-mail]
ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT:mailto:
[e-mail]
DTSTART;TZID=America/Los_Angeles:20080922T110000
DTEND;TZID=America/Los_Angeles:20080922T120000
LOCATION:lighting
X-MOZ-SEND-INVITATIONS:TRUE
X-MOZ-GENERATION:1
END:VEVENT
END:VCALENDAR


Reproducible: Always

Steps to Reproduce:
1.Enable scheduling on Lightning
2.Invite a user to an event
3.View invitation as attendee using another client.
Actual Results:  
Organizer shows up as undecided.

Expected Results:  
Organizer should be a confirmed attendee for the event.

Add the Organizer as attendee and change partstat to confirmed.

Comment 1

[Andreas Treumann]

Reproducible -> change status from 'Unconfirmed' to 'New'.

Comment 2

[Filip Zrůst]

This isn't related to CalDAV only. The general problem is that Lightning doesn't produce valid iCalendar object for meetings (\w organizer and attendees). Organizer is treated the same way as attendee which is wrong, because organizer has only a small subset of parameters of attendee property and is of different type. See, organizer <http://tools.ietf.org/html/rfc5545#section-3.8.4.3> and attendee <http://tools.ietf.org/html/rfc5545#section-3.8.4.1>.

There are number of issues which tackled the general but none solved it. There was even a proposal for new, more general, interface calIPerson for using as organizer instead of calIAttendee in comments of bug 354559.

I'm not sure what the guidelines are in this case but I think a new bug should be created or this one should be changed.

Since this issue affects our products, we might be able to fix it, but we don't have any resources at the moment. We have a workaround but it is not related to CalDAV.

Comment 3

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

It would be very cool if you could invest some resources to fix this bug, I'm very much open to a fundamental change.

One thing that could be done is to change the serialization of calIAttendee to not emit those properties if mIsOrganizer is true. This would of course not fix that the organizer should be able to attend.

What we could do is change the setter for the organizer to also add to the attendees (and possibly remove the old organizer attendee if contained in the attendees array), this would require checking each place where getAttendees and the organizer getter is called to see if calling code handles this situation correctly, a simple grep should do it.

Filip, do you think you could help us out and make this a priority?

Comment 4

[Filip Zrůst]

We're very constrained by available resources at the moment as I've stopped being a full time developer and practically stopped programming. Maybe I'll find some time the next weekend. If not, it should be clearer within a month, whether and when someone can be assigned to this issue.

I like your idea and it is in fact similar to the approach we chose in our workaround. I think we'll go this way if someone doesn't take over this issue before we can create some patch.

Comment 5

[[:MakeMyDay]]

Taking this bug. Changing component, as this is not specific to caldav but a general problem how the ical is composed.

Comment 7

[[:MakeMyDay]]

Attachment: MakeOrganizerConformWithRfc5545-DialogPart-V1.diff

I attach a first WIP patch for the dialog part of the fix - no review required for now, but comments are welcome of cause. It basically changes the list setting on load, if the event already had attendees before. Also, it modifies the getters to return conforming organizer and attendes. It keeps the current behaviour to add the organizer as a meeting host by default - now as a separate attendee.

For caldav scheduling this would just be enough, as of http://tools.ietf.org/rfcmarkup?rfc=6638#section-3.2.1 the server will take take no to mess the organizer with his own invitation. For iTip, this will require some extra changes, which I am currently working on.

Comment 8

[[:MakeMyDay]]

One more thing: Does anybody know if there is also something I should take care of in the WCAP provider?

Comment 9

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Comment on attachment 8378313 [details] [diff] [review]
MakeOrganizerConformWithRfc5545-DialogPart-V1.diff

Putting this in my feedback queue so I can give more constructive feedback. Both our existing code and this patch has one potential issue: There can be multiple places new events are created (i.e from the views, in an event dialog, etc), and doing operations like adding an organizer would theoretically require fixes in all locations.

I don't know if this is the silver bullet, but we need something that gives us better control. Either a service that prepares events, or some kind of hook that sets up new events when connecting them with a calendar.

Comment 10

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Honestly I don't know how this will affect the WCAP provider. I do have (private) test server credentials somewhere, but as Sun is no longer maintaining the project, the WCAP provider has been left dormant. I think its best to just ignore it for now, email me as a reminder when this patch is in the nightly builds, then I can forward it to the folks that still depend on WCAP servers.

Comment 11

[[:MakeMyDay]]

Thank you for your feedback. Before we discuss about the way of implementation a solution here, I would like do assure we have a common understanding of how we want to deal with the participation state/role of the organizer in general, as this is a main driver to decide on the best implementation.

Currently, the organizer is carrying partstat and role information (which is violating the RfC) and is automatically treated as he/she is attending the event.

Creating a conforming organizer property itself is not be a big deal (a close to a workaround solution with a small footprint in the code base might be just to intercept the notifications process and remove invalid params from the organizer property before sending). But not to loose and to expose the partstat/role information of the organizing party to other attendees of the event, the only solution is to add the organizing party as a regular attendee property (beside the organizer property), which can can have role and partstat information. The RfC leaves this up to the client implementation to do so or not. For want I know, Lotus Notes/Domino does it in this way (at least in former releases), whereas MS Exchange - at least for email invitations - does not (and does'nt expose any partstat/role information of the organizing party thereby).

If we are receiving an invitation with the organizing party not added as attendee, we currently add the status information to make the organzer also displayed as attending party. If we follow the 'attendee' approach, we probably should not do that anymore.

Making the organizing party a mandatory participant of an event is not longer required with a conforming oragnizer property and we may want to leave this up to the calendar user (to even support more user scenarios), but especially the 'attendee'-approach would make this obvious and easy to implement without the necessity of mocking up something in the attendee dialog.

As a further  benfit, especially the 'attendee'-approach would enable us to just remove all the special case handling for the organizer everywhere, an ical with attendees is (re-)created.

Last but not least, any implementation will also need to take care of an oppurtunity to migrate existing events which are still malformed (to be hooked in on loading the event from db/remote server).

We can also apply this receiver-side migration on incoming inviation (applicable mostly in a Lightning-to-Lighting scenario)to ensure we don't need special organizer teatment in the code anymore (see balove), but this would break RfC as a replying attendee is not allowed to change the organizer property in the reply. To be prepared to handle this gracefully in cross version scenrios (as the problem is emitted by all previous Lightning installations), we would also need also a rollback functionallity for the migration to be applied when composing the response. Alternatively, we can just refuse the invitation as not conforming, but this will probaly would produce a lot of user complaints.

That said, I would appreciate any comments on
- whether or not to add the organizing party as attendee
- dealing with inviations without organizing party's partstat
- leaving the organizing party a mandatory participant or not
- removing the special case handling for the organizer everywhere
- dealing with invitations malformed due to this bug

Comment 12

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

> That said, I would appreciate any comments on
> - whether or not to add the organizing party as attendee
Generally I think it makes sense to add the organizing party as an attendee. Maybe we can handle a special case when the user sets the organizer to "not attending" in the event dialog that we don't add the organizer as an attendee. This is of course different for editing an event that already has the organizer as an attendee.


> - dealing with inviations without organizing party's partstat
You mean an invitation that has a rfc conforming ORGANIZER and no ATTENDEE that matches the organzer, right? In any case, I don't think we should be adding the partstat information, because truthfully we don't know the right state.

UI wise I think we have two options to implement this. First of all, following what I mentioned before, we could visually display the organizer as an attendee but with the state "not attending". When the item is reserialized, the organizer should not be added as an attendee.

The second option would more closely match the technical circumstances. Here we wouldn't show the organizer as an attendee at all, if the organizer adds himself (same email as organizer) as an attendee, then we consider this to be the organizer's partstat and can do special things like displaying it at the top of the attendee list.

> - leaving the organizing party a mandatory participant or not
As we both prefer the attendee approach, I think this is clear? No matter how this is implemented in the UI, we don't need to add the organizer as a mandatory participant behind the scenes. I would give the user the option of not making the organizer an attendee, using one of the UI options in the previous question.

> - removing the special case handling for the organizer everywhere
Sounds good to me

> - dealing with invitations malformed due to this bug
I generally hate migration code, but I guess there are situations where that doesn't help me. I think what we can do here really depends on how servers handle this. Theoretically we wouldn't be changing the organizer, just removing some invalid parameters. If the server is smart it will figure this out.

When receiving a such invitaiton, we could just ignore the partstat of the organizer. This would cause our code to think that the organizer is no longer an attendee, which will definitely be a problem for those that expect the organizer to attend.

I don't see a good way to migrate this without keeping most of the old crufty code. In any case, I think we should push this one some time after the next merge, so we have more time to figure out how this feels for users (otherwise it will be part of the release for TB31, which will be a major release like TB24).

Comment 13

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Comment on attachment 8378313 [details] [diff] [review]
MakeOrganizerConformWithRfc5545-DialogPart-V1.diff

Review of attachment 8378313 [details] [diff] [review]:
-----------------------------------------------------------------

f+ for the patch, the complete solution is obviously a little more though. For example, I'd suggest modifying the calAttendee.js code to not output the attendee specific parameters when creating the ical property.

Unit tests, and possibly some mozmill tests, would be great here.

Comment 14

[Sumana Harihareswara]

I recently ran into this bug while using Thunderbird/Lightning to manage my Fastmail calendar. I was running Thunderbird beta.

Possible duplicate: Bug 1621942 .

Here's what Neil from Fastmail support said to me:

The issue is that in the iCalendar data Thunderbird is creating it's putting you as the "organizer" but not putting you as an "attendee" as well. This means semantically that you are organising the event but does not mean that you are attending, hence we show you as "not going".

The relevant bit from the iCalendar data is this:

ORGANIZER;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT:mailto: [e-mail];CN=Rodrigo Example;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT; SCHEDULE-STATUS=1.1:mailto:[e-mail];CN=[e-mail];PARTSTAT=ACCEPTED;CUTYPE=INDIVIDUAL; ROLE=REQ-PARTICIPANT;X-NUM-GUESTS=0;X-DTSTAMP=20220406T144342Z; X-SEQUENCE=1;RECEIVED-SEQUENCE=1;RECEIVED-DTSTAMP=20220406T144342Z:mailto: [e-mail]

The other interesting thing here is Thunderbird has added PARTSTAT=NEEDS-ACTION to the ORGANIZER – it looks like it's trying to store attendance status on this. That's not allowed in the spec. The PARTSTAT parameter is only defined on the ATTENDEE property, not the ORGANIZER.

Comment 15

[Дилян Палаузов]

I am against changing anything here. In case ORGANIZER has already PARTSTAT, it can stay there, but some servers might reject the input.

How often do users ask theirselves, if the one who invites them for a meeting, will attend the meeting? Never! For example if person A invites person B for a dinner, will person B be certain that there will be a dinner at the appointed place, but at the same time asking itself, if person A will attend? No.

That said, software presenting iCalendar data shall make no statements, on whether the Organizer is attending or not. The users assume here the correct information from the context.

Only in cases where the user cannot assume the right attendance status, the organizer can be added manually as ATTENDEE;PARTSTAT=DECLINED (or =ACCEPTED).

Comment 18

[Andrei Hajdukewycz [:sancus]]

I Hope this is the earliest report of this issue.

Comment 20

[Sean Burke [:leftmostcat]]

Attachment: Bug 459683 - add organizer as attendee by default. r=#thunderbird-reviewers

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/91dea7821895
add organizer as attendee by default. r=aleca