The Jeff's Ticket Tracking System

Transcription

1 TheJeffsTicketTracker.thejeffapproves.com The Jeff's Ticket Tracking System Jeff Denton A.K.A The Jeff 15

2 Contents About The Jeff... 4 Project Summary and Requirements... 5 Design Documentation... 6 Sprint Backlog... 6 Sprint Backlog Continued... 7 Initial Use Case Diagram... 8 Description of Use Case Diagram... 8 Supplemental Use Case Diagrams... 9 User Use Case Diagram Tech Use Case Diagram Admin Use Case Diagram Database Diagram Description of Database Overview of Project User Interface Home Page Admin Control Panel Assign Ticket Edit Ticket Contact Management Panel Close Ticket Search Page Code Behind Main Menu Add New Contact Claim Ticket Details Links Switch for Edit Control Filtering for Ticket Index View Remove Tech Search Results... 28

3 Date Change for Soft Delete Unclaimed Tickets Action Resume... 30

4 About The Jeff The Jeff attended college at DeVry University in In 2010, The Jeff graduated Summa Cum Laude with a Bachelor's Degree in Computer Information Systems with a concentration in website and database design. Shortly after finishing the undergrad program, The Jeff attended Keller Graduate School of Management from 2010 to The Jeff received a Master's Degree and graduated With Honors with a dual concentration in database management and security. Following this, The Jeff attended Centriq Training in 2015 in order to enhance the skills obtained at DeVry and Keller. The Jeff is a quick learner, knows how to interact with clients, is self-motivated, and eager to learn and grow in the world of.net development. The Jeff pays attention to detail and strives for excellence in all areas in order to ensure that...the Jeff Approves

5 Project Summary and Requirements The purpose of this project is to simulate an internal tracking system that employees can use to submit tickets to the I.T. department. These tickets can then be reviewed by technicians in order to resolve issues relating to a number of areas, including hardware and software. Technicians can also post notes that pertain to the current ticket. Tickets are treated as private, so only select users can view and edit tickets. Tickets are also kept for historical information. This project also allows for several administrative functions, such as the management of employees and internal departments. Based on this information, the project contains the following requirements: 1. Allow All Users to Submit Tickets to a Database. 2. Limit Management, including Creation and Removal, of Employees and Departments to only Admin Users. 3. Limit the Viewing of Tickets to Technicians and Submitting Users. 4. Limit the Editing of Tickets to Technicians and Admins. 5. Implement a "Soft-Delete" of Tickets (Remove the Ticket from View, but not From the Database). 6. Allow Technicians to Post Notes Relating to the Current Ticket.

6 Design Documentation Sprint Backlog Date Sprint Version Tasks to Accomplish Tasks Completed Tasks Still To Complete October 12th Sprint 1.0 Create Initial All Tasks Completed Database, Create Initial Web Project, Implement Identity October 13th Sprint 2.0 Convert Template to All Tasks Completed MVC Layout Page, Create Data Layer For Project, Implement Database Using Entity Framework, Create Meta Data Classes October 14th Sprint 3.0 Create Controllers All Tasks Completed and Views For Lookup Tables October 15th Sprint 4.0 Create Controller & Views for Employees, Create Controller & Views for Employees, Implement Filtering Based On User Roles Confirm CRUD Functionality for Employees, Implement Filtering Based On User Roles October 19th Sprint 4.1 Implement Filtering Based On User Roles, Create Views and Controller for Tickets, Implement Soft Deletes and Filtering for Tickets based on Status Confirm CRUD Functionality for Employees Create Views and Controller for Tickets, Implement Soft Deletes and Filtering for Tickets based on Status Implement Filtering Based On User Roles

