| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 1901 | Composr | calendar | public | 2015-05-11 16:10 | 2020-03-28 18:09 |
| Reporter | Chris Graham | Assigned To | |||
| Priority | normal | Severity | feature | ||
| Status | new | Resolution | open | ||
| Summary | 1901: Unify calendar notification system | ||||
| Description | The calendar notification system is needlessly complex. The interests part of it can be streamlined, by better drawing on common functionality in the notification system. Remove the 'calendar_interests' table. Instead we'd just use notification categories for the calendar_reminder notification type, similar to how you set a monitor on particular forums. The current interest setting UI can be mapped to it - i.e. when you save, it is really saving to your notification settings. The code for setting the categories within the calendar_reminder notification type can be copied from the calendar_event notification type. Rename 'Reminders for calendar events subscribed to' (calendar_reminder) notification type to 'Get event reminders'. That's simpler. Note the UI on the add/edit form is pretty confusing. Screenshot attached. It needs to clearly say 3 options (which can be combined): 1) Sign yourself up (default: ticked) 2) Sign usergroup members up (default: empty list selection) 3) All people with notifications will automatically be signed up (default: ticked) The "Reminder notice" option would remain on the form. This functionality wouldn't change - we'd still be using the calendar_reminders and calendar_jobs tables to set up individual reminders. The calendar_reminder notification type settings would drive the "All people with notifications will automatically be signed up" behaviour, leading to the individual calendar_reminders/calendar_jobs rows being created when adding the event. If calendar_reminder was enabled wholesale for a user, that user would get notifications for all events where "All people with notifications will automatically be signed up" was ticked - otherwise it would be based on the individual calendar_reminder categories that were seelcted under it. The "Sign usergroup members up" setting would now work irrespective of the calendar_reminder notification type settings - as calendar_reminder is now for setting interests, not working as an additional layer of configuration. The way the reminders would be received would no longer be individually configurable as a consequence of removing the extra layer - but we could hard-code it to use the value of the calendar_interests setting if that is set, (category-override if there is one) or fall back to the A_STATISTICAL notification setting, i.e. send e-mails if the user has most of their other notification types set to that, or private topics if they are preferring private topics (but locked from doing digests). The ability to manually set up a reminder would not change either. The changes in this issue refer to *interests*, not individual reminders. We can't integrate that into a notification type because of the need to configure the reminder notice (hours) value individually per-event reminder. All this new behaviour would need clearly documented. i.e. how exactly the notification settings work, what exactly determines what kind of notification you receive, what exact control the event submitter has, and how you can manually change a member's reminders from the event view screen. It would also explain why we store reminders outside the main notifications system (reason: because you can have multiple and set individual notice times on them, and we didn't want to be over-complex by having separate reminder and reminder receipt settings like we used to). | ||||
| Additional Information | We can still use the full notification system for sending reminders while ignoring the actual member notification settings which are really now just defining their broad interests (auto-reminders), with a small code change... diff --git a/sources/hooks/systems/notifications/calendar_reminder.php b/sources/hooks/systems/notifications/calendar_reminder.php index 13a097b..9cbd767 100644 --- a/sources/hooks/systems/notifications/calendar_reminder.php +++ b/sources/hooks/systems/notifications/calendar_reminder.php @@ -40,6 +40,16 @@ class Hook_Notification_calendar_reminder extends Hook_Notification */ function list_members_who_have_enabled($notification_code,$category=NULL,$to_member_ids=NULL,$start=0,$max=300) { + if ($to_member_ids!==null) + { + $members=array(); + foreach ($to_member_ids as $member_id) + { + $members[$member_id]=A_INSTANT_EMAIL; + } + return array($members,false); + } + $members=$this->_all_members_who_have_enabled($notification_code,$category,$to_member_ids,$start,$max); $members=$this->_all_members_who_have_enabled_with_page_access($members,'calendar',$notification_code,$category,$to_member_ids,$start,$max); $members=$this->_all_members_who_have_enabled_with_category_access($members,'calendar',$notification_code,$category,$to_member_ids,$start,$max) Ours would probably use A__STATISTICAL instead of A_INSTANT_EMAIL, and we'd define a allowed_settings function in the hook. | ||||
| Tags | Roadmap: Over the horizon, Type: Usability (major) | ||||
| Time estimation (hours) | 5 | ||||
| Sponsorship open | |||||
- Anonymous
