QIR .NET Web App - Home Page and Incident Assembly

1.0 - Challenge Overview

Welcome to the QIR .NET Web App - Home Page and Incident Assembly challenge! In this challenge, you will need to build the backend services, stored procedures and part of the pages that the new QIR .NET App will use (based on the architecture design).

NOTE: This is part 3 of a series of assembly challenges for this project!  

1.1 - Project Overview

The client for this project has an existing system called Quality Incident Reporting (QIR) application.  This existing application was created using SharePoint and is used for creating and managing quality incident records.  The goal for this project is to build a new Quality Incident Reporting application using .NET (based on the existing QIR application).

This assembly will provide the the backend services, stored procedures and part of the pages as detailed below for the Home Page and Incidents (details below).

1.2 - Competition Task Overview

A complete list of deliverables can be found in the TopCoder Assembly competition Tutorial at: http://apps.topcoder.com/wiki/display/tc/Assembly+Competition+Tutorials

Note: Extensive implementation notes are provided at method documentation on UML Class Diagrams. Please follow them for implementation.

Note: Please read the whole Application Design Specification first. All the details not mentioned in this specification are provided in that document.

1.2.1    Backend Services
This assembly is responsible for implementing the following services on class diagram "Backend Services Class Diagram":
    1) IncidentService
    2) ClassificationService
    3) ClassificationNodeService
    4) ActionItemService

1.2.2    Stored Procedures
This assembly is responsible for implementing all stored procedures used by the above-mentioned services.

1.2.3    Regular Home Page (regularHomePage.aspx)

Code Behind: RegularHomePage
Wireframe: regular_user_home

- The content of this page is rendered in server side, see the RegularHomePage methods for details.
- For rendering QIRs data we will use GridView to render the root causes tree. We need to prepare incident data for the data provider.
- The “Clear” button erases all values entered by user in search parameters. No interaction with the server side takes place.
- When “Remove from working list” link button is clicked against a QIR and database is updated relevant the grid view is updated with the same paging/sorting/search parameters staying on the page without reloading the whole page.

1.2.4    Admin Home Page (adminHomePage.aspx)

Code Behind: AdminHomePage
Wireframe: business_and_system_admin_user_home

- The processing of this page is similar to the above page (Regular Home). Note that all some more search criteria are added and “Delete” link button is available against every QIR in the list. Handled by code behind as well.
- When “Delete” link button is clicked against a QIR and database is updated relevant the grid view is updated with the same paging/sorting/search parameters staying on the page without reloading the whole page.

1.2.5    Draft Incident Page (draftIncidentPage.aspx)

Code Behind: DraftIncidentPage
Wireframe: qir-_required_for_draft_fields_filled

Most of content of this page is rendered in server side, see the DraftIncidentPage methods for details. But some content are rendered in client side using Javascript, using AJAX calls to server side:
- for adding Author a modal popup appears when clicking “…”; SearchPersonsRequestHandler AJAX request is made to get available persons (at first all at once, then by first chars of their name); AJAX response is rendered as a list of users;
- the same for adding Incident Owner;
- to populate regions drop down list after the department is chosen GetRegionByDeptRequestHandler AJAX request is made to get regions by the chosen department;
- if Impact on customers is “Yes” all other fields in “Impact On Customer” section are available; if “No” – all these fields are hidden;
- when enter/edit classification button is clicked a modal popup appears to choose a classification:
   - to get all classification nodes GetAllClassificationNodesRequestHandler AJAX request is made to the server side; 
   - its AJAX response after being parsed popuated a TreeView instance and is rendered in the popup by means of this instance;
   - when user updates any level of classification or keyword values (see modal popup in wireframe) you must loop though the TreeView nodes to find and render only those nodes that contain [keyword] substring or are children of the selected node;
   - to populate next level drop down list of the current node GetClassificationChildrenNodesRequestHandler AJAX request is made to the server side;
- when enter/edit root cause button is clicked a modal popup appears to choose a root cause:
   - to get all root cause nodes GetAllRootCausesRequestHandler AJAX request is made to the server side; they are persisted at the client-side until the popup is closed;
   - its AJAX response after being parsed popuated a TreeView instance and is rendered in the popup by means of this instance;
   - when user updates any level of root cause or keyword values (see modal popup in wireframe) you must loop though the TreeView nodes to find and render only those nodes that contain [keyword] substring or are children of the selected node;
   - to populate next level drop down list of the current node GetRootCauseChildrenNodesRequestHandler AJAX request is made to the server side;
   