7 Sprint Backlog Continued Date Sprint Version Tasks to Accomplish Tasks Completed Tasks Still To Complete October, 21st Sprint 4.2 Implement Filtering Based On User Roles, Test CRUD Functionality on Support Tickets Implement Filtering Based On User Roles Test CRUD Functionality on Support Tickets October 25th Sprint 4.3 Implement Filtering Based On User Roles, Implement jquery Datepicker for Date Fields, Implement Functionality for File Uploading October 26th Sprint 4.4 Implement Filtering Based On User Roles October 28th Sprint 5.0 Implement Paging and Searching for Employees and Tickets, Secure Controllers October 29th, Sprint 5.1 Secure Controllers, Add Tech Note Creation for User Tickets November 2nd Sprint 6.0 Complete Styling Sheet and Overall Look of Web Application, Correct Minor Issues, Add Assignment Functionality to Admin Users Implement jquery Datepicker for Date Fields, Implement Functionality for File Uploading Implement Filtering Based On User Roles Implement Paging and Searching for Employees and Tickets Secure Controllers, Add Tech Note Creation for User Tickets Complete Styling Sheet and Overall Look of Web Application, Correct Minor Issues, Add Assignment Functionality to Admin Users Implement Filtering Based On User Roles Secure Controllers

8 Initial Use Case Diagram Description of Use Case Diagram This is an initial version of the ticket tracking system, based on the outlined requirements. After examining the requirements provided, it can be determined that at least three types of actors will interact with the application. The first is the User actor, which represents all logged in users that do not have the roll of technician or admin. This actor will have access to only minimal functionality. The second is the Tech actor, which represents actual members of the IT department. This actor will have

9 access to features that the User does not. Lastly, we have the Admin, who will have access to all functionality. Initially, the User will only have the ability to submit a new user ticket. Viewing tickets is common to all actors and is therefore not shown. The Tech will have the ability to submit new tickets, add notes to a ticket, and mark tickets as resolved. The Admin will have access to the functionality available to the User and Tech, and in addition, the Admin will be allowed to mark support tickets as Open and manage by Identity. information regarding employees, internal departments, as well as users and roles as provided Supplemental Use Case Diagrams Additional research resulted in several additional functions for the application. As a result, several new actors and use cases were identified. Thusly, the use case diagram above was altered. The above diagram will be broken down according to the functionality that each actor has access to while using the application.

10 User Use Case Diagram This use case diagram illustrates the actions that are permitted for actors in the User role. Research on the application has identified an actor known as Supervisor. While this actor will be a factor in certain areas of the application, both the User and the Supervisor will have identical privileges. The User and the Supervisor will be able to submit new support tickets and view the tickets they have submitted. In addition, they will also be able to manage personal contact information that they have entered. Tech Use Case Diagram

11 The Tech actor will have access to the same functionality as the User and Supervisor in addition to the ability to view all open support tickets for the purpose of claiming them. They will also be able to view tickets that were assigned to them. The tech will also have the ability to edit tickets, mark them as resolved and release tickets they have claimed, marking them as open. They are also allowed to add notes to each ticket. Admin Use Case Diagram While researching the application, the admin actor was split into three distinct roles, the Tech Admin, the HR Admin, and the Admin. All of them will have the same basic functionality available to the

12 User actor. However, several functions will be extended. The HR Admin can manage employee information as well as all employee contact information. The Tech Admin will have the privileges available of the Tech user, however, they will also be able to manage all ticket information. The Admin actor will have access to all areas of the site, as well as the information related to membership.

13 Database Diagram TicketCategories PK CategoryID INTEGER TicketPriorities PK PriorityID INTEGER Name VARCHAR(20) Name VARCHAR(20) TechNotes Tickets PK TicketID INTEGER FK1 SubmitedBy INTEGER FK2 TechID INTEGER FK4 CategoryID INTEGER DateSubmitted DATETIME DateClosed DATETIME Description VARCHAR(250) FK3 StatusID INTEGER FK5 PriorityID INTEGER PK NoteID INTEGER FK2 TicketID INTEGER FK1 TechID INTEGER Text VARCHAR(200) DateAdded DATETIME TechSpecialities PK SpecialityID INTEGER Employees Speciality VARCHAR(30) TicketStatuses PK StatusID INTEGER Status VARCHAR(20) Contacts PK ContactID INTEGER FK2 EmployeeID INTEGER ContactName VARCHAR(50) FK1 ContactTypeID INTEGER PK EmployeeID INTEGER FirstName VARCHAR(50) LastName VARCHAR(50) Primary VARCHAR(128) UserID ATTACHMENT FK1 DepartmentID INTEGER FK2 SpecialityID INTEGER FK4 SupervisorID INTEGER DateOfBirth DATETIME EmployeePhoto VARCHAR(200) HireDate DATETIME ExitDate DATETIME FK3 StatusID INTEGER EmployeeStatuses PK StatusID INTEGER Name VARCHAR(30) ContactTypes PK ContactTypeID INTEGER Departments PK DepartmentID INTEGER ContactTypeName VARCHAR(15) Name Description IsActive VARCHAR(25) VARCHAR(500) BINARY(1)

