1351601 - Determine in which cases to reset the PARTSTAT when other event details have changed

Status: NEW

(Calendar :: General, defect, P5)

Description

[tronde]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20170301181722

Steps to reproduce:

1. Create an event wit on attendee
2. Attendee acknowledge the event (PARTSTAT=ACCEPTED)
3. Wait until DTEND is reached
4. Right-Click on event and select copy
5. Right-Click on a day in the future and select paste
6. Double-Click event to edit title; save and exit


Actual results:

Althoug day and title changed the PARTSTAT parameter of the attendee is still ACCEPTED. The Attendee did not reveive any notification about this event.

The attendee see the new event as well with the parameter PARTSTAT=ACCEPTED.


Expected results:

After pasting the event and editing the title the parmeter PARTSTAT should be set to NEEDS-ACTION and a notification should be send to the attendee. So the attendee should have to accept or decline the event.

Additional Info: When besides day and title the time slot is altered too, PARTSET is set to NEEDS-ACTION for the attendee.

Comment 1

[tronde]

Attachment: The initial event

Comment 2

[tronde]

Attachment: Event copied and pasted to different day and time with altered title

Comment 3

[tronde]

Attachment: Event copied and pasted to different day but the same time with altered title

Comment 4

[Philipp Kewisch [:Fallen][📱📆]]

I'm confirming this. The copy/paste functionality literally makes a copy, it does not do any processing. We should figure out under which circumstances partstat changes should be made, and we should also be careful to honor user choice.

I think the actual cases under which the PARTSTAT should be changed is mentioned in one of the related RFCs, it would be good to get some quotes from those.

Comment 5

[jens.poenninghaus]

(In reply to Philipp Kewisch [:Fallen] from comment #4)

I browsed and sifted some related RFCs but found no directly focused statements and only little guidance from a broader perspective. I brought the topic to calconnect.orgs attention on order to possibly get side (client/server) and implementation independent clarification on what should be expected or considered undesirable behaviour.