Difference between revisions of "WebIssues/Alerts and Notifications"
(→Introduction) |
|||
| (6 intermediate revisions by the same user not shown) | |||
| Line 4: | Line 4: | ||
The main improvements compared to version 0.8.4 are: | 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 == | == Functional Specification == | ||
| Line 17: | Line 17: | ||
The basic operations on alerts are: | 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). | 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). | ||
| Line 26: | Line 26: | ||
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. | 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 | + | Each alert will have an optional email setting. There will be three modes of emails: immediate notification, summary notification and summary report. Immediate notifications will be sent as often as the cron job is running (between 5 minutes and 1 hour). Summary notifications and reports will be sent at selected days of week and selected hours, based on user preferences. |
| − | For each alert a separate email will be sent. | + | For each alert a separate email will be sent. Notification emails 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 has already read the issue; the user will have the possibility to exclude already read issues from notifications. |
| + | |||
| + | Summary reports will simply include all issues, no matter if they were modified since previous notification or if they were read. | ||
A prototype of the user interface is available at http://doc.mimec.org/prototypes/alerts/index.html. | A prototype of the user interface is available at http://doc.mimec.org/prototypes/alerts/index.html. | ||
| Line 42: | Line 44: | ||
Database table used for storing alerts: | Database table used for storing alerts: | ||
| − | alerts ( alert_id, user_id, folder_id, view_id, | + | alerts ( alert_id, user_id, folder_id, view_id, alert_email ) |
| − | 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 | + | 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_email field can be 0 (none), 1 (immediate), 2 (summary notification) or 3 (summary report). 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 | + | User preferences related to emails: |
| + | * email | ||
| + | * notify_no_read (0 or 1) | ||
| + | * summary_days (list of integers: 0-6) | ||
| + | * summary_hours (list of integers: 0-23) | ||
| − | + | System settings related to emails: | |
| − | + | * email_engine (standard or smtp) | |
| − | + | * email_from | |
| − | + | * smtp_server | |
| + | * smtp_port (1 to 65535) | ||
| + | * smtp_encryption (ssl or tls) | ||
| + | * smtp_user | ||
| + | * smtp_password | ||
Latest revision as of 13:41, 28 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 setting. There will be three modes of emails: immediate notification, summary notification and summary report. Immediate notifications will be sent as often as the cron job is running (between 5 minutes and 1 hour). Summary notifications and reports will be sent at selected days of week and selected hours, based on user preferences.
For each alert a separate email will be sent. Notification emails 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 has already read the issue; the user will have the possibility to exclude already read issues from notifications.
Summary reports will simply include all issues, no matter if they were modified since previous notification or if they were read.
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_email )
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_email field can be 0 (none), 1 (immediate), 2 (summary notification) or 3 (summary report). 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 emails:
- notify_no_read (0 or 1)
- summary_days (list of integers: 0-6)
- summary_hours (list of integers: 0-23)
System settings related to emails:
- email_engine (standard or smtp)
- email_from
- smtp_server
- smtp_port (1 to 65535)
- smtp_encryption (ssl or tls)
- smtp_user
- smtp_password