14 Description of Database This diagram depicts the schema for the database back-end for the Ticket Tracker application. The central tables of the application are the Employees, Tickets, and TechNotes. The Employees table will gather information from the Departments, EmployeeStatuses, and TechSpecialities table. The Departments table will hold information relating to the area of the company in which the employee works (Sales, Marketing, HR, IT, etc.). The Status table will provide information that indicates whether the employee is currently active, on leave, laid off, or terminated. Lastly, the Specialities table will indicate whether or not the employee is a technician. If the employee is a tech, then they will have a specialty, such as hardware, software, or peripheral devices. In most cases, the information will pertain to only one specific employee one employee can have no more than one status or one tech speciality. However, many employees can belong to one department. Information stored within this table will be personal information, such as names, primary address (for membership purposes), as well as dates of hire and dates of departure. The Employees table will also relate to itself to allow for one employee to fill a supervisory role one employee can be a supervisor to several employees. The Employees table will also relate to the Contacts table, which contains all the contact information for the employees. The Contacts table will also contain information that will indicate whether the contact information relates to phone numbers or addresses. Besides the submitting employee, the Tickets table will contain information for the assigned technician. This field will allow for null values in order to allow for the fact that when a ticket is created, no tech will be assigned initially. In addition, this ticket will store a submission date and closure date provided by the system. It will also hold a description of the issue that prompted the submission of the

15 ticket. It will also gather information that relates to the category of the ticket, whether it pertains to hardware, software, etc. It will also gather information that relates to the ticket priority that will be assigned by the user. Lastly, the TechNotes table will contain information, such as the submitting tech, the ticket the notes are attached to, the text for the note itself, and the date the note was entered. All of this information will be provided by the system, while the text will be submitted by the user. All the tables will be identified by surrogate keys in order to allow for ease of functionality with the MVC code used to create this application. Overview of Project User Interface This area depicts several examples of the user interface for the application. Key areas of this application are represented, as well as areas that were created in addition to the minimum requirements outlined above.

16 Home Page This is the homepage for the application. It was designed from a template, and the template was chosen for it simple, user-friendly appearance. The navigation bar is easy to scale in the event additional navigation is required, and the main content is kept in the same area. Because of the requirements and expectations of this project, it was determined that the layout should be simple both in appearance and usability. The project was designed for an internal IT tracking application, and this requires a professional appearance. In addition, the functionality and navigation should be kept consistant among all pages, and this layout was suited to allow for it. It requires little modifcation to allow for content to be displayed with little to no effort. Lastly, the layout is already built to be responsive, which allows for flexibility among prospective users.

17 Admin Control Panel This is the control panel created for the admin users. The main content is divided into lists of management options. The lists are also divided and grouped according to the specific needs of the admin who is currently logged in. Only the Admin user can manage departments, while the HR and Tech Admins can view management options for employees and tickets respectfully. This layout was chosen again for its clean and easy-to-read appearance.

18 Assign Ticket This is a view created in order to allow for the assignment of techs to tickets by the Tech Admin or Admin user. The header will contain the most basic information for the ticket, such as who has submitted it and the date the ticket was submitted. The page will also contain a form that is common among other small views, such as editing lookup tables. The form will also contain a drop-down list containing all users in the Tech role. This design isolates the areas that are editable by the user in order to group them together for ease of use.

