Projects:Intrusive Alerts/Specifications

Contents 1 Intrusive Alerts - Functional Specifications 1.1 Overview 1.1.1 Purpose 1.1.2 Scope 1.1.3 Dependencies 1.2 Glossary 1.3 Functional Requirements 1.3.1 Use cases 1.3.1.1 Create an alert 1.3.1.1.1 Role 1.3.1.1.2 Configuration 1.3.1.2 Receive an alert 1.4 Business process definition 1.4.1 User interface 1.4.1.1 Alert definition 1.4.1.1.1 Manually 1.4.1.1.2 Via webservice 1.4.1.2 Alert display 1.5 Functional requirements based on business processes

Intrusive Alerts - Functional Specifications

Overview

Purpose

Intrusive Alerts is an extension to the current Alerts. But while current alerts do not require user interaction when they are raised, intrusive ones do. This means, that when current alerts are triggered the user simply watches an active alerts counter increasing, afterwards, when the user desires to, he/she can manage the alert. When an intrusive alert is raised, user will have compulsory to manage it.

The goal of these alerts is to inform about urgent issues which cannot be postponed.

For example:

• Openbravo ERP server is going to be rebooted, system administrator should generate an alert to be broadcasted to all the users working currently in the application in order they can save their work before the system is down.

As it is a general alerts extensions it should be implemented using the current alerts implementation (as far it is possible).

Scope

The scope of Intrusive Alerts is global. They are shown wherever the user is in the application.

Dependencies

To be possible to use correctly time triggers for alerts the implementation of background project must be completed.

Glossary

• Intrusive: talking about alerts intrusive means that requires user interaction.

Functional Requirements

Use cases

There are two use cases:

Create an alert

Role

Not everyone can create intrusive alerts, this is restricted to Admin roles.

Configuration

An alert is defined as:

• Message The message the alert will display. This message should be multilingual: the text will appear to the user in the language he or she is using the application.
• Triggering event It is the event that raises the alert. In the current alert implementation it is always a SQL clause, when it returns any record the alert is triggered. This capability could be useful for intrusive alerts too. But in addition a time definition is required for this kind of alerts. This time definition is the time the alert is active. For example if the system is going to be restarted today at 12:00 the alert could be defined to be active today from 11:30 to 12:00, but it has nonsense at 13:00 because the system is already working. Once this new event is implemented it could be used for general alerts too. This time scheduling will be defined within the background project scope.
• Recipients General alerts are defined to have some recipients (which can be defined as individual users or as roles), currently the way to add everyone as recipient is by assigning every role in the application, this is sufficient for general alerts because they usually needn't to be broadcasted to everybody, but the general use for intrusive alerts is to send them to all the users, so there should be a way to do it easier than adding all the roles.

Receive an alert

Once the alert is raised its recipients will be informed about it in a way they have to attend it before they can continue with their current work in the application.

The decisions a user can take when is informed are:

• Confirm the alert, the user knows about it and it will not be displayed again.
• Remind. The alert will be displayed again in a period of time defined by user.

Business process definition

User interface

According to the use cases there are two needed interfaces:

Alert definition

There will be two ways of creating alerts:

Manually

This is the way currently alerts are defined and intrusive alert definition should use the current alert rule interface. Adding to it the new required fields:

• Message Currently the displayed message for alerts is included in the SQL clause. This is a flexible way to do this because allows to have different messages depending on the SQL conditions but it is more difficult (though it is possible) to make multilingual messages. See to be defined section.
• Triggering event Currently it is always a SQL clause. The new implementation will allow to trigger an alert by an SQL clause or according to scheduling.
• Recipients A new all check should be added.
• Alert instance per user Up to date there is a single alert instance for every user. This means that if a user manages an alert instance (for example it is set as fixed) every user that is recipient of this alert will notice this change (following the example the alert instance will not be taken into account in the counter). This can be a problem for intrusive alerts because the instance should be one per recipient in order to allow to be managed in a different way by different users (for example one could decide to confirm it -set as fixed or as inactive- while other one could set as remind). So a new column is needed to set the alert rule to create an instance per user. When this is checked the alert process will create a different alert for each user, additionally the instance table will need a user column to manage this kind of recipients.
• Message Currently the message to be displayed by the alert is defined within the SQL clause, in case the alert has no SQL clause a new field to insert the message must be added. Additionally the message must have the ability of using existing messages in database, not only an fixed string. This will allow to translate the message to different languages.

Via webservice

A webservice needs to be defined in order to automatize the alerts creation.

Alert display

A new interface must be created for showing intrusive alerts.

It should be a kind of popup (or a floating html div). The information it will display is:

• Message non-editable box.
• Confirm button.
• Remind in ... minutes editable numeric text box.
• Remind button.

When the alert is raised the message box is displayed with the alert's text. The remind button is preselected and the default value for remind in n minutes is for example 5. If remind button is clicked the popup disappears and will appear in n minutes. If Confirm button is clicked the alert disappears and will not be raised again.

Functional requirements based on business processes

Num	Requirement	Importance	Status	Estimated time	Comments
1.1	Prepare infrastructure for the intrusive alerts (new columns and fields in application dictionary)	Must have	To be started	1d
1.2	Manage this new type of alerts by the current background process	Must have	To be started	5d
1.3	Create intrusive alert interface	Must have	To be started	10d
1.4	Use time scheduling to define alerts triggering	Should have	To be started	4d	This requirement depends on background project