View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 166 | Composr | core | public | 2010-04-10 21:05 | 2012-02-21 03:50 |
| Reporter | Chris Graham | Assigned To | Chris Graham | ||
| Priority | normal | Severity | feature | ||
| Status | resolved | Resolution | fixed | ||
| Summary | 166: Global tracking system | ||||
| Description | Currently tracking is on the forum, side-wide via RSS or Commandr or admin-customised whatsnew-newsletters (or via calendar event notifications when the event's close to happening). I'd like to extend the forum-style e-mail tracking to be applicable to any kind of category. So for instance you'd get an alert if you tracked a download category above which a download was added. I'd also like a page that can show all your current trackings and deset them. It wouldn't allow tracking setting, as these would be done by buttons actually within the categories themselves (simpler to implement, and architecturally cleaner). The 'track whole forum' member option should be removed, as it doesn't fit in cleanly and isn't needed. Also, the new e-mail tracking system would allow people to do it via digest, of a digest-length of their choice (e.g. daily, weekly, monthly). Also another screen that is built into the search module, that integrates with this. The screen is just like the search screens, except instead of performing a search, it adds an 'advanced tracker' – basically a search-based filter that is run against everything new added, to determine whether to send a tracking notification to the member or not. These 'advanced trackers' could be removed from the main tracking management screen described in my first post. Trackings should be able to work via either SMS or e-mail or RSS – each of which are managed on a different copy of the same screen. For RSS each member is given their own unique RSS URL, which works on what they have chosen to track. Also the tracking management screen would allow selection of 'special' trackers (this replaces old 'staff emails'): * Whenever the adminzone is accessed * Whenever a particular user logs on * Whenever something is submitted for any particular content type (regardless of category) [Extension of CEDI mails currently sent] * Whenever something is changed on CEDI, and would go into the CEDI changes table * Whenever someone applies to be in a particular group [Duplicate of mail sent to leader] * Whenever there's a potential hackattack [SMS alternate of staff mail] * Whenever invited to an IM session [SMS alternate] * Whenever a backup finishes [SMS alternate of staff mail] * Whenever there's a calendar event notification [SMS alternate] * Whenever something needs validating / a forum post needs validating [SMS alternate of staff mail] * Whenever the server gets low on disk space [SMS alternate of staff mail] * Whenever a member changes to a new external avatar [Staff mail generalised] * Whenever a member changes a photo [Staff mail generalised] * Whenever a member changes a signature [Staff mail generalised] * Whenever a custom todo item is added to the Admin Zone front page [Staff mail generalised] * Whenever you're given points [SMS alternate] * Whenever you're invited to a chat [SMS alternate] * Whenever your username changes [SMS alternate] * Whenever you're banned/unbanned [SMS alternate] * Whenever you've received a newsletter [SMS preview] * Whenever you've got a new personal topic [SMS alternate] * Whenever you've been warned [SMS alternate] * Whenever you get a ticket reply [SMS alternate] * Hit reports for catalogues that have hit reports enabled [SMS alternate] * Whenever a certain product is sold [SMS alternate] * Whenever a survey has been filled in [SMS preview] For these 'SMS alternate' 'special trackers', e-mails are sent out as they currently are, unless the special tracker is added and it's told to not send e-mails – so it works as a kind of override. Some of these would of course be protected, and there would be a usergroup-defined quota for SMS message throughput. An per-member option would be given to specify whether track buttons would work against SMS or e-mail notifications by default. For SMS obviously a special 'Phone Number' CPF would need to be filled in. Another change needed for this – for Conversr, comment topics would need to be tracked automatically as if the comment topic was posted by the submitter of the resource the topic is for. Also, for Conversr, portal-side comment topic posts would trigger tracking notifications. When you click 'Track forum' provide an option to cascade it to all subforums. | ||||
| Additional Information | ocProducts has some code written for a client that can form part of this feature. The area of notifications is very fraught, as there are many competing-ways/conversation-management to do this: - SMS - RSS - Google Wave - E-mail (including tracking, direct e-mailing, newsletters, and mailing lists) - Todo lists - Calendars - Reporting (e.g. Reported posts), Issue management (e.g. tickets) - IM / messaging middleware (e.g. XMPP) - Popup alerts, or programs flashing when they've updated - (And of course in the past there have been other things we are replacing like post, telegram, telegraph, and phone calls) Our coverage is as follows: - SMS: Tracking - Facebook: Informal; We can syndicate updates out - Twitter: Informal; We can syndicate updates out - RSS: We have a lot of RSS feeds, more planned - Google Wave: This looks like it is not going to become popular - E-mail: Tracking - Todo lists: Admin Zone front page checklist; we plan to represent all 'tasks' there somehow - Calendars: RSS can be overlayed - Reporting: Tie-in to Admin Zone front page checklist - IM: We do not do this, as it's competing with too many other things, and also a bit of a fudge - Popup alerts, or programs flashing when they've updated: Only for our chat room | ||||
| Tags | Risk: Core rearchitecting , Risk: Database change , Risk: Major rearchitecting , Skills: Lead programming , Type: Cross-cutting feature | ||||
| Attach Tags | |||||
| Time estimation (hours) | 30 | ||||
| Sponsorship open | |||||
| related to | 167 | Resolved | Chris Graham | Improved admin zone checklists |
| related to | 164 | Resolved | Chris Graham | E-mail to Composr bridging system |
| related to | 22 | Resolved | Chris Graham | Resource comment tracking for submitters |
|
|
Let's kill the word 'tracking'. Instead we have 'notifications'. The 'track XXX'/'untrack XXX' buttons can become 'alerts OFF' and 'alerts ON' with tooltips that clearly explain that clicking the buttons change the state that is displayed on the buttons. I'm not entirely sure about that, I don't like mixing state explanations with action text, it gets confusing. But I think it is less confusing than the term 'tracking' which people no longer understand, and there is limited space on the buttonface (we can't say "Disable notifications" on there). |
|
|
Kill reported posts - just tie into staff messaging system Tie report content addon into staff messaging system Kill staff emails, instead staff can sign up to alerts in their notifications settings Any kind of log_it call can also be signed up to for alert Any kind of syndicate_described_activity call can also be signed up to for alert Kill SMS support - people have smart phones now Facebook/Twitter will be handled through the non-bundled activities addon [which provides the syndication service implementation], which tie into the non-bundled Facebook/Twitter addons RSS feeds stay as they are, although an activities RSS feed will be added Google Wave - Forget IM or Growl alerts - If people want to route stuff to IM, they can set up some kind of email handler outside the scope of Composr Calendar - Leave overlays as-is Todo lists - Leave as-is Implement consistent notifications support (formerly 'tracking'), for creation of e-mail alerts, through the system |
|
|
Continuing to refine this. This will be a really important API in the future Composr, replacing a lot of hard-coded email dispatching and giving users and staff much more control. It's not tracking now. It's not notifications now. It's alerts. We'll just talk about getting or stopping alerts. Dead simple and intuitive :). Users will have a member settings tab that allows them to define what alert status to have for each kind of alert they are allowed to receive. This includes email, PT, digest email, SMS (yeah, decided to put this back again), etc. |
|
|
Defined the API and exact TODO list to implement... /* Background details, to set the context and how we have structured things for consistency... Alerts are one-off messages sent out in response to something happening on the site. They may get delivered via e-mail, etc. Alerts may optionally create a message that staff might discuss, in which case a discussion link will be auto-appended to anyone having access to the admin_messaging module. This should be used sparingly - remember that any staff may raise such an alert by reporting some content, so it should only be particularly eventful stuff that spawns this. People may get an RSS feed of alerts if they track via PT, as PTs have an RSS feed - that may then be connected to Growl, IM, or whatever service they may enjoy using (kind of quirky, but some power users enjoy this for the cool factor). It's good that we support the standards, without too much complexity. There is a separate Composr action log, called via log_it. This is not related to the alerts system, although staff may choose an alert on anything added to the action log. Similarly, there is the Composr activities syndication system. This is not related either, but again alerts may be generated through this. The Admin Zone front page shows tasks. These are not the same thing as alerts, although alerts may have been sent when they were set up. Any alerts are CC'd to the configured CC email address (if there is one). This is like having that address get alerts for everything, even if they shouldn't normally be able to receive that alert (i.e. was targeted to a specific member(s)). But it's not really considered parts of the alerts system. */ /** * Standard code module initialisation function. */ function init__alerts() { // Alerts will be sent from one of the following if not a specific member ID define('A_FROM_SYSTEM_UNPRIVILEGED',-3); // Sent from system (website itself) *without* dangerous Comcode permission define('A_FROM_SYSTEM_PRIVILEGED',-2); // Sent from system (website itself) *with* dangerous Comcode permission // Alerts will be sent to one of the following if not to a specific list of member IDs define('A_TO_ANYONE_TRACKING',NULL); define('A_NA',0x1); // Not applicable define('A_INSTANT_EMAIL',0x2); define('A_DAILY_EMAIL_DIGEST',0x4); define('A_WEEKLY_EMAIL_DIGEST',0x8); define('A_MONTHLY_EMAIL_DIGEST',0x10); define('A_INSTANT_SMS',0x20); define('A_INSTANT_PT',0x40); // Private topic (TODO: implement using nice alerts topic emoticon) // And... define('A__ALL',0xFFFFFF); // And... define('A__STATISTICAL',-1); // This is magic, it will choose whatever the user probably wants, based on their existing settings } function dispatch_alert(ID_TEXT $alert_code,?SHORT_TEXT $alert_code_category,SHORT_TEXT $subject,LONG_TEXT $message,?array $to_member_id,integer $from_member_id,$priority=3,$store_in_staff_messaging_system=false,$attachments=NULL,$no_cc=false) { // TODO: Implement } // TODO: Write API doc headers /* TODO: Add all hooks with codes for - each kind of content (can subscribe to a category in each, or the whole lot) - ^ the old forum tracking is now just another kind of the above. Reimplement, kill old tables - convert over each kind of existing mail_wrap call (some will still be directed to a list of members, some to a specific member, or some to all -- but each will be sent on a alert code) - anything added to the action log - anything generated syndicated actions - when a new task is created on the Admin Zone front page checklist - Whenever the adminzone is accessed - Whenever a particular user logs on - When a support ticket is posted to a certain category (this used to be hard-coded into ticket types, remove that) - Extend the CEDI post tracking to also include page adding, and let anyone get alerts for it Hooks will be defined as... class Hook_trackable_X { function list_handled_codes() // Addons can define hooks that handle whole sets of codes, so hooks are written so they can take wide authority { return array( array('SOME_ALERT_CODE','Some category','Some label'), ); } function supports_categories($alert_code) // Content types, for example, will define alerts on specific categories, not just in general. The categories are interpreted by the hook and may be complex. E.g. it might be like a regexp match, or like FORUM:3 or TOPIC:100 { return true; } function allowed_settings($alert_code) { return A_ALL; // Returns a bit-mask } function get_initial_setting($alert_code,?SHORT_TEXT $category=NULL) { return A_NA; } function get_default_optin_setting($alert_code,?SHORT_TEXT $category=NULL) { return A__STATISTICAL; } function list_members_who_could_receive($alert_code,?SHORT_TEXT $category=NULL) { return array(); } function list_members_who_would_receive($alert_code,?SHORT_TEXT $category=NULL) { return array(); } function member_could_potentially_receive($alert_code,$member_id,?SHORT_TEXT $category=NULL) // If they are allowed to receive these alerts { } function member_would_receive($alert_code,$member_id,?SHORT_TEXT $category=NULL) // If they are actually set to receive these alerts { } } */ // TODO: Convert tracking addon to official alerts feature, and overhaul UI - will be a member setting alerts tab // TODO: Remove Commandr notifications feature (it's now really redundant) // TODO: Make sure references to e-mail are changed to alert where possible // TODO: Must be careful to ensure new private topics do not create alerts that create new private topics (and so on) // TODO: Any alert will be sent as email to the staff CC address, even if it did not actually get truly sent via email // TODO: Put "get alerts"/"stop alerts" buttons all over Composr (used to be called track buttons) // TODO: UI must not show options unavailable to them. E.g. if they do not have SMS setup (or site does not), it should not show as an option. Ditto if email address not set up. // TODO: If SMS quota reached, goes to email instead, with a note explaining this // TODO: Kill reported posts feature - just link through to standard reporting system (posts a staff message, and alerts to any staff wanting 'reported content' alerts), based on the current non-bundled addon |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-06-08 00:14 | Chris Graham | Tag Renamed | Major rearchitecting => Risk: Major rearchitecting |
| 2016-06-08 00:15 | Chris Graham | Tag Renamed | Database change => Risk: Database change |
| 2016-06-08 00:15 | Chris Graham | Tag Renamed | Core rearchitecting => Risk: Core rearchitecting |
