Messages Task List
The application shows you warning messages that are triggered during processing to give you choices about the outcome of a transaction. There are three levels of severity assigned to task list items:
-
Error (E) messages occur when the user cannot complete the transaction without changing the conditions. You cannot bypass Errors; the application expects you to change the conditions of the transaction until the error is corrected (usually missing information, invalid entries, etc.).
-
Warning (W) messages occur when you can decide how to handle a transaction that has an issue. You can bypass a Warning to continue processing a transaction; bypassing a warning allows you to confirm that you accept the non-standard conditions of the transaction.
-
Hidden (H) messages only display for Application Managers so they can decide how to handle an issue. Hidden messages don't generate a task list window and are only visible to an Application Manager.
Authorized users can customize these settings in most cases.
For each action that triggers a task list message, an Application Manager can either upgrade a warning to an Error or downgrade a Warning to Hidden. All messages initially default to a status of either Error or Warning. Messages that default to Error can never be reduced to a warning or hidden state! Messages that default to Warning but have been modified to an Error can be reset back to a Warning.
Changing Message Severity
Currently, rather than use the Message Maintenance form (Maintenance > Database > Messages) to change message severity, we encourage Application Managers to modify the message severity when the message displays using the process below:
1. In the Task List form, right-click the message icon of the warning severity you want to change.
This displays the New Severity options list for the message you selected.
2. In the New Severity box, choose the new severity option for this error. Choices include: Error, Warning, Hidden, and either a "Reset to Warning" or "Reset to Error" option (depending upon the original severity setting). These messages are defined as follows:
-
Error
Select this option to prevent the user from completing the action associated with the message. -
Warning
Select this option to show the warning message to the user when this circumstance occurs. This allows the user to accept the message and choose to continue or make a change. -
Hidden
Select this option to display the current message for admin users only. -
Reset to Warning/Error
Resets the message type to either the Warning or Error status, depending upon the current setting.
3. Continue based on the types of transactions you want to apply this severity change to:
-
To apply this change in severity to only this transaction, leave the Apply to ALL transactions box unchecked.
-
To apply this change in severity to all future transactions associated with this message, select (check) the Apply to ALL transactions check box.
4. Choose Save to update this message severity change.
To see the user who has the Application Manager permissions, review the settings in Maintenance > Database > Parameters > Setup, and the User ID tab... see User ID Parameters for more information). Even Application Managers cannot modify messages that were coded as Error (E) types originally. The primary reason we don't allow severity changes on all messages is that certain messages are used to prevent processing errors (required fields, etc.).
Message Maintenance Form
The Menu Maintenance form is more useful for inquiry than for resetting groups of task list items back to system defaults.
Messages are grouped together and organized by application or database area. Application areas provide a breakdown of task list items by activity. After selection in the upper grid, all messages that potentially might appear when processing (F12) in the application, database, or activity are listed in the lower grid. The situations that trigger messages vary considerably and are set within the code. Some messages may only be triggered in very specific situations. For this reason, you may see what appear to be duplicate messages. The way the messages are used in different situations sometimes requires that we add the same message more than once (so that we can have one that triggers just a "Warning" but another that always triggers an "Error" in another specific case, for example).