19 Edit Ticket This is the view that shows the edit form for a specific support ticket. Non-editable information is displayed in the headers, such as the name of the user who submitted the ticket and the date the ticket was submitted. This information also includes the tech that is assigned to the ticket. This is not editable here, as the tech is assigned and removed using other actions. Once again, editable information is grouped together in a form and isolated by a border.

20 Contact Management Panel This view displays the contact information for the current logged-in user. This was an additional view created to add additional functionality to the application. The name of the user is displayed on top, and the information is displayed in a table. The information is grouped according to the contact "name" ( address or phone number) the contact type, and the options to edit and delete the specific contact. Users will also be allowed to add a new contact. A tabular design was chosen due to the potential for several contact entries for the same employee. This made a tabular design more practical and readable.

21 Close Ticket This is the view that shows the option to mark a ticket as resolved by techs and tech admins. In this instance, a layout similar to the one used in forms is used to hold only the basic information about the ticket in order to ensure that the ticket selected was the one the tech wanted to close. This was done in order to offer a sense of continuity among the application.

22 Search Page This is the page depicting the search functionality available to admins. It searches for employees by last name. This is one of the few areas of the site that does not have the same border used elsewhere. In this case, it was determined that the border was not needed. While it could have easily been added, many search boxes do not include a large surrounding border. Therefore, this view does the same.

23 Code Behind These are key and additional areas of the code for the application included to demonstrate how the functionality on the pages was performed. Main Menu This is a code segment that creates the main navigation menu for the application. A series of IF statements are used to isolate areas of the navigation so that non-authenticated and/or non-admin users will not see sensitive areas of the site. Only authenticated users should have access to the communication manager and contact form, while only admin users should have access to the admin control panel. Add New Contact

24 This is part of the code used when an employee decides to add a new contact method through the communication manager. The employee information is stored in a session variable to make it persistent (it will not be deleted when the user leaves the page). The employee name is displayed to the user via a ViewBag variable in order to verify that the contact information is for only a specific employee, and the list of contact types is created through another ViewBag variable containing a SelectList. Once the employee clicks the submit button, this information will be used to create a new row in the Contacts table. Claim Ticket This is the code that provides the functionality for the Claim Tickets page. The currently selected ticket is found by way of an id value that is passed in by clicking on a specific link. The current user is also found by getting the user's id and then this value is used to determine the corresponding entry in the Employees table (users and employees are treated as two separate tables). This action will assign the employee id to the tech id field for the current ticket. It will also mark the ticket as in progress, in this case a status value of 2. Then, the information is saved to the database, before the user is returned to the list of tickets.

25 Details Links This code depicts certain areas of functionality shown on the details view for tickets. In this case, if the user is an admin or a tech and the current ticket does have a tech assigned, the option to release a ticket is seen. If, however, the user is an admin and the tech id of the current ticket is set to null, the option will be seen to assign a tech to the ticket. This reason for this is that techs and admins should be able to release a ticket, but only admins should be able to assign a tech to a ticket.

26 Switch for Edit Control This code displays one area of functionality of editing a ticket. In this case, we see the changes to specific fields based on the status of the ticket. This was done with a switch statement as the values used are constant. They will not change, although new statuses can be added. If the status chosen from the edit view equates to open (the ticket is either not claimed, claimed by a tech, or "escalated" to indicate additional assistance is required), then the date closed field will be set to null. If the status equates to closed (the ticket is resolved or canceled) then the date closed field will be set to the current time.

27 Filtering for Ticket Index View This code displays another example of isolating specific areas of functionality to certain users. In this case, this is a piece of code taken from the list of support tickets. If the user is logged in as an admin, tech admin, or tech, then they will be able to view the details for a specific ticket. If the user does not occupy one of these roles, they will only be able to see the name of the employee who submitted the ticket. The reason for this is that only specific users should have access to the details of a ticket. Remove Tech This code depicts the code that removes an assigned tech from a ticket. When the appropriate link is clicked on, the id of the current ticket is found. The tech id field is then set to null, and the ticket status

