Difference between revisions of "SoC core notification support"
(→Objective) |
|||
| (6 intermediate revisions by 3 users not shown) | |||
| Line 3: | Line 3: | ||
== Overview == | == Overview == | ||
| − | There are a number of core GL features and plugins that send out email notifications and each plugin or module has to develop their own code. There is no central area for the site admin or members to moderate what they can receive notifications | + | There are a number of core GL features and plugins that send out email notifications and each plugin or module has to develop their own code. There is no central area for the site admin or members to moderate for what they can receive notifications or how they want them handled. |
| − | There is also the need to | + | There is also the need to expand the ability of sites to provide alerts for events in which administrators may have an interest. |
| − | Many plugins would require a | + | Many plugins would require a basic level of notification service. Others, such as the forum plugin, will require a more complex notification service. For instance, a notification service for the forum would need to allow a user to subscribe to a topic or a complete forum. If they have subscribed to a complete forum, they can selectively un-subscribe to some topics. The same level of control may be needed for stories (articles), where a user can subscribe to a complete site but then un-subscribe to certain topics or stories by a certain user. |
== Objective == | == Objective == | ||
| − | * Develop a set of core | + | * Develop a set of core Geeklog API's to support the registration of new notification services and user notification of subscriptions. Ideally, an [https://en.wikipedia.org/wiki/Observer_pattern observer pattern] would be used for clarity and efficiency. |
| − | * Extend the plugin API | + | * Extend the plugin API to use the new services. |
| − | * Extend the core GL modules to use the new services | + | * Extend the core GL modules (polls, articles, links, etc) to use the new services. |
| − | * Develop the notification admin / site admin | + | * Develop the notification admin / site admin GUI. |
| − | * Develop the | + | * Develop the GUI for the users to manage their notification/subscription rules. |
| + | * Develop the GUI for users to receive messages on the site and to delete them once read. | ||
Support for: | Support for: | ||
| Line 29: | Line 30: | ||
* Admin wants to receive daily digest of all other notifications | * Admin wants to receive daily digest of all other notifications | ||
* User wants daily digest of all notifications | * User wants daily digest of all notifications | ||
| − | * Support for RSS Feed per user - using a random hash like URL | + | * Support for RSS Feed per user - possibly using a random hash like URL |
* Daily digest format needs to use a template so the site admin can modify it | * Daily digest format needs to use a template so the site admin can modify it | ||
| + | * Receive Notifications via email and/or prominent system message on site | ||
| + | == Use Cases == | ||
| − | |||
* Site Admin wants to be notified of all new forum topics and MG albums created but not new replies and images uploaded | * Site Admin wants to be notified of all new forum topics and MG albums created but not new replies and images uploaded | ||
* User wants daily digest of all MG updates for albums they have access to | * User wants daily digest of all MG updates for albums they have access to | ||
| Line 43: | Line 45: | ||
The site Admin and user can have multiple notification rules setup and setup the email subject, email address so they can filter or redirect notifications. | The site Admin and user can have multiple notification rules setup and setup the email subject, email address so they can filter or redirect notifications. | ||
| + | |||
== Level of Difficulty == | == Level of Difficulty == | ||
| − | ''medium'' | + | ''medium to high'' |
| + | |||
| + | This project will require someone to spend time understanding how the core GL plugin API works. Need to install a number of the more popular plugins that use notification-like features and develop a model of the new notification service API. | ||
| + | |||
| + | Students should have OO experience and knowledge of say the Observer Design Pattern as that would be a good base for the design of this project. | ||
| + | |||
| + | '''Mentor:''' Vinny Furia | ||
| + | |||
| + | == Further Reading == | ||
| − | + | * We had a student interested in this project in 2008. Please see the discussion "GSoC 2008: Core Notification Service" in our [http://eight.pairlist.net/pipermail/geeklog-devel/2008-March/thread.html mailing list archives]. | |
[[Category:Summer of Code]] [[Category:Development]] | [[Category:Summer of Code]] [[Category:Development]] | ||
Latest revision as of 15:47, 10 April 2013
Overview
There are a number of core GL features and plugins that send out email notifications and each plugin or module has to develop their own code. There is no central area for the site admin or members to moderate for what they can receive notifications or how they want them handled.
There is also the need to expand the ability of sites to provide alerts for events in which administrators may have an interest.
Many plugins would require a basic level of notification service. Others, such as the forum plugin, will require a more complex notification service. For instance, a notification service for the forum would need to allow a user to subscribe to a topic or a complete forum. If they have subscribed to a complete forum, they can selectively un-subscribe to some topics. The same level of control may be needed for stories (articles), where a user can subscribe to a complete site but then un-subscribe to certain topics or stories by a certain user.
Objective
- Develop a set of core Geeklog API's to support the registration of new notification services and user notification of subscriptions. Ideally, an observer pattern would be used for clarity and efficiency.
- Extend the plugin API to use the new services.
- Extend the core GL modules (polls, articles, links, etc) to use the new services.
- Develop the notification admin / site admin GUI.
- Develop the GUI for the users to manage their notification/subscription rules.
- Develop the GUI for users to receive messages on the site and to delete them once read.
Support for:
- Alert Classification (admin, general, moderation, error ...)
- Alert Type (core, plugin ...)
- Alert Subtype (module specific)
Only Root or plugin Admin's have access to the admin and error type notifications but this should be a configurable mapping option and controllable via the online notification service admin.
Users should be able to determine how they want to receive their notifications.
- Admin wants to be emailed on all admin and error notifications
- Admin wants to receive daily digest of all other notifications
- User wants daily digest of all notifications
- Support for RSS Feed per user - possibly using a random hash like URL
- Daily digest format needs to use a template so the site admin can modify it
- Receive Notifications via email and/or prominent system message on site
Use Cases
- Site Admin wants to be notified of all new forum topics and MG albums created but not new replies and images uploaded
- User wants daily digest of all MG updates for albums they have access to
- User wants daily digest of all comments to content they have created or have replied to.
- Admin wants daily digest of all items awaiting moderation
- Admin wants to be notified via email of all site logins
- Admin wants to be notified via email of all bad login attempts so they know if a user is now locked out
- Admin wants to be notified of new user signups.
The site Admin and user can have multiple notification rules setup and setup the email subject, email address so they can filter or redirect notifications.
Level of Difficulty
medium to high
This project will require someone to spend time understanding how the core GL plugin API works. Need to install a number of the more popular plugins that use notification-like features and develop a model of the new notification service API.
Students should have OO experience and knowledge of say the Observer Design Pattern as that would be a good base for the design of this project.
Mentor: Vinny Furia
Further Reading
- We had a student interested in this project in 2008. Please see the discussion "GSoC 2008: Core Notification Service" in our mailing list archives.
