MONRS_Funct_Spec.pdf

Metrology OOT Notification and Reporting System Functional Specification

1. Overview The Metrology Out-of-Tolerance (OOT) Notification and Reporting System (MONRS) is a web-based system that notifies MTE owners of OOT conditions as they arise and provides a graphical interface for these owners to disposition those conditions. In addition MONRS retains a record of the disposition for reporting and auditing purposes.

2. Scenarios

2.1. Scenario 1: Dave

Dave works at one of the test areas on-site as a test engineer. He designs multiple test systems each year and as a result sends a lot of equipment to the calibration lab. Some of this equipment becomes part of a test system for prototype hardware; other is used in flight-certification.

Occasionally Dave is notified by the calibration lab that a piece of equipment he sent in for calibration was found to be out of tolerance. In the past he was always notified with a paper form with instructions on how to close out the event, and an attached printout containing the details of the calibration so that he could perform an impact assessment. Because of the varying nature of the work Dave does he has found that sometimes the out of tolerance event has impacted testing and sometimes it has not. Being a busy person with a priority on his engineering work, Dave has always addressed the immediate impacts of the OOT-event first and worried about the paperwork later, if there was time. On rare occasion the paperwork has even become lost. Rather than bother the calibration lab for another copy Dave has just assumed that if they really needed it they would let him know.

Now that Dave has access to MONRS however, his previous issues with time constraints and tracking paperwork have diminished. When a piece of equipment that Dave is responsible for is found to be out of tolerance by the calibration lab, he receives an email. The email contains some preliminary information on the OOT-event as well as a link to MONRS where he can pull up the full detail of the recent calibration. In the same location in MONRS Dave can enter any information related to his assessment of the impact of the OOT-event and any final actions that were performed as part of the official disposition. At any time Dave can go to MONRS and see which OOT-events are still open that he is responsible for closing. If he wants to enter some initial information addressing the event but needs more time to fully close it, he can enter into MONRS what he knows now and come back later to finish updating and then close out the event. If Dave ever wants to see which pieces of his equipment have been out of tolerance he can simply look up it in MONRS.

2.2. Scenario 2: Jessica

Jessica is the manager at the on-site calibration lab and as such is responsible for maintaining good records on all of the equipment that passes through her lab. Although Jessica has always done her best to keep the lab records as complete as possible, she is unfortunately somewhat limited by the current process for handling out of tolerance MTE, which is a paper-driven, manual and error-prone process. Although Jessica has a notification sent each time an OOT-event occurs, her lab doesn’t always receive a timely response back from the MTE owner. Sometimes the lab gets no response at all, or the paperwork gets lost in the “shuffle”. This puts Jessica in a very difficult situation when audit time comes and is only made worse by the fact that her lab has established a goal of becoming ISO certified. On top of all that Jessica’s lab is facing budget and personnel cuts, further reducing the resources she has available to manually generate OOT notifications and track and record OOT-event dispositions and close-outs. Jessica needs a better way to send OOT notifications and record responses.

With the help of MONRS Jessica can gain efficiency while increasing accountability. Because MONRS sends email notifications about OOT-events once they are entered into the Metrology Information Management System (MIMS) database she doesn’t have to allocate any of her personnel resources to fill out and send the paper forms. To help her provide her “out and up” close-out metrics she can run simple reports in MONRS on all past OOT-events. And when audit time rolls around she can quickly pull up detailed information to provide the auditor on the calibration, impact, disposition and close-out of any given OOT-event.

3. Non-goals This version will not support the following features:

• Assignment of the point-of-contact for an MSCL account

• A workflow that automates approval of an OOT-event assessment and disposition

• Close-out reminder notifications

• Reporting capability beyond that offered by SharePoint 2010 out-of-the-box

4. Terminology

4.1. Item / Record / Event

The terms “item”, “record”, and “event” are used interchangeably throughout this document. In SharePoint parlance, an item is the generic term for an element of a list. MONRS-DI exports OOT event data to MONRS-DS (SharePoint), which adds the event data for each event as an individual list item in the Events list. So each item in the Events list can also be considered an “event”.

Furthermore each item in the list becomes a record of the OOT event that is represents, hence the use of the term “record”.