The code snippet below gives an idea how search for nodes by its name or a substring in its name:

private TreeNode FindNodeByValue(string value)
{
    foreach(TreeNode node in TreeView1.Nodes)
    {
        if(node.Value = value) return node;
        TreeNode pnode = FindNodeRecursion(node, value);
        if(pnode != null) return pnode;
    }
    return null;
}

private TreeNode FindNodeRecursion(TreeNode parentNode, string value)
{
    foreach(TreeNode node in parentNode.ChildNodes)
    {
        if(node.Value = value) return node;
        TreeNode pnode = FindNodeRecursion(node, value);
        if(pnode != null) return pnode;
    }
    return null;
} 

 

1.2.6    Required for Save Incident Page (requiredForSaveIncidentPage.aspx)

Code Behind: RequiredForSaveIncidentPage
Wireframe: qir-_required_for_save_fields_filled

The processing of this page is similar to the above page (Draft Incident Page). Everything different to the page above is handled by the server side and documented in RequiredForSaveIncidentPage impl notes.

1.2.7    Required for Approval Incident Page (requiredForApprovalIncidentPage.aspx)

Code Behind: RequiredForApprovalIncidentPage
Wireframe: qir-_required_for_approval_fields_filled

- The processing of this page is similar to the above page (Draft Incident Page and Required for Save Incident Page). Everything different to the page above is handled by the server side and documented in RequiredForApprovalIncidentPage impl notes.
- The only difference for the client-side is Edit link button against each action item. It shows a modal popup which populate with action item draft. These data is pulled from the server side with GetActionItemRequestHandler AJAX request (its response is parsed and rendered as Action Item).

1.2.8    Awaiting for Approval Incident Page (requiredForApprovalIncidentPage.aspx)

Code Behind: AwaitingforApprovalIncidentPage
Wireframe: qir-_awaiting_approval

- The processing of this page is similar to the above page (Required for Save Incident Page and Approval Incident Page). Everything different to the page above is handled by the server side and documented in RequiredForApprovalIncidentPage impl notes.
- When Reject button a modal popup appears asking a user for the rejection reason. User can either cancel this action or enter the reason and click Reject – this action will be handled with #Reject which accepts the incident Id and the reason text.

1.2.9    Closed Incident Page (closedIncidentPage.aspx)

Code Behind: ClosedIncidentPage
Wireframe: qir-_closed

This page is fully rendered on page load. All possible actions are handled with code behind of ClosedIncidentPage class.

1.2.10    Reopened Incident Page (reopensedIncidentPage.aspx)

Code Behind: ReopenedIncidentPage
Wireframe: qir-_reopened

This page has controls and behaviour totally similar to Required for Approval Incident Page (requiredForApprovalIncidentPage.aspx). The only tiny difference is that rejection reason is displayed.

1.2.11    Request handlers

This assembly is responsible for implementing all HTTP Request handlers used by the above-mentioned pages.

 

1.3 - Technology Overview

- Windows Server 2008 R2
- MS SQL Server 2012
- IIS 7
- C# 4.0
- .NET Framework 4.0
- ASP.NET Web Form
- jQuery 1.11.1 http://jquery.com

 

Browser Requirements:
Your submission must works on browser in the list below:
- IE8+
- Safari latest version on Mac & Windows
- Firefox latest version on Mac & Windows
- Chrome latest version on Mac & Windows

 

1.4 - Documentation Provided

Documentation and Applications that will be provided to registered members:

Document Name	Document Description
Application Design Specification	Architecture documentation attached
Class Diagrams	Architecture documentation attached
Sequence Diagrams	Architecture documentation attached
ERD	Architecture documentation attached
UI Prototype	HTML / CSS / JS prototype attached
Assembly 1: Model, Exception, Authorization, and Notification Assembly	Completed 1st assembly challenge in this series
Assembly 2: Codes, Regions, Logs and Root Cause Assembly	Completed 2nd assembly challenge in this series
Quality Incident Report Enhancements - Dec 19 2014.xlsx	Excel file with latest requirements (form fields, access levels, classifications, root causes, etc)

 

1.5 - Testing

Please include unit tests to verify your application successfully meets the requirements of the project.  You should provide functional tests.