Tickets :: Comment on [#3965] Track the Organizer of events

* Your Email Address
* Spam protection	Enter the letters below: ._..___.. ..__ . . \| \| \|\ \|[ __\| \| _\|_ \| \| \\|[_./\|__\|
Comment	>> We should probably also add logic to prevent sending updates to any >> attendees when $organizer != $_creator while still allowing changes >> in acceptance status to be emailed back to the $organizer. Also, do >> we want to disallow any changes to an accepted invitation's details? > > Yes, I think we still need to prevent mails to anybody but the organizer. > But how do other attendees notice that you have accepted the > invitation? Is this the organizer's (tool's) task? > > Google Calendar has two checkbox options to a) allow attendees to add > new attendees and b) edit the event. > Don't know the mechanics behind this. Normally I would assume if I > edit my local copy of an event, that these are my notes on the event > and the changes should not be shared with everybody else. > >> For me, if we disallow sending updates/cancellations this is enough, >> but some calendar clients (especially on mobile) completely lock the >> event (other than deleting it completely) when the current user is >> not the organizer. > > I think this is overkill. You should be able to at least edit the > "description" part. If this is too tricky, locking might be an option. > >>> ActiveSync users: Please test. >> >> I'll take care of the testing, though obviously others feel free to >> test as well. I've already got a fairly large number of ready-to-go >> EAS testing setups :) >> >> Once this is fully tested I can start looking at/testing turning on >> allowing access to shared calendars for ALL EAS clients and not just >> those that support multiple calendar collections. >> > > I will add some code to Kronolith::sendITipNotifications to guard > against mails to anybody but the organizer. Due by Sunday night.
Attachment
Watch this ticket

Saved Queries