5. Architecture There are two primary modules in MONRS. One of the modules (what is sometimes referred to as the data interface module or MONRS-DI) interfaces with the MSCL’s MIMS to copy new OOT-events into MONRS. The other module (the data store module or MONRS-DS) provides event notification and a user interface for MTE owners and calibration lab management. MONRS-DS stores OOT-event calibration data (including a domain-resolved “owner” of the event record), a calibration certification in PDF format (automatically generated and provided by the calibration lab), and OOT assessment and disposition information entered by the MTE owner. A further description of each module is contained in the following sections.

TECHNICAL NOTE: MONRS-DS user authentication is performed by the Engineering Directorate’s SharePoint system (which itself uses JSC domain authentication). All users are therefore REQUIRED to have a NASA domain account to access MONRS.

TECHNICAL NOTE: MONRS-DS user authorization is handled by the Engineering Directorate’s SharePoint access control system. Record-change authority is limited to the record owner and the application administrators. However any authenticated domain user can access the system and view existing OOT records.

6. Data Interface Module (MONRS-DI) The data interface module is a stand-alone console application that is configured to run as an automated daily task on the server that hosts MIMS. End-users have no direct interaction with this module.

IMPORTANT: The point-of-contact listed in MIMS for the account that owns a given piece of metrology and test equipment is the individual that becomes the “owner” of an OOT record in MONRS-DS. Therefore the correctness of that piece of data in MIMS is critical to the correct operation of MONRS.

6.1. Flowchart

6.2. Configuration File

MONRS-DI stores and reads (at run-time) several configuration parameters from within its configuration file (named Monrs.Di.exe.config). Every effort was made to limit the amount of configuration data that was hard-coded into the application itself.

6.3. MIMS

MIMS contains a Sybase SQLAnywhere database as its back-end. MONRS-DI can access the MIMS database through either an MSCL-provided ODBC connection or a Sybase-provided ADO.NET provider (the connection mechanism is configurable through MONRS-DI’s configuration file). The Sybase provider is the preferred (and currently configured) connection mechanism; the ODBC option is provided for backwards-compatibility only.

TECHNICAL NOTE: OOT events are uniquely identified in MONRS by the field ‘AssetCTAG’.

6.4. Command Line Arguments

MONRS-DI has several command-line arguments.

The ‘no-notifications’ (or ‘nn’) option causes the application to set the SendNotifications field of the MONRS-DS record to false, which then prevents MONRS-DS from sending notification emails on record creation / reassignment (more on this in the MONRS-DS section). This is primarily a debugging and testing option.

The ‘no-deletions’ (or ‘nd’) option prevents the application from deleting calibration reports one they are uploaded to MONRS-DS. This is primarily a debugging and testing option.

The ‘forget-run’ (or ‘fr’) option prevents the application from recording the date of the current run.

This is primarily a debugging and testing option.

The ‘debug’ option is simply a shortcut for all of the above options, as they are most commonly all used in conjunction with each for performing debugging and testing of the system.

The ‘id’ option can be used multiple times, each with a corresponding MIMS Asset Ctag value, to put the application into the ‘SPECIFIC EVENTS’ mode.

6.5. Logging

MONRS-DI logs a series of nominal operation and error information to two locations, a text file on the host server and the Log List on MONRS-DS. If for some reason MONRS-DS’s Log List cannot be reached (it is remote so there is a possibility of a network error, a configuration error, etc.) when MONRS-DI starts up the application logs that error to the local (text file) log and suppresses further attempts to write to the remote log for the remainder of the current run.

6.6. Modes

6.6.1. Specific Events

This is the mode in which MONRS-DI operates if one or more ‘id=XXX’ options are used on the command line. In this mode the application queries MIMS only for the specified events.

6.6.2. New Events

This is the default mode of the application. If no ‘id’ options are used on the command line the system runs in this mode. In this mode the application first checks for the time of the previous run (a timestamp written to a text file). Once it has this value it queries MIMS for all OOT records that have occurred since the last run date minus a configurable (via the configuration file) number of days.

6.7. Translating MIMS OOT Event Objects Into MONRS OOT Event Objects MONRS-DI performs an internal translation of the MIMS event objects into MONRS event objects;

all of the MIMS event object fields are translated one-for-one into MONRS event object fields with the exception of one; the MIMS customer email field is resolved by MONRS-DI into a NASA domain ID (via a lookup in the NASA Enterprise Directory (NED)). This ID is then set as the value of the DataServicesData field of the MONRS event.

