Feature #4676
closedOffer silent option (no email notification) for events calendar in groups
0%
Description
When one is part of a group with a lot of events being created, the number of email notifications of new event creations can get a little overwhelming. I just had a request from someone who asked whether it is possible not to send out notifications when new events are created. i think we should add this option as we have for file uploads
Files
Related issues
Updated by Boone Gorges about 9 years ago
- Assignee changed from Boone Gorges to Daniel Jones
- Target version set to 1.9
Dan, can you take a look at this along with the other "silent" ticket I recently assigned to you? There's probably not much to be gained from having these different "silent" options share a technical foundation, but at least they should probably look the same.
Updated by Boone Gorges about 9 years ago
- Target version changed from 1.9 to 1.10
Updated by Daniel Jones almost 9 years ago
For the life of my couldn't figure out what my issue was here, but looks like it's just that I don't have permissions to access the repository: think you can add me so I can dig in here?
Updated by Boone Gorges almost 9 years ago
OK, you should have push access to cuny-academic-commons/bp-event-organiser now. (Though it's a public repo, so you should already have had read access.) https://github.com/cuny-academic-commons/bp-event-organiser
Updated by Daniel Jones almost 9 years ago
Awesome thank you I'm all set up now! Can work on this next week. I had been trying to use the SSH cloning method, but don't think I was doing it right. Switching to HTTPS made it work. Sorry about that.
Updated by Daniel Jones almost 9 years ago
I've implemented this here: https://github.com/cuny-academic-commons/bp-event-organiser/commit/63bbdfa223c464835ecc6c1f276376c1b2340cf4
I thought that the best way to do it given how the plugin is already written was to add the silent option as a meta box for the Event post type. Let me know if that doesn't work though! This way it's added to the back-end too, which could be useful. Right now I'm not checking to make sure we're in a group-context, or groups are already added, before showing the metabox. Let me know if I should add that in.
Updated by Matt Gold almost 9 years ago
Just noting that we have a muting option when adding a file to Group Files, so we may want to mirror that in look and feel. Have added Sam for that
Updated by Boone Gorges almost 9 years ago
- File Screenshot_2016-02-18_21-19-13.png Screenshot_2016-02-18_21-19-13.png added
- File Screenshot_2016-02-18_21-21-58.png Screenshot_2016-02-18_21-21-58.png added
Thanks, Dan! Functionality looks good.
A couple notes about UX:
1. The language should distinguish between event creation and event editing.
2. Let's use the same language we use for group files. There we say: "Silent upload (notifications will not be sent to subscribed group members)". In this case, we'd say something like "Silent create (notifications will not be sent to subscribed group members)"
3. The metabox is a good idea - especially the fact that it appears on the back end - but I think that (a) it buries the option too much, (b) it's a departure from our existing interfaces (see the two screenshots attached), and (c) "silentness" is not a property of the event, but a property of the specific create/edit action, while metaboxes seem like something that would persist between edits. Can we move it a raw checkbox in the front-end interface, and maybe leave it out of the Dashboard for the time being?
4. Yes, we will need to check for group associations before showing the checkbox. You may want to do this fully in JS, since you'd want the box to appear after someone adds group associations for the first time during event creation.
Updated by Matt Gold over 8 years ago
Hi All --
Just wanted to check in on progress on this ticket. it would be great if we could implement sooner rather than later and not wait for a major release to implement (though we can package in publicity for our next major release)
Best,
Matt
Updated by Daniel Jones over 8 years ago
Hey Matt -
I've been working on this some, but focusing on the export bug. I think I've got something working for creating events from within a group, but for some reason it isn't working when creating events from a user's profile. I need to keep working on it.
Updated by Daniel Jones over 8 years ago
Okay I believe I have this working here: https://github.com/cuny-academic-commons/bp-event-organiser/commit/b373542c372dc1265d28c8a948b1dd2e01507be9
I wasn't getting email notifications on event edits, so I prevented the silent-ness option from showing up on event edit pages. Let me know if I should change that.
Updated by Boone Gorges over 8 years ago
Thanks, Dan. I think that the silent notification tool is perhaps more important on the Edit Event page than it is when creating new events. Can you say more about the problems you were having with not getting email notifications on event edits? If you can point me to a changeset, I can try to take a look.
Updated by Daniel Jones over 8 years ago
Understood. If that's the case I can just set it to include on the edit pages as well.
The issue I'm having is that I don't get any email notifications when I edit events. This is the case both when I edit an event that's already associated with a group and when I take an event that previously wasn't associated with a group and associate it. I do get notifications about new events associated with groups though, unless I use the silent create option.
Let me know what you think!
Updated by Daniel Jones over 8 years ago
Looked deeper into this - I think my issues were being caused by the throttling on event updates, which means that updates within 6 hours of event creation don't create activities or notifications. We might want to add in an exception there for cases where people submit the event and then right away realize they've made an error. Could be as simple as adding another condition to the throttling if-statement to make sure that $last_activity->type isn't 'create_event'. I'd defer to you all on that though!
Once I turned off the throttling I was able to get the editing emails to make sure that my changes worked. Here they are - https://github.com/cuny-academic-commons/bp-event-organiser/commit/4c3d54ad7746068db47bc445b36173094d717b68
Updated by Boone Gorges over 8 years ago
- Status changed from Assigned to Resolved
- Target version changed from 1.10 to 1.9.12
Thanks for your work on this, Dan, and sorry for the delay in having a closer look.
Functionality appears to be pretty good to me. I've made some changes to the code so that it's a bit less fragile and a bit friendlier for distribution: https://github.com/cuny-academic-commons/bp-event-organiser/commit/d22f6144eafccaab82316c92a0b77a19bd3d7547
- Instead of building the markup for the checkbox in JS, do it in PHP. This does a couple things. First, it makes it easier to detect whether we're in Create or Edit mode - relying on elements of the DOM for this is pretty subject to breakage in future releases. Second, it makes it a bit easier to assemble the appropriate strings in a way that will be translator-friendly. Third, rendering a single time in PHP saves memory, since we won't be destroying/rebuilding on group select/unselect. Instead, we are just hiding/showing based on the contents of the Groups selector. Fourth, rendering in PHP gives us the possibility for no-js support in the future (although it's not yet complete).
- Your technique for checking on the contents of the Groups dropdown is heavily dependent on the internals of Select2. I switched to using their events instead - on( 'change' ).
Let's roll this into 1.9.12 to satisfy Ye Olde Higher Ups.