Programmer’s Guide
For
Timesheet System
Submitted by
Todd Klasik, Kalin Gochev
Copyright (c) 2005, Gregory W. Hislop. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
Table of Contents
1 Introduction 3
1.1 Purpose 3
1.2 Definitions, Acronyms, and Abbreviations 3
1.3 References 3
2 Authentication 4
3 Modules 4
3.1 Modules and Actions 4
3.2 Adding New Modules 5
3.3 Removing Modules 5
1 Introduction
The Timesheet System is a system designed to be able to manage the timesheets produced by the clock in and out card system used currently on Trinity College campus. It will support functionality to approve timesheets, allow administrators to overwrite student hours, and provide a printable version of the hours worked by students during the week.
1.1 Purpose
The purpose of this document is to provide developers with a detailed description of how Timesheet System works and how to extend the functionality of the system.
1.2 Definitions, Acronyms, and Abbreviations
Optim System – the current clock in/out system utilized by Trinity College.
1.3 References
Software Requirements Specifications (SRS) for Timesheet System submitted on March 5, 2007 by Todd Klasik and Kalin Gochev.
Software Design Specifications (SDS) for Timesheet System
2
2
2 Authentication
Authentication in Timesheet System is managed by PHP sessions. After the user provides username and password to the login page, the credentials are verified using the database and a session is created. The session contains information about the following:
User agent: $_SESSION[‘ts_user_agent’]
Username: $_SESSION[‘ts_user’]
User id: $_SESSION[‘ts_user_id’]
User access: $_SESSION[‘ts_access’]
The session authentication management allows for easy and reliable authentication throughout all modules of the system.
3 Modules
3.1 Modules and Actions
What is a module? A module inside Timesheet System is a set of functions and/or scripts aimed to provide certain functionality to the user. From the developers’ perspective, a module is contained inside a folder in <root dir>/mod/ having the module’s name. The module’s folder has to contain 2 PHP files called conf.php and default.php.
conf.php
conf.php has to contain 2 functions
module name>_toolbox() – specifies if a link to the module should be displayed in the employee toolbox, admin toolbox, both, or none. It returns ‘emp’, ‘adm’, ‘both’, or ‘none’ respectively.
module name>_title() – specifies the title that should be displayed in the toolbox. This allows for the name of the module to be something like ‘usrman’, but the displayed title to be ‘User Manager’.
default.php
All functions inside a module should have the following structure
module name>_<action name>(…)
default.php contains all the functions needed for the module to operate, including all the action functions (in the form module name>_<action>() ).
main.php accepts parameters mod and act, which specify the module and the action respectively. If a parameter is not specified its value is assumed to be ‘default’.
e.g. If both mod and act are not specified the function default_default() from the default module will be called when main.php executes.
The function getModuleList() in main.php generates a list of modules and uses calls to module name>_toolbox()to generate the list of modules that should be displayed in the user’s toolbox based on his/her permissions (access).
3.2 Adding New Modules
Adding new modules is relatively simple as long as they conform to the above-defined standards. A folder inside <root dir>/mod/ will be recognized as a new module if it contains valid conf.php and default.php files.
3.3 Removing Modules
Removing the module folder from <root dir>/mod/ will remove the module.
5
5