6.0.0-git
2019-04-24

[#12482] Don't send notifications to organiser
Summary Don't send notifications to organiser
Queue Kronolith
Queue Version Git master
Type Bug
State Resolved
Priority 1. Low
Owners mrubinsk (at) horde (dot) org
Requester simon (at) simonandkate (dot) net
Created 2013-07-19 (2105 days ago)
Due
Updated 2016-02-04 (1175 days ago)
Assigned 2016-02-02 (1177 days ago)
Resolved 2016-02-04 (1175 days ago)
Milestone
Patch No

History
2016-02-04 15:52:20 Michael Rubinsky Comment #13
State ⇒ Resolved
Reply to this comment
Is this still happening with the recent organizer/attendee refactoring?
Yes. Invites are still sent to all users listed in the attendees 
list, including the organizer.
Actually, I lied. This was already implemented, but had some issues in 
some cases - like when an attendee altered his/her response an iTip 
would be sent to the ORGANIZER with a ITIP_REPLY as expected, but an 
additional ITIP_REQUEST would also be sent. This has now been fixed, 
along with some more checks that only the ORGANIZER's copy of the 
event can trigger requests/updates.
2016-02-02 15:38:25 Michael Rubinsky Comment #12
Assigned to Michael Rubinsky
Taken from Jan Schneider
Version ⇒ Git master
Reply to this comment
Is this still happening with the recent organizer/attendee refactoring?
Yes. Invites are still sent to all users listed in the attendees list, 
including the organizer.

Will fix.
2016-02-02 10:32:50 Jan Schneider Comment #11 Reply to this comment
Those changes are in Git master only, for Kronolith 5
2016-02-02 10:31:24 bugs (at) miniskipper (dot) at Comment #10 Reply to this comment
Is this still happening with the recent organizer/attendee refactoring?
Horde 5.2.8 with Kronolith 4.2.11 and I am still added as attendee in 
the first try. When cancelling the creation of the event and recreate 
it I am not in the list, anymore.
2016-02-02 10:26:25 simon (at) simonandkate (dot) net Comment #9 Reply to this comment
Which updates included the refactoring Jan? I am current as at 2 weeks 
ago (Horde 5.2.8 Kronolith 4.2.11) and it still behaves exactly the 
same as in the original post.

I have the pref:  "Don't send me a notification if I've added, changed 
or deleted the event?" ticked, but it still does anyway.
2016-02-02 09:52:55 Jan Schneider Comment #8
State ⇒ Feedback
Reply to this comment
Is this still happening with the recent organizer/attendee refactoring?
2015-03-20 07:03:23 bugs (at) miniskipper (dot) at Comment #7 Reply to this comment
I noticed the following behaviour on my System:

If I create a new meeting and add attendees, I am added as an 
attendee, myself. I would then cancel the creation of the meeting.
Then i create a new meeting and I am not added to the attendees list, anymore.

But: when I refresh the browser or navigate to another Horde-module 
and create a new meeting, I am again added to the attendee list.
2014-03-21 12:41:01 Jan Schneider Assigned to Jan Schneider
State ⇒ Assigned
 
2014-03-21 12:40:48 Jan Schneider Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 1. Low
 
2014-03-21 12:40:22 Jan Schneider Comment #6 Reply to this comment

[Show Quoted Text - 12 lines]
This exists in basic view.
2014-02-12 16:26:18 bugs (at) miniskipeptr (dot) at Comment #5 Reply to this comment
There is a (user) setting for kronolith which should prevent sending 
status/invites to the address of the owner, but is does not work :-(
I would even prefer to not get added automatically as event creator...
If you dont want to add yourself (organizer) to the attendee list 
(personally, I prefer this):
Change
   'onAdd' => 'function(attendee) { 
KronolithCore.addAttendee(attendee); 
KronolithCore.checkOrganizerAsAttendee();  }',
in kronolith/index.php to
   'onAdd' => 'function(attendee) { KronolithCore.addAttendee(attendee); }',

(for 4.4.4 this is line 115)



If you want to add yourself, but not send the email:
Add
   if ($ident->getValue('event_notification_exclude_self') &&
       $email === $ident->getValue('from_addr')) {
       continue;
   }
to kronolith/lib/Kronolith.php in function sendITipNotifications()  before
   /* Determine all notification-specific strings. */
   switch ($action) {

(for Kronolith 4.1.4 this is around line 2116)


This is just quick and dirty, there surely is a more elegant solution.
2013-10-04 14:27:12 lst_hoe02 (at) kwsoft (dot) de Comment #4 Reply to this comment
There is a (user) setting for kronolith which should prevent sending 
status/invites to the address of the owner, but is does not work :-(
I would even prefer to not get added automatically as event creator...
2013-09-26 11:02:07 jmozdzen (at) nde (dot) ag Comment #3 Reply to this comment
I notice when i add someone as attendee to a new meeting in the 
Kronolith dynamic GUI, it also now adds me automatically. This is a 
good thing. :)
[...]
I would have though that Kronolith should parse the owner's known 
email addresses and any that match should be excluded from 
notifications when the owner creates / modifies / deletes.
something needed on top of this would be a UI in kronolith to change 
the status of participants - as far as I can see this is not 
implemented (yet), but only handled by "importing" status updates sent 
via email.
2013-09-26 06:49:48 sascha (at) schmidt (dot) ps Comment #2 Reply to this comment
I think the prio of this bug should be changed from "low" to "medium"...
2013-07-19 12:45:15 simon (at) simonandkate (dot) net Comment #1
Type ⇒ Enhancement
State ⇒ New
Priority ⇒ 1. Low
Summary ⇒ Don't send notifications to organiser
Queue ⇒ Kronolith
Milestone ⇒
Patch ⇒ No
Reply to this comment
I notice when i add someone as attendee to a new meeting in the 
Kronolith dynamic GUI, it also now adds me automatically. This is a 
good thing. :)

However, as a result I get an invitation to my own meeting, and when I 
cancel the meeting and send notification, I get a cancellation email 
that when I click on it pretending to be a numpty user that has no 
idea returns an error message that it can't be found (as I have 
deleted it).

I would have though that Kronolith should parse the owner's known 
email addresses and any that match should be excluded from 
notifications when the owner creates / modifies / deletes.

Saved Queries