[Tickets #3965] Re: Track the Organizer of events

[noreply at bugs.horde.org]

BITTE NICHT AUF DIESE NACHRICHT ANTWORTEN. NACHRICHTEN AN DIESE  
E-MAIL-ADRESSE WERDEN NICHT GELESEN.

Ticket-URL: https://bugs.horde.org/ticket/3965
------------------------------------------------------------------------------
  Ticket           | 3965
  Aktualisiert Von | lang at b1-systems.de
  Zusammenfassung  | Track the Organizer of events
  Warteschlange    | Kronolith
  Version          | Git master
  Typ              | Enhancement
  Status           | Accepted
  Priorität        | 2. Medium
  Milestone        |
  Patch            |
  Zuständige       | Ralf Lang (B1 Systems GmbH), Horde Developers
------------------------------------------------------------------------------


lang at b1-systems.de (2015-01-10 17:21) hat geschrieben:

> 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.