Tools & Users - Alerts Editor.

Getting started.

Here is where you can create enhancements to validation. This tool allows you to create a variety of alerts to increase the information on the forms you generate. In the directory \project35-1.0-win, click on run_alerts_editor . This will produce a pop up dialog like the one shown on the right. Select the model you want as the base for your alerts.

This list of models is taken from those listed in the models subdirectory in \project35-1.0-win. These will disappear when you click OK. What will appear is the Alerts Editor with a blank template based on the model you have selected.

The parts of the screen.

Here is where we can now go into some detail about the various parts of the Alerts Editor. The picture shown on the right shows an example of the screen you will see. You can either start editing the blank form that appears or load up an existing file.

Along the top is the menu list. Below and on the left is the navigation tree with the different types of alerts. Just below that is the button list for you to choose what kind of alert you want to create. On the right of the screen is the form you fill out for any type of alert.

This section will divided into groups based on the type of information being explained. These groups are: Menus, Buttons, Forms & Fields.

Menus.

There is only one menu list with the Alerts Editor.

Menu List	What you can select and what happens
	New - opens a blank file to start editing; Open - opens an existing file for editing; Save - save an alerts bundle under a specified name; Save As... - save an existing alerts bundle; Exit - exits the programme. You will prompted to save any unsaved changes.

Buttons.

On this application, you will see a variety of buttons. These will occur every time you run this application. Below is a table that can be used for reference if you haven't used a button before and don't know what it does.

Button	What happens when you click it
	This will show an entry for creating an Error Alert on the navigation tree on the left hand side of the dialog. There will be no change to the main part of the dialog on the right. This kind of alert could be used when combinations of data lead do not make sense.
	This will show an entry for creating a Warning Alert on the navigation tree on the left hand side of the dialog. There will be no change to the main part of the dialog on the right. This kind of alert could be used for when combinations of data may be correct but indicate a problem in the use case.
	This will show an entry for creating an Information Alert on the navigation tree on the left hand side of the dialog. There will be no change to the main part of the dialog on the right. This kind of alert migh tbe used for such things as upgrades to information.
	This will show an entry for creating a Contact Alert on the navigation tree on the left hand side of the dialog. There will be no change to the main part of the dialog on the right. This kind of alert might be used to contact other people who have expressed an interest in certain combinations of data.
	This will delete whatever entry has been selected.
	This will save the alerts bundles to a file that you name.
	This is used to attach a criterion to a certain list field. More information is provied below.
	This is used to attach a criterion to an edit field. More information is provied below.

Forms & Fields

In keeping with the other areas of the documentation, we've decided to keep the images to a minimum here. The main screen for the Alerts Editor remains the same regardless of the model or the type of alert; there is only one form and the fields remain the same. Below this is a list of the fields that can be found on the current form and what is meant to go in them.

Fields	What is meant to go in them

Name	The name of the alert.
Message	This is for the information you want in the alert.
Author	This is the creator of the alert.
Institution	This is where the author comes from.
E-Mail	This is the author's contact e-mail.

Edit Field vs List Field Criteria

An alert comprises a collection of edit field and list field matching criteria. Both kinds of criteria use field names that for a selected record type that is described in the XML schema. The main difference between these two types of criteria are in the kinds of operators they support. Below are images of what appears when you create a new matching field criterion.

In the top example of a edit field criterion, the box shows a list of edit fields for the record type "DuringDisaster". The combination box is followed by a list of operators that can be applied to single value. The blank field is a place to put a value that is compared with the value of the "during_disaster_q1" field that is part of a DuringDisaster record. An edit field criterion can be used to phrase conditions like: "For the edit field "location_type" of the record type "terrain_data", indicate a match if the field value is equal to 'Agricultural'.

In the bottom example of a list field criterion, the first combination box shows the list fields for the record type "Food Security". This is followed by a list of operators that relate to the number of items in a list. The blank field expects a number. The next combination box lists the type of child record that will be counted. For example, a list field criterion can be used to phrase a condition such as: "For the list field "supplies" of the record type "relief assessment", indicate a match if the number of "non_food item" records in the list is ">=" 3.