Difference between revisions of "WebIssues/Alerts and Notifications"

Revision as of 10:36, 5 October 2010

Introduction

Alerts will be introduced in version 1.0-alpha3 and will replace folder watches and notifications from version 0.8.4. Alerts will extend the idea of views, giving the possibility of tracking new and modified issues in selected folders and optionally sending email notifications when some changes occur.

The main improvements compared to version 0.8.4 are:

* the new/modified/read state of issues will stored on the server side
* alerts will be stored on the server side
* notifications will be unified with alerts, so they will be based on filter criteria, not subscriptions

Functional Specification

Each user will have separate alerts and will only be allowed to view and modify his own alerts.

Each alert will be associated with a single folder and optionally a public or private view. Alert can also be related to the built-in 'All Issues' view (i.e. the entire folder).

The name of the alert is the same as the name of the associated view. When a view is renamed or deleted, the associated alerts are also renamed or deleted. When a view is no longer available because it was unpublished, the alerts are also deleted.

The basic operations on alerts are:

* list all alerts for a given folder
* add a new alert
* modify an alert
* delete an alert

Each issue in the system will have a state for each user: new (the user never opened it), modified (it was modified after last opening) and read (it was not modified after last opening). The state is automatically tracked for all issues, whether the folder has any alerts or not. The state automatically changes when the issue is created or modified or when the user opens an issue. The user can manually change the state of a single issue or all issues in a folder (and alert?) to "new" or "read". New and modified issues will be marked with different icons (closed envelope with yellow or green dot).

For each alert, the number of new and modified issues and the total number of issues will be displayed. In the Web Client, this information will only be displayed in the Manage Alerts view. In the Desktop Client, alerts will be displayed as an additional level of the tree of projects tree (instead of a separate dashboard). Folders with at least one alert will be periodically updated and alerts will be recalculated on the fly.

Each alert will have an optional email notification settings. Notifications can be sent it two modes: immediate and summary. Immediate notifications will be sent as often as the cron job is running (between 5 minutes and 1 hour). Summary notifications will be sent at selected days of week and selected hours based on user preferences.

For each alert a separate email will be sent. The email will contain a list of issues from the given view which were created or modified since the previous notification. The email will not be sent if there are no changes. By default the notification will be sent even if the user had already read the issue; the user will have the possibility to exclude already read issues from notifications. In case of summary notifications the read state of the issues will always be ignored; in addition the user will be able to include all issues in every summary notification, even if they were not modified since previous notification.

A prototype of the user interface is available at http://doc.mimec.org/prototypes/alerts/index.html.

Technical Specification

Database table used for storing the state of issues:

issue_states ( state_id, user_id, issue_id, read_id )

The state_id will be an auto-incremented primary key. Rows of this table cannot be modified but must be deleted and inserted again to make it possible to incrementally track the changes of state. There will be one command for incrementally updating the state of all issues in all folders. The user_id and issue_id foreign keys will be included in a unique index. The read_id value is NULL for new issues, equal to stamp_id for read issues and less than stamp_id for modified issues.

Database table used for storing alerts:

alerts ( alert_id, user_id, folder_id, view_id, alert_notify )

The alert_id will be a primary key. The user_id, folder_id and view_id foreign keys will be included in a unique index (view_id can be NULL). The alert_notify field can be 0 (none), 1 (immediate) or 2 (summary). Alerts can be modified like any other data because they will not be updated incrementally. Alerts will be included in the LIST PROJECTS command.

User preferences related to notifications:

* notify_immediate_no_read (0 or 1)
* notify_summary_all (0 or 1)
* notify_summary_days (list of integers: 0-7)
* notify_summary_hours (list of integers: 0-23)