IMPORTANT: MIMS is the initial source of asset owner contact information; MONRS-DI attempts to perform a translation of the owner’s email address into a domain account. If the email address is missing or cannot be translated into a valid domain account then MONRS-DI assigns a (configurable) default owner (typically some point of contact within the calibration lab). The default owner can then manually identify the correct owner and reassign the event record within MONRS-DS.

TECHNICAL: MONRS-DI cannot set the Owner field of the MONRS event because a SharePoint field of type ‘Person’ cannot be used over SharePoint’s ODATA data services.

6.8. Exporting to MONRS-DS

Once MONRS-DI has a set of MONRS OOT event objects it attempts to export (upload) these objects to MONRS-DS. For each event it first checks with MONRS-DS for the existence of that event (via Asset Ctag value). If the event already exists the application skips to the next event.

Otherwise it uploads the event meta-data (asset number, calibration date, etc.) and then uploads the corresponding calibration report (a PDF file copied into a common file repository by the MSCL) and then deletes the local copy of that report (assuming the ‘no-delete’ option has not been set).

If the meta-data upload fails the system logs the error and sends an email to the application administrator. It will not attempt to load the calibration report.

If the upload of the calibration report fails the system logs the error and sends an email to the MSCL Help Desk POC.

Once all non-existent events have been exported to MONRS-DS the application records the current date and time locally (assuming the ‘forget-run’ option has not been set) and then shuts down.

6.9. Automated Scheduling

Windows Task Scheduler is used to run the MONRS-DI application once a day at midnight Central Time.

TECHNICAL: Task Scheduler is configured to run the application as the ‘svjs-monrs’ domain service account, which has record-creation permission on the Events list of

MONRS-DS.

7. Data Storage Module (MONRS-DS) The data storage module is the user interface for MONRS. It is a SharePoint site with a SharePoint list that has been configured to store the OOT events exported from MONRS-DI. All MONRS-DS code runs within a SharePoint Sandboxed Solution.

7.1. Flowchart

The flowchart is a high-lever overview of the typical user process and is presented from the perspective of an MTE owner except where marked by the SYSTEM identifier.

7.2. The Events List

This list contains the event items exported out of MONRS-DI. It is the single location on the MONRS SharePoint site that end-users interface with. It stores all data exported from MONRS-DI as well as any data entered by end-users.

7.2.1. Fields

A complete listing of this list’s fields can be found in the corresponding Schema.xml file in the source code. Only those fields of special interest are detailed here.

7.2.1.1. Asset

The Asset field is really the Title field with a different display name; as the Title field is a required field in all SharePoint lists it was renamed to fit with the schema of the OOT event.

7.2.1.2. Closed

This is a Boolean field that corresponds to the status of the record; if the record (Event item) is closed then the field value is true. Once a record is closed its assessment and disposition data is considered “locked” (i.e., no longer editable).

7.2.1.3. FormData

This field is used internally by the system to pass any non-specific serialized data between the list forms and the list itself. Server-side list event handlers clear this field after each update to the list item data. The ShowInViewForms attribute for this field is set to false and thus is not viewable in any list views.

7.2.1.4. ImpactToTesting

Although this field represents a Boolean (true / false), it was implemented as a SharePoint “Choice” field that specifies three specific states: Yes, No, and Null (e.g. blank or no value). It was implemented this way so that validation algorithms (both server- and client-side) can verify a value has been selected (Yes or No); a Null value fails validation.

7.2.1.5. Owner

The Owner field is a SharePoint “User” field and holds the SharePoint-resolved site ID of the record (item) owner. This field is not available via MONRS-DS’s ODATA data service (a limitation of SharePoint).

7.2.1.6. DataServicesData

The DataServicesData field is a text field and is provided as a “catch-all” field for any information being passed in via MONRS-DS’s ODATA data service that is not captured via the other fields. The ShowInViewForms attribute for this field is set to false and thus is not viewable in any list views.

7.2.1.7. SendNotification

This field is used internally by the system to suppress notification emails, as may be required during testing and debugging of the tool. When set to false, notifications (such as the ones sent when a new record is created or an existing record is reassigned) are not sent by the event handlers. The ReadOnlyEnforced attribute for this field is set to true to prevent modification of the field value after the list item has been created. The ShowInViewForms attribute for this field is set to false and thus is not viewable in any list views.

7.2.2. Event Handlers