28 is set to open. The changes are then saved to the database before returning the user to the main tickets view. Search Results This code illustrates the functionality used to find employees based on information entered in a search box. The value from the search box is passed into the action, and a list of employees is pulled from the database. If the string passed in is not null or an empty string, it will return all employees whose last names contain the characters found in the string.

29 Date Change for Soft Delete This is another example of setting specific fields using the system. In this case, the code displays changes made by deactivating or reactivating a ticket. However, unlike the edit functionality, this code will set the status of the ticket to "resolved" if the ticket has a status that equates to open. In addition, the date close field is set to the current time. However, if a ticket is reactivated from a state that equates to closed, then the ticket is marked as "open" and the date closed is set to null. Unclaimed Tickets Action This code depicts the functionality that is used to display a list of all unclaimed support tickets for techs and tech admins. This allows them to claim tickets that they are comfortable in handling. The support tickets that have a status of open and no tech assigned are gathered and made into a list, and then returned to the view to be formatted into a table and displayed to the user.

30 Resume Jeffrey Denton 7521 North State, Route 9 Kansas City, Missouri (816) Mobile: (816) [email protected] DEVELOPER SUMMARY OF QUALIFICATIONS Knowledge of.net development and Microsoft Visual Studios High Aptitude in Database Development Proficiency in IT Consulting and Requirements Identification Commitment to Excellence in Work and Attention to Detail TECHNICAL SKILLS Windows Visual Studio 2013 C# C++ JavaScript XHTML PHP Database Creation, Population, Manipulation, and Administration using Oracle 9i PL/SQL, SQL Server and Microsoft Access Website Design using Adobe Dreamweaver and CSS. Technical Documentation Skills Using Microsoft Office Applications Data Modeling Using Microsoft Visio EDUCATION Centriq Training, Leawood, KS April Present.NET Developer Program Technical Competencies: Visual Studio, C#.NET, ASP.NET, ADO.NET, AJAX, LINQ, MVC, EF, SQL, SQL Server, SSMSE, HTML5, JavaScript, jquery, jqueryui, CSS3, Responsive/Mobile Web Development, JSON, Bootstrap. Professional IT Project Experience: o Widgets and Gadgets: Created a secure application for managing product data. Application is built to simulate an online store front with a shopping cart. Administrators have the ability to manage product, category and vendor data.

31 o Trouble Ticket Project: Created a secure ASP.NET MVC application for managing the lifecycle of a trouble ticket associated with hardware and software within an organization. Administrators have the ability to manage employee and department data as well as manage all details of submitted trouble tickets. Projects available for review: Keller Graduate School of Management, KC, MO September March 2014 Master of Information Systems Management (With Distinction), Dual Concentration in Database Management and Information Security Technical and Soft Skills o Directed team to create plan for IT application development o Created project definitions, requirements, and documentation for use by team o Calculated estimates for financial requirements and potential gains o Investigated business intelligence solutions for existing companies o Designed basic network architecture o Modeled database back-end for IT application o Proposed physical and IT security measures to ensure data remains uncompromised o Maintained active communication among team members o Provided quick and accurate work under tight deadlines DeVry University, KC, MO September June 2010 Bachelor's Degree in Computer Information Systems (Summa Cum Laude), Major Website and Database Development Technical and Soft Skills o Created front-end design for Gamma Beta Phi website using HTML and CSS o Distributed project documentation and Status Updates for Team o Programmed Basic Applications Using C#, C++, Java, and ASP.Net o Programmed Databases Using Oracle PL/SQL o Configured Systems with Windows and Linux Red Hat o Calculated Basic Financial Information o Team Conflict and Resolution o Provided Quick and Accurate Work Under Tight Deadlines PROFESSIONAL EXPERIENCE JEMMCO Enterprises, LLC, KC, MO May Present Senior Service Package Operative Assist JEMMCO service teams to provide quality service to clients Train temporary employees as needed Adapt to new service requirements as requested by clients Inform JEMMCO staff of inventory deficiencies

32 Security and IT Consultant Assess current IT structure and report findings Assess current security structure and report findings Develop potential IT expansion solutions for consideration by upper management Propose new security solutions for consideration by upper management