Application Manager | Tech Docs
Contents
Application Details
Developer: Joe Gautreau | Programmer / Web Application Developer | jgautreau@judsonisd.org | (210) 945-5558
Development Platform: ColdFusion MX 7, SQL Server, Model-Glue Framework, CSS Layout
Development Server: Testweb
Development Database: ERCSQL
Production Server: Web1
Production Database: ERCSQL2K5
Launch Date: September 14, 2007
Application Overview
The Application Manager was designed to be the the front-end tool for an administrator to give users and groups access to in-house applications. This simple GUI interface provides an easy way to manage users. This application is far from the final product we would like, but for the interim it does the job quite well.
It works quite simply. The administrator will log in and choose from a list of applications which one they would like to manage. The screen will reload after submission a list of all Judson ISD users and groups will appear next to a tabbed box for each role for that application. Users and groups are moved in / out of applications and roles accordingly.
To sum it all up, the Application Manager is for permissions users and groups in and out of in-house applications.
Roles
There is only one role for this application at the moment and that is the administrator role which can permission users and groups in and out of any in-house application.
Database Schema
Below you will find the Application Manager database schema along with a short description for each table.
Application Table: This table is used to store data about in-house applications. The application name, url, description, developer, owner, active or not, and manageable or not information are stored in this table. If you want to create a new in house application this is the first place you would start. Here your AppID is created to be used elsewhere.
AppRole Table: This table is used to store the different types of roles that an application may have. For instance "Application A" may have User, Manager and Admin roles, so in this table you'll find three entries for those role types, once a role is defined, a roleID is created to be used in the userRole table.
UserRole Table: This table is used to store all user permissions. The user's employeeID is the stored with the applicationID and roleID that they have access to. A user can have multiple entries in this table because access to multiple applications is probable.
AdData Table: This table is used to store a "copy" of data needed from Active Directory for this application. This is used as a "quick" lookup instead of going to AD for it which takes a LONG time!
Flow
Application Manager Data Flow Document - Click to download the PDF.
CFC's & Functions
Apps.cfc
init:
- Purpose: When called this function returns an instance of the entire object / cfc with all methods available.
- Arguments: None
- Return Type: CFC
getApps:
- Purpose: This function goes into the Application table and pulls a list of applications along with their ID and returns a query result set.
- Arguments: None
- Return Type: Query
getAppRoles:
- Purpose: This function goes into the AppRole table and pulls the roleID and roleName where the appID matches the application ID passed into the function. It orders the query result set by application name and passes back a query result set.
- Arguments: appID (numeric)
- Return Type: Query
getPermissionsDataByAppRole:
- Purpose: This function grabs everyone from the userRole table where their roleID matches what was passed into the function, and it joins itself on the adData table for detailed user info to display on the screen. This function is used to get the query result set of what users are in what role for an application. It is ordered by the employeeCN on the adData table. A query result set is then returned for the roleID with the users and/or groups who have that role assigned to them.
- Arguments: roleID (numeric)
- Return Type: Query
getActiveDirectory:
- Purpose: This function selects all users and groups from the adTable where they are not assigned to any role within the application. The notIn argument string, is obtained from the controller which loops over the query result sets from the getAppRoles function and adds the uniqueID's of the user/group to a comma seperated string and passes it in to this function.
- Arguments: notIn (comma seperated string)
- Return Type: Query
updateAppPermissions:
- Purpose: This function updates the userRole table with any changes to the user permissions of an application. The first thing done is to delete everyone with the roleID(s) that match the edited application. Next the passed in structure of userID's and their roles is looped over and they are inserted into the userRole table. This process is wrapped in <cftransaction> tags, if anything fails then the process won't take, otherwise the process will return a boolean value of whether it passed or not.
- Arguments: permStruct (structure), appID (numeric)
- Return Type: Boolean (true/false)
Notes
Future revisions to this application would be to tie it together with the Application Portal and fix error handling, also to add user levels that allows "Application Owners" to manage user and group permissioning for an individual application.
A nightly process run on the CF Server called updateAdData, runs nightly to query AD and grab everything out of it, and dump it into a table called adData in the Application Security database. This process allows for our display of users and groups to go much quicker pulling it from SQL tables instead of directly from Active Directory.