The event handlers for the Events List run on the SharePoint server. During execution of any of these handlers, if an error is encountered the event is cancelled and the exception message is logged to the Log List.

TECHNICAL: The ItemAdded event handler is by default an asynchronous handler, but in this application has been configured to run synchronously. This was done to prevent concurrent access errors that can occur (and did occur during testing) when MONRS-DI is exporting OOT events to MONRS-DS.

7.2.2.1. ItemAdding

This handler runs while a new record is being added (e.g. the creation data for the record has been submitted but the system has not yet created the record). The sole purpose of this handler is to ensure that a valid SharePoint user is provided in the Owner field of the item.

When a new record is created via the New Form, the form’s people picker control validates that the Owner field contains a valid user. However when a new record is created through the ODATA data service the Owner field is not accessible. Instead the domain ID of the owner is passed via the DataServicesData field. In such instances the ItemAdding handler converts the domain ID into a valid SharePoint user and inserts the value into the Owner field, after which it clears the DataServicesData field. If the handler cannot determine the user from the data provided in the DataServicesData field it inserts a pre-configured default user (typically the application administrator).

7.2.2.2. ItemAdded

This handler runs once a new record has been added to the Events List. It assigns the Edit permission for the record to the owner and sends an email notification to that individual. The email includes an explanation of why the user is receiving the notice, a basic set of instructions on the next steps to take and a link to the SharePoint list that holds the event records.

IMPORTANT: The ‘Edit’ role allows a record to be modified and the permissions changed (this is necessary to allow reassignment of the record), but does NOT allow the record to be deleted.

7.2.2.3. ItemAttachmentDeleting

This is the handler that runs while an attachment is being deleted. It has been configured to perform three checks. 1) If the current user is a site admin it simply returns from the function call (e.g. it takes no further action). 2) If the current user is not a site admin then it checks the closure status of the record. If the record is closed it cancels the event and returns an error message stating that attachment deletion is forbidden after record closure. 3) If the user is not a site admin and the record is not closed then it checks the filename of the attachment being deleted. If the filename matches the filename of the Calibration Report (which itself is named after the AssetCtag value of the record) it cancels the event and returns an error message stating that the Calibration Report cannot be deleted.

7.2.2.4. ItemUpdating

This handler runs while an existing record is being updated. It handles updating ownership of the record (if the record has been reassigned by its current owner) and all related activities (updating permissions, sending notifications). It also handles validating (server-side) form data if the user has submitted the form for closure. If the data validates the Closed field is set to true, otherwise it cancels the event and displays a validation error to the user. The fields that are validated are: ImpactToTesting, ImpactAssessor, and Disposition. The only requirement is that these fields have a value (i.e. are not empty).

The ItemUpdating handler also performs checks that prevent a record’s data from being modified after record closure (with the exception of the Notes field), unless the user performing the modification is a site admin. If a non-site admin attempts to update a record after closure the handler cancels the event and returns an error message stating that the record cannot be modified after closure. This function of the handler prevents modification after record closure from all different update sources (through the user interface as well as through the SharePoint data services and client object model).

7.2.2.5. ItemDeleting

This handler runs while an existing record is being deleted. It simply checks to see if the current user is a site administrator. If not, it cancels the event and logs the attempt as an unauthorized access.

7.2.3. Custom Actions

MONRS-DS has several Custom Actions (the generic SharePoint term for custom Ribbon buttons, menu items, etc.) that have been added to the list forms and menus.

7.2.3.1. Reassign Item

The Reassign Item button is displayed on the Ribbon menu of the Display Form and allows the current record owner to reassign ownership of the record to another individual. It does this by displaying the Reassignment Form (detailed further in a section below). Reassignment of ownership can occur at any time prior to the closure of the record (after closure the button is disabled).

TECHNICAL: The Reassign Item button is always disabled for everyone except the record owner (and the site owners / admins). This is done via client-side script that asynchronously queries the server for the permission set of the current user on the current item. If the user does not have Edit permission the button is disabled.

7.2.3.2. Submit

The Submit button is displayed on the Ribbon menu of the Edit Form and allows the record owner to submit the record closure (as mentioned previously the form data must validate first).

7.2.3.3. Attach File

The Attach File button is displayed on the Ribbon menu of the Edit Form. This specific button is provided as one of the default SharePoint actions but for this application has been overridden to disable itself once the record has been closure (to prevent any further attachments from being added to the record after closure). Otherwise this action behaves exactly as the default.

