Online Application System and Employee Dashboard for application sales and HR

Summary [login to view URL] is a custom written PHP website used to enroll people in dental insurance and keep track of a call center doing the same. It provides “Dental Insurance Applications” aimed at visitors of the site, outside sales agents, and data entry operators. It displays lists of those applications to various users responsible for manipulating or counting the records. Conventions There are a few different coding conventions used throughout as the scope of the project expanded, starting with procedural, then converted to OO in most places. Most classes are StudlyCaps, most methods, functions and variables are camelCase. Most pages visible to the user are in the root of a given subdirectory. Most pages that process data in some way are in the include directory within that subdirectory. For example, a user login is processed like this: /subdirectory/index ->POST-> /subdirectory/include/processLogin This segregation allowed quick duplication in the early, procedural days of the site. It is very WET and inefficient, but the site’s production schedule necessitated new areas fairly regularly and on short notice. Users Users are maintained through cookies and session. We’ll a user of class Employee as an example here. Logging In Every subdirectory directly below the root that requires login has a [login to view URL] file that contains a login form. The employee login form is then POSTed to employees/include/[login to view URL] which simply instantiates an object of class Employee and calls the public method Employee->authenticate($username, $password, $remember). The method compares $password to the entry in the employees table and does 3 things on success: It loads all user information from database to current object It updates the hash column in the employees table with a new random string It redirects to [login to view URL] on success or calls the global function handleError() on failure Access Control Each page that requires the user to be logged in implements require_once ‘/include/[login to view URL]’ to load the class of user applicable to that page. It then starts the session and checks for $_SESSION[‘LoggedIn’] and redirects the user to index if it’s missing. Next it instantiates an object of the Employee class. Then it calls the calling the Employee->validateHash() method which compares the randomly generated hash stored in $_COOKIE[‘User’] to see if it matches the value stored in the employees table of the database. On a match, the method calls the Employee->load() method which loads the user variables into the current Employee object from the database. If a page has content that should only be viewed by certain users, it is filtered by using PHP conditional statements that compare the value of Employee->department and Employee->accessLevel. Editing Users Applications Applications are handled as an object during entry and as a database row during retrieval and display. There are many types of applications including in-house, duplicate and external. Examples here are based on the in-house apps entered by the data entry users at /employees/[login to view URL] Entering applications Processing Applications Reports Reports are handled as objects that have methods to echo a list for viewing in the browser, on the printed page, and downloaded as a csv. These are filtered based on a starting and ending date range to reduce load time. In the browser, they are formatted as tables and enhanced using the DataTables jQuery extension. Generating a Report Printing a Report Downloading a CSV Suggested Improvements and Refactoring Users Applications Reports