7.2.3.4. Instructions

The Instructions button is displayed on the Ribbon menu of both the Display and Edit forms.

When clicked it simply launches a modal dialogue with a set of instructions on how to use the currently displayed form and how to perform the OOT assessment and disposition.

7.2.3.5. Delete Item

SharePoint normally displays a button in the Display Form, Edit Form and List View menu that allows a user with appropriate permissions to delete the list item. As MONRS end-users are never granted the rights to delete a record (list item) the Delete Item button has simply been overridden such that it does not even display in any of the list forms or views. This was to prevent any possible confusion on the part of the end-users who would otherwise be able to see (but not click) a delete button.

7.2.4. Views

SharePoint views provide a “tabular” view of the records contained in a list. MONRS-DS has two primary views, described below. Other views may be added as needed by the application administrator, however because MONRS-DS uses customized list forms to control the modification of item data it is necessary to prevent end-users from creating new views directly, as doing so has the potential to subvert the various controls implemented by the current configuration. Additionally inline editing of item data from within a SharePoint view is disallowed for the same data-control reasons.

7.2.4.1. All Items

The All Items View is a standard SharePoint list view that has been configured to display a subset of OOT data for each record. This view is not filtered so every record in the system is shown (records are paginated using the default SharePoint pagination scheme). This view is primarily for report generation and auditing purposes.

7.2.4.2. Owned Items

This view is also a standard SharePoint list view showing a subset of OOT data but it has been filtered so that the currently logged-in user will see only those records for which he or she has ownership. This is the view to which users are linked from within the notification email.

7.2.4.3. All Items (Detailed)

This view is similar to the All Items view with the exception that all of the potentially-relevant list fields are displayed (several more than are displayed in the All Items view).

7.2.5. Forms

All forms associated with the Events List (New, Display, Edit, and Reassignment) are customized using XSLT, HTML, CSS and JavaScript. Because the use of JavaScript is so integral to the normal operation of the list forms (they will not work if JavaScript is turned off), the forms display only a warning to that effect (i.e. no data) if JavaScript is disabled.

When an OOT event is exported from MONRS-DI, the Calibration Report is uploaded as a regular attachment to the newly created list item. Because a SharePoint list item can have only a single attachments folder associated with it, when displayed in the list forms the Calibration Report for has to be specially handled. For both the Display and Edit forms, the Calibration Report is dynamically positioned in the form via JavaScript on the client-side. It does this by parsing the list of attachment elements in the form, looking for the attachment having a filename that corresponds to the AssetCtag value of the currently selected list item, and then moving the matched element up into the Calibration Report row. It also removes the Delete Item link that normally accompanies attachments rendered via SharePoint on the server-side. If a match cannot be found a statement is inserted into the Calibration Report row indicating that the MSCL help desk should be contacted (along with a contact number and a “mailto” link).

All forms requiring data validation do so using client-side JavaScript functions. When valid data is required (e.g. when attempting to submit the record for closure) the validation functions will display an error message next to each form field that failed validation.

All forms having editable fields (namely the Edit, Reassignment, and New forms) include tooltip descriptors that gradually fade into view when the editable field is hovered over with the mouse.

TECHNICAL: All forms are a mixture of a form template (created in SharePoint Designer) and an XSL document that contains the actual XSLT logic for rendering the form controls.

7.2.5.1. Display Form

The Display Form is a customized web form that displays a subset of event fields and provides a quick look at the status and data of the OOT assessment. From this form a user may choose to open the Edit Form or the Reassignment Form of the record by clicking the appropriate Ribbon button. The button for the Reassignment Form is disabled if the record has been closed.

7.2.5.2. Edit Form

The Edit Form is the interface where an event owner will spend most of his or her time. This form has two “modes”: pre-closure and post-closure.

TECHNICAL: The logic for rendering both “modes” of the Edit Form are contained in the same XSL file. Conditional XLST logic is used to first determine if the record is closed and then choose what type of control to render (editable or read-only) for each field in the form.

Pre-Closure

In this mode the form presents a mix of read-only event fields (including a link to the Calibration Report) and editable fields the owner uses to record the results of the assessment and disposition for the OOT event. The assessment/disposition fields are those required by JPR

1281.11 and included on the JSC Form 190, and are marked as required on the Edit Form where appropriate. Where possible, form fields are date pickers, drop-downs and people pickers to assist the user in selecting valid field values. Users may also add file attachments to the record as necessary to support his assessment and final disposition.

As a user works inside the Edit Form they may save their progress at any time by clicking the Save button. Save allows an update to the record without performing any field validation.

Once a user has completed filling out all required fields in the form and does not need to make any further changes to the record he or she should click the Submit button. A dialogue box then asks for confirmation that the user wishes to proceed with record closure (this is to prevent accidental closure by the user). If the user confirms, the form will then perform the aforementioned validation check. If the form data passes validation the form will send that data back to the server-side where another validation (checking for the same validation conditions) will run. If the server-side validation passes the list item will then be marked as closed (as described in the list Event Handlers section).

Post-Closure

In post-closure mode the form renders all previously editable event fields as read-only, with the exception of the Notes field, which remains editable. This allows the record to have historical annotation added as necessary post closure. Both the Submit and Attach File buttons are disabled in this mode. However the Save button is still active to allow updates to the Notes field to be saved to the record.

IMPORTANT: As it may be clear at this point, an owner of a record will retain the Edit permission on the record even after record closure. This is to allow the owner to update the Notes field indefinitely. This has obvious implications; namely, the owner still has the potential to edit a record after closure. However the system prevents post-closure modification of the record (with the exception of the Notes field) by controlling the avenues (forms, views) with which a user can edit the record. This is why end-users are not allowed to perform inline editing or creation/modification of views and is also why the list forms will not function with JavaScript disabled.

7.2.5.3. Reassignment Form

The Reassignment Form allows the current record owner to reassign owner responsibility to an individual of his or her choosing. This form has three fields.

The first is a people picker that assists the current owner in selecting the new owner. The second is a text field that allows the current owner to provide an optional personalized message that will be sent as part of the notification email to the new owner. The third field is the Reassign Account checkbox that, when checked, causes the system to send an email to the MSCL help-desk indicating that the user would like the MSCL to update their point-of-contact information for the account associated with the current record to the new owner. The account and new point-of-contact information are grabbed dynamically by the system during the execution of the server-side event handler.

7.2.5.4. New Form

The New Form allows new event records to be created manually from within MONRS-DS itself.

It provides web controls for collecting the same data that is passed to MONRS-DS from MONRS-DI. Several of the fields are critical to the lifecycle of an OOT record in MONRS-DS and thus are marked as required in the New Form. As with the Edit Form all required fields in the New Form are validated with client-side script.

IMPORTANT: The server-side event handlers currently do NOT perform any data validation when a new record is created.

IMPORTANT: A new role called “Add” provides the permissions (primarily the Add and Manage Permissions permissions) necessary to create a new record via the New Form.

7.2.6. User Notifications

To the greatest extent possible, all email notifications sent by the system (New Event, Reassigned Event, Reassigned Account) use an HTML templating system that prevents the formatting and wording of the notification from being hard-coded into the application. The event handlers that send the notifications look up a few small dynamic notification elements (asset number, calibration date, etc.) that are inserted into the template at runtime.

TECHNICAL: Because MONRS-DS runs inside a sandboxed solution, it cannot make programmatic calls to the SPUtility.SendEmail method of the SharePoint API. Instead it uses the Oasis.SandboxProxies.SPUtilityProxy proxy API that was developed by the Oasis development team, which contains a proxied SendEmail method. See the Notification source code for further detail.

7.3. The Log List

The Log List is an extremely simple SharePoint list with three fields: Title, Message, and Type. The Title field is used to hold the timestamp of a list item (e.g. a log entry). The Message field contains the log message. The Type field represents the type of log message for the item; although the type can be just about anything it is common practice within MONRS to use one of the following values:

INFO, WARNING, or ERROR.

There are no event handlers configured for this list.

TECHNICAL: The MONRS-DS feature receiver creates a new permission level called “Add” when the feature is activated. This permission set allows list items to be viewed and new items to be created but does NOT allow modification of the items. This permission set is granted to the MONRS SharePoint site “visitors” group so that the event handlers are able to write error messages to the Log List (event handlers run as the currently logged-in user).

8. Signatures Prepared By: Jason P. Vos Signature: _____________________ Date: _____________

Approved By: Barry Plante Signature: _____________________ Date: _____________

8